Java interop question
work> (.getName (.getClass 0)) "java.lang.Integer" work> (.getName java.lang.Integer) ; Evaluation aborted. Why does the second expression fail? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Stumped - Java hangs when using Swing in Slime
I've got the same problem as srolls24 and CuppoJava on Windows XP, using Emacs 23 and versions of Clojure, Slime and Swank fetched today. Also, when starting Slime, it opens a connection to *inferior-lisp*, but keeps polling for Swank until I hit return in the inferior-lisp buffer. After that, it very quickly connects the slime-repl. Any thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Stumped - Java hangs when using Swing in Slime
Here's my experience with 1.6.0_12: When I run (load-file "celsius.clj") (celsius/celsius) from a REPL in a Cygwin rxvt, the problem recurs as before: The Swing window comes up, but input is not echoed in the swing window until I hit return in the rxvt window. If I use a cmd shell, I don't have the problem. SLIME with the emacs version I'm using, 23.0.0.1 (i386-mingw- nt5.1.2600), still has the problem. Can anyone recommend an Emacs version that does not exhibit the problem? A Cygwin terminal that doesn't have the problem? On Feb 11, 2:02 pm, "sroll...@gmail.com" wrote: > On Feb 5, 1:52 am, David wrote: > > > I've got the same problem assrolls24and CuppoJava on Windows XP, > > using Emacs 23 > > and versions of Clojure, Slime and Swank fetched today. > > > Also, when starting Slime, it opens a connection to *inferior-lisp*, > > but keeps polling > > for Swank until I hit return in the inferior-lisp buffer. After that, > > it very quickly connects > > the slime-repl. > > > Any thoughts? > > I just upgraded to JDK 1.6.0_12 (from 1.6.0_05) and the problem of > swing hanging no longer occurs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: My SLIME installation diary
I have a small problem with clojure-mode in your setup.
Since clojure-mode is autoloaded, it, and SLIME, aren't available
until I load a '.clj' file.
Starting SLIME, though, doesn't add the SLIME menu to the previously
loaded '.clj' buffer
(Newly loaded files get the menu, as they should).
Thanks,
-dms
On Feb 12, 12:35 pm, Phil Hagelberg wrote:
> bOR_ writes:
> >>> (push "/home/boris/.emacs.d" load-path)
> >>This is actually already on the load-path by default; no need to add it.
>
> > Standard load-path on ubuntu didn't include ~/.emacs.d for me. Not
> > sure why not.
>
> You're right; my bad.
>
> > 1. Creating a .emacs with the load-path .emacs.d
> > 2. Downloading clojure-mode.el
> > 3. replacing git:// with http:// to get past my proxy
> > 4. The slime git kept failing (stalled somewhere near the end of
> > downloading), so I removed that line from clojure-mode.el and
> > installed a snapshot of slime myself.
> > 5. The clojure git failed as well, I replaced it with the "svn
> > checkouthttp://clojure.googlecode.com/svn/trunk/clojure"; in clojure-
> > mode.el
>
> I can't reproduce these download problems... Has anyone else had trouble
> with these URLs?
>
> > I think perhaps the best thing to do with the failing gits (for
> > whatever reason) is to just let the script skip the downloading of new
> > checkouts if an old checkout is present, and to let it give a message
> > like this: "Failed to checkout slime, please do so manually, install
> > in ~/src and rerun M-x clojure-install".
>
> Yeah, not a bad idea.
>
> > 1. It can't find M-x slime clojure-slime-config doesn't seem to be an
> > option either to manually run with M-x clojure
>
> clojure-slime-config is a function, but it's not a command, so you can't
> invoke it via M-x. It should only be invoked from your .emacs file. I
> suspect you're missing the autoload that it mentions in the
> clojure-mode.el header:
>
> ;; (autoload 'clojure-mode "clojure-mode" "A major mode for Clojure" t)
> ;; (add-to-list 'auto-mode-alist '("\\.clj$" . clojure-mode))
>
> That should go in your .emacs file.
>
> I should have mentioned that if you don't already have an Emacs config,
> you could try the Emacs Starter Kit, where clojure-mode is already
> installed for you. (You would still have to install Clojure though.) But
> the autoloads are all set up for you.
>
> http://github.com/technomancy/emacs-starter-kit
>
> > (setq swank-clojure-jar-path (concat clojure-src-root
> > "/clojure/clojure.jar")
> > swank-clojure-extra-classpaths
> > (list (concat clojure-src-root "/contrib/src/"
>
> This isn't right according to the default installation, but if you
> checked things out manually it could be different.
>
> -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
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: My SLIME installation diary
I can't really claim to be handy with elisp, but I got by. (Is there a guide to elisp functions anywhere? The Lisp reference didn't include the Common Lisp emulation library, and I never did find an equivalent to the clojure filter()). Anyway, here's what I added to my .emacs: (defun find-ext-for-mode (m) (let (modes) (dolist (ext auto-mode-alist modes) (if (eq (cdr ext) m) (add-to-list 'modes (car ext)) ; (find-ext-for-mode 'clojure-mode) (defun is-clojure-buffer (b) (let ((regexes (find-ext-for-mode 'clojure-mode))) (find-if (lambda (regex) (string-match regex (buffer-name b))) regexes))) (defun add-slime-mode-to-existing-buffers () (interactive) (let ((clojure-buffers (remove-if-not 'is-clojure-buffer (buffer- list (dolist (b clojure-buffers) (set-buffer b) (slime-mode (eval-after-load 'slime '(add-slime-mode-to-existing-buffers)) Let me know if you add it to your repository. There could conceivably be some issues with multiple slime connections, or with running slime-mode repeatedly on the same buffer. I couldn't find any easy way to determine if a buffer already had slime-mode -- love to hear from someone who is actually handy with elisp! On Feb 13, 4:39 pm, Phil Hagelberg wrote: > David writes: > > I have a small problem with clojure-mode in your setup. > > > Since clojure-mode is autoloaded, it, and SLIME, aren't available > > until I load a '.clj' file. > > Starting SLIME, though, doesn't add the SLIME menu to the previously > > loaded '.clj' buffer > > (Newly loaded files get the menu, as they should). > > Yeah, I've thought about a hook that runs after SLIME loads to activate > slime-mode for all pre-existing clojure-mode buffers; just haven't > gotten around to it. > > If you're handy with elisp, I'd love a patch, otherwise I'll get around > to it eventually. =) > > -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 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: My SLIME installation diary
On Feb 18, 6:34 pm, Phil Hagelberg wrote: > David writes: > The Elisp CL emulation package is documented in its own top-level Info > node for some reason rather than in the Elisp manual. Almost certainly historical -- it must be a later, separate development. It really should be listed in the 'More Manuals' submenu of the Help Menu, though -- that's where I looked for documentation. It never occurred to me that there would be some other elisp manual someplace else (and my Internet connection was dead -- very frustrating). > Cool! It's a little simpler to check for the value of the major-mode > local variable rather than to use the filename, so here's what I ended > up with: > > (defun clojure-enable-slime-on-existing-buffers () > (interactive) > (dolist (buffer (buffer-list)) > (if (equal '(major-mode . clojure-mode) > (assoc 'major-mode (buffer-local-variables buffer))) > (with-current-buffer buffer > (slime-mode t) Well, that's simpler! > Thanks for getting the ball rolling on this. Glad to help, -dms --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Internal structure of evaluation results
Every now and again I try to get serious about learning Clojure and every time I quit due to its documentation. I find it confusing. Nothing seems to be where it should be, there are almost no examples etc. So, every time I end up writing (in Java, I might add) a documentation browser with index, full-text search support, bookmarks (something similar to Eclipses help system or kchmviewer) and maybe a possibility of adding custom examples to meta :doc with aspiration of building a personal tutorial as I go along. I can't seem to find a way of obtaining that information from Clojures runtime in a "standard" manner, however. I tried tackling the 'problem' with evaluating a (map meta (reduce concat (map vals (map ns- publics (all-ns) and then parsing the result using Clojures java classes. I can do that without major problems. But I'm tired of doing it every time when some (sub)results type gets changed (the last one was from LazyCons to LazySeq) and I naively update everything from the SVN. Is there any guarantee with regard to the internal structure of evaluation results (speaking in Java terms)? If not, is there something planed to that effect for official release(s)? Alternatively, what's the best (quickest, most robust, ...) way of obtaining Clojures runtime info in a manner similar to this: Map // keys == distinct namespace names interns: Map // keys == distinct intern or public names meta: Map (or Map> for the sake of arguments ;-) ) // keys == meta names in a sentence: something that could be parsed from within Java using java.lang.String and Java collection classes? Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Internal structure of evaluation results
Thanks for the link, Mark. I'll look into the contents.
What I'm talking about, though, is not that there is no documentation,
but rather I can't find my way around it very well. I only get around
to Clojure every so often and I find I forget a lot, so I'd have to go
through practically all the docs every time to refresh my memory.
That's quite a lot of docs to go through, mind you. And usually I
leave off before I can get to serious work. Or, right in the middle of
it I get frustrated and start working on the help browser. I don't
finish it of course, and then I leave things be for a couple of
months. It's a vicious circle, from my standpoint.
I know, the fault is entirely mine. I'm so used to full-text search
with highlighted results that I find everything less than that...
well... unsatisfactory.
For example: I know that there is a meta data one can obtain from
objects, so I type
user=>(find-doc "metadata")
and get, among other things
clojure/meta
([obj])
Returns the metadata of obj, returns nil if there is no metadata.
Great!, Let's try it:
user=> (meta meta)
nil
Ups! Let's try again:
user=> (meta 'meta)
nil
Erm. Let's try yet again:
user=> ^#meta
java.lang.Exception: No dispatch macro for: m
java.lang.Exception: ReaderError:(17,1) No dispatch macro for: m
at clojure.lang.LispReader.read(LispReader.java:160)
etc.
OK. Final try:
user=> ^#'meta
{:line 142, :doc "Returns the metadata of obj, returns nil if there is
no metadata.", :file "boot.clj", :ns #, :name
meta, :arglists ([obj])}
Allelluyah! But... if such an example would be right there in the docs
I got with the (find-doc "metadata"), I'd get where I want to be in 10
secs instead of a couple of minutes.
Regards,
David
P.S. Joshua and Laurent, thanks for your explanations, too.
On Mar 1, 9:34 pm, Mark Volkmann wrote:
> On Sun, Mar 1, 2009 at 2:15 PM, David wrote:
>
> > Every now and again I try to get serious about learning Clojure and
> > every time I quit due to its documentation. I find it confusing.
> > Nothing seems to be where it should be, there are almost no examples
> > etc.
>
> There are lots of examples in the article I wrote
> athttp://www.ociweb.com/mark/clojure.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Internal structure of evaluation results
On Mar 2, 12:37 pm, Mark Volkmann wrote: > Are you saying that you wanted the metadata of the meta function? No, I just used it to illustrate that the Clojure documentation is not as well organized and intuitive as some would have us believe. Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Internal structure of evaluation results
On Mar 2, 3:04 pm, Michael Wood wrote: > I don't think David is having trouble finding the documentation for > meta. He's complaining that the output of (doc meta) does not tell > you that you need to use (meta (var meta)) instead of (meta 'meta) or > (meta meta). Something like that, yes. Now, if the :doc in question contained "for example (meta (var something))" it would've been user friendlier. At least for newcomers like me who don't know that "obj" (in the meta :doc) really means "var". The more I think of it, the more I realize that :doc is not the best way of describing what it contains. I'd say it's more like :ref (as in reference). If you're a seasoned Clojure (OK Lisp) programmer, you quickly grasp onto the meaning, but if you're an old fashioned Java one, you might need more. So... Here's a proposal: break the existing :doc into :ref, :exmpl and :doc. Or even some sort of :xdoc containing an XML structured data (including real-world examples), which one could transform (using XSLT) into human-readable format (including colours, bold text, and other eye-catching rendering tricks) tailored also for IDE usage. Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Adding implicit indexing to Clojure lists and arrays?
(defn indexed "Returns a lazy sequence of [index, item] pairs, where items come from 's' and indexes count up from zero. (indexed '(a b c d)) => ([0 a] [1 b] [2 c] [3 d])" [s] (map vector (iterate inc 0) s)) -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: ClojureScript 0.0-1877 (Breaking change)
A large percentage of tests for my core.async based library are failing. Any thoughts? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Code re-use in Speclj
"context" might be what you're looking for. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Code re-use in Speclj
You can also use let instead of with. If you have multiple tests inside let wrap them in a context call. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Looks cool. I'll be sure to check it out. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
stch.schema a Prismatic Schema fork
Please check out the repo README page for motivations and differences. Thanks so much to the Prismatic people for open sourcing Schema. It's awesome and I love it. Some of my changes seemed too different to even consider a pull request, so I decided to create my own fork. All feedback is welcome. https://github.com/stch-library/schema -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: stch.schema a Prismatic Schema fork
Thanks for pointing that out. Changed defn*, defrecord*, fn*, letfn* to defn', defrecord', fn', and letfn'. Added tests for fn' and letfn'. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] stch.routing 0.1.1
I'm really excited to announce stch.routing. This library is similar to Compojure in purpose, but is much different in use. It is based off ideas from bulletphp.com. The overall objective is concise routing of Ring requests. Feedback is very much appreciated. Full documentation, examples, and example site can be found at https://github.com/stch-library/routing. Add the following to your project dependencies to use: [stch-library/routing "0.1.1"] BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] stch.dom 0.1.0 - A new jQuery-like DOM manipulation library for ClojureScript
https://github.com/stch-library/dom Add the following to your project dependencies to use: [stch-library/dom "0.1.0"] BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] stch.html 0.1.0 - A brand new library for HTML generation that supports Clojure and ClojureScript
Announcing stch.html. A library for HTML generation that supports Clojure and ClojureScript. Based on ideas from Hoplon. Feedback is welcome. Full documentation and examples can be found at https://github.com/stch-library/html. Add the following to your project dependencies to use: [stch-library/html "0.1.0"] Example code: (defhtml main [users] (html5) (html (head (title "My Page")) (body (section (header (h1 "Users")) (ul :id "users" (for [x users] (li x (footer "Copyright 2014" BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] stch.schema 0.3.3 - Optional type annotations and type checking
Changes in 0.3.x: 1. Fixed a bug with the documentation generated for multiple arity fns. 2. Replaced eq, pair, one, optional, record, protocol, pred, and enum with Eq, Pair, One, Optional, Record, Protocol, Predicate, and Enumerate, respectively. 3. Moved utility functions to separate project. stch.schema is on Clojars as well. Add the following to your project dependencies to use: [stch-library/schema "0.3.3"] BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] stch.schema 0.3.3 - Optional type annotations and type checking
Forgot github link: https://github.com/stch-library/schema -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] stch.html 0.1.0 - A brand new library for HTML generation that supports Clojure and ClojureScript
0.1.2 released.
class attribute can be a string, set, or sequential type now.
(->html (div :class "big bold"))
; ""
(->html (div :class #{"big" "bold"}))
; ""
(->html (div :class ["big" "bold"]))
; ""
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ANN] stch.sql 0.1.0 - A DSL for SQL query, DML, and DDL
I'm excited to announce stch.sql. A library for generating JDBC compatible
SQL statements. Based on code from Honey
SQL<https://github.com/jkk/honeysql>and ideas from
Lobos <http://budu.github.io/lobos/> and
SQLingvo<https://github.com/r0man/sqlingvo>.
Many thanks to the authors of those libraries.
Full documentation and examples can be found at
https://github.com/stch-library/sql.
Add the following to your project dependencies to use:
[stch-library/sql "0.1.0"]
Example code:
(-> (select :users.name
:contacts.*
'(date_format dob "%m/%d/%Y"))
(from :users)
(join :contacts
'(= users.id contacts.userid))
(where '(in users.status ["active" "pending"]))
(group :users.status)
(order-by (asc :contacts.last-name))
(limit 25)
(sql/format :quoting :mysql))
(create
(-> (table :users)
(integer :userID :unsigned :not-null)
(integer :orgID)
(set' :groups ["user" "admin"] (default "user"))
(enum :status ["active" "inactive"])
(decimal :ranking '(3 1) (default 0))
(varchar :username [50])
(chr :countryCode [2] (default "US"))
(primary-key :userID)
(index [:userID :orgID])
(unique :username)
(foreign-key :orgID '(orgs orgID) :on-delete-cascade))
(engine :InnoDB)
(collate :utf8-general-ci))
(alt
(-> (table :users)
(add (varchar :email [50]) (after :userID))
(add (varchar :firstName [25]) :first)
(add (index [:firstName :lastName]))
(add (index '(username ranking)))
(add (foreign-key :orgID '(orgs orgID) :on-delete-cascade))
(change :username (varchar :username [100]))
(drop-default :ranking)
(set-default :ranking 1)
(drop-column :countryCode)
(drop-index :uname)
(drop-primary-key)
(drop-foreign-key :fk1)))
BTW, I'm currently looking for work as a Clojure developer. If you like
what you see, please hit me up.
David
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
REPL Reloaded
I'd like to introduce stch.ns. What is stch.ns? In short, it's a namespace utility for reloading modified files that's designed to be used in a REPL. Now you may be thinking we already have tools.namespace, so what's the big deal. Here are some differences: 1. Aliased namespaces are preserved upon reloading. 2. If you 'use'd a namespace previously, stch.ns attempts to reload the namespaces using 'use' instead of 'require.' 3. Only the project's src directory is checked by default. This can be modified, of course. 4. Any exceptions that are thrown while trying to reload a namespace are return in the result map under the 'exceptions' key. Each key/value pair represents the namespace and the corresponding exception message. This turns out to be really convenient, alleviates a call to clojure.repl/pst, and also allows for multiple exceptions to be caught in namespaces that don't depend on one another. All the features that make tools.namespace great, like generating a dependency graph are still there. As are some of the issues inherent in reloading namespaces (e.g., records and protocol fns). Project page can be found here: https://github.com/stch-library/ns To use, add the following as a dependency to your lein user profile in ~/.lein/profiles.clj: [stch-library/ns "0.3.0"] Enjoy. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: REPL Reloaded
BTW, I'm currently looking for work as a Clojure developer. If you like what you see, please hit me up. David -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] clj.jdbc 0.1.0-beta5
Looks nice. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Callbacks as Sequences
I'm not to clojure/clojurescript and was wondering if anyone has taken a crack at writing a macro that transforms callbacks into a sequence. There is an awesome implementationion in LispyScript show here: https://gist.github.com/santoshrajan/3715526. Thanks for help. David -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Callbacks as Sequences
I've seen that and think it's awesome. This would be used for Node.js. I whipped this up to show what a Clojure version might look like. Basically each body form after the first is inserted where (cb) is found in the previous form. ; Definition (defmacro defseq [fn-name params & body]) ; Example usage (defseq request-handler [req resp] ((. resp (set-header "Content-Type" "text/html")) (exists "some-file.txt" (cb))) (fn [exists] (if exists (read-file filename "utf8" (cb)) (. resp (end "File Not Found" (fn [err data] (if err (. resp (end "Internal Server Error")) (. resp (end data) On Wednesday, February 6, 2013 2:13:33 PM UTC-5, Max Penet wrote: > > Hi, > > jayq includes something similar (nicer imho). It takes the form of a let > like construct > > (let-deferred > [a (jq/ajax "http://localhost:8000/1.json";) > b (jq/ajax "http://localhost:8000/2.json";)] (do-something-with-result > (merge a b foo))) > > It also supports :let and :when intermediary steps. > > more examples can be found here: > https://github.com/ibdknox/jayq#jayqmacros-source > > and the macro: > https://github.com/ibdknox/jayq/blob/master/src/jayq/macros.clj#L15 > https://github.com/ibdknox/jayq/blob/master/src/jayq/core.cljs#L516 > > > Max > > On Wednesday, February 6, 2013 7:45:36 PM UTC+1, da...@dsargeant.comwrote: >> >> I'm not to clojure/clojurescript and was wondering if anyone has taken a >> crack at writing a macro that transforms callbacks into a sequence. There >> is an awesome implementationion in LispyScript show here: >> https://gist.github.com/santoshrajan/3715526. Thanks for help. >> >> David >> > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
String interpolation in ClojureScript
Why does ClojureScript support string interpolation for js* and not regular
clojurescript strings? Interpolation would be very useful.
(def x "hi")
(js* "alert(~{x});") => "hi"
(js/alert "~{x}") => "~{x}"
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: ClojureScript release 0.0-1798
Please don't forget to run "lein cljsbuild clean" after upgrading, assuming you're using the cljsbuild lein plugin. Hope this saves someone some valuable time :) David -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Emacs - marmalade package install and .emacs file entries
I'm using GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600)
of 2011-03-10 on 3249CTO
Here's the relevant section of my init.el
(load "package")
(add-to-list 'package-archives '("marmalade" . "http://marmalade-
repo.org/packages/"))
(package-initialize)
I've got to load "package" explicitly to prevent a warning about a
nonexistent var: package-archives.
I have to call (package-initialize) explicitly.
Hope this helps,
-dms
--
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: Enclojure for Clojure 1.2
Have you been able to "Build with Dependencies"? I haven't been able to figure this out yet - though I suspect it's my inexperience with Maven. On Nov 17, 8:28 pm, Ken Wesson wrote: > On Wed, Nov 17, 2010 at 3:54 PM, Harrison Maseko wrote: > > Does Enclojure support Clojure 1.2 yet? > > Yes. I've been using Clojure 1.2/Enclojure 1.4/NB 6.9.1 for the past > few weeks myself. -- 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
if-let bug
Consider the two definitions: (defn if-let-good [str] (if-let [rest (seq (drop-while (partial = \a) str))] (first rest) "empty")) (defn if-let-bad [seq] (if-let [rest (seq (drop-while (partial = \a) seq))] (first rest) "empty")) The only difference between them is the name of the arg: "str" in the good definition, "seq" in the bad definition. (if-let-good "") => "empty" (if-let-bad "") aborts with: java.lang.String cannot be cast to clojure.lang.IFn [Thrown class java.lang.ClassCastException] -- 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: if-let bug
Nevermind - it was late, and I found the error message cryptic. Sorry for throwing up a red herring. On Jan 5, 5:30 am, Alessio Stalla wrote: > On Wednesday, January 5, 2011 11:06:34 AM UTC+1, David wrote: > > java.lang.String cannot be cast to clojure.lang.IFn > > [Thrown class java.lang.ClassCastException] > > Clojure is a Lisp-1: it has a single namespace for functions and variables. > If you call your parameter seq, you're shadowing the definition of the seq > function (and trying to call the seq parameter as a function, which is the > source of the exception you're getting). -- 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: ANN: A simple scheme interpreter in clojure
Line 86 of core.clj is: (list 'cadr caddr) and should be: (list 'caddr caddr) On Jan 23, 9:45 pm, dennis wrote: > I have implemented a simple interpreter in clojure,it is just > transformed from the interpreter in SICP.Maybe someone interested in > it. > > I have pushed it on github athttps://github.com/killme2008/cscheme > ,you can clone and run it by yourself. -- 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: Release.Next Version Number
On Thu, 2011-02-24 at 11:33 -0500, Steve Miner wrote: > The choice boils down to whether or not you want to follow Semantic > Versioning [1]. Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have > equivalent policies. Personally, I think it's a perfectly logical approach > to increment the major version number for any backwards incompatible change. > > Python officially has a more relaxed interpretation [5]. My understanding is > that in practice the Python community was very concerned about backwards > compatibility among the late 2.x releases because 3.0 was going to introduce > big changes. > > > Python versions are numbered A.B.C or A.B. A is the major version number – > > it is only incremented for really major changes in the language. B is the > > minor version number, incremented for less earth-shattering changes. C is > > the micro-level – it is incremented for each bugfix release. > > The Wikipedia article on software versioning [6] covers some other concerns > such as marketing. I guess that takes into account the idea that "2.0" > should be a major improvement. > > As I said, I personally like the concept of semantic versioning. If Rich > wants to do something else, I can live with an incompatible 1.3. In any > case, it would be useful for the Clojure Core team to document the Clojure > version policy. > > > > [1] http://semver.org > > [2] http://apr.apache.org/versioning.html > > [3] http://wiki.eclipse.org/index.php/Version_Numbering > > [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > > [5] > http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work > > [6] http://en.wikipedia.org/wiki/Software_versioning > I agree. One thing we should keep in mind is that if we're going to follow semantic versioning, we should not plan *any* backwards-incompatible changes in the near future. In other words, after 2.0, we should be done changing the language for a while, or we'll risk bumping major versions on every release. -- 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: Release.Next Version Number
Part of my underlying concern is one of branding and not directly based on concerns about measuring and/or quantifying the quality of an ecosystem. I fully recognize that we could call the next iteration of Clojure "2.0" and would be well within our rights. My point has been that calling it 2.0 may give people the impression that developing in the language is seamless and well-polished. When they find out that it's not, Clojure may experience some backlash. (What's more, if Clojure wants to continue adding backwards-incompatible features at the same rate that it is now, it would not be advisable to bump the major version just yet.) That said, I don't have a real problem saying the language itself is 2.0-worthy. David On Thu, 2011-02-24 at 11:45 -0500, Dennis Crenshaw wrote: > What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable > to make a standard out of it. To quote Peter Drucker, "What gets > measured gets managed." Are there any solid examples of languages that > would constitute a good canonical spectrum for ecosystem versions and > why? > > It seems like if the ecosystem surrounding a language is another > concern in the semantic versioning equation that can't be sufficiently > be expressed by the existing scheme, there should be a another > digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0 > or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may > mean, ecosystem surrounding it.) > > My points may also be a moot point, since it seems to make this SemVer > compatible we might have to call it SemVer 1.1.0, or 2.0 depending on > how people thought the extra digit(s) would affect the compatibility > with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?) > > All this being said, I like the idea of semantic versioning and I wish > more languages/software at least attempted some sort of version number > scheme transparency. #(+ 1 %) to semantic versioning. > > TL;DR Can an ecosystem be properly versioned? Can that version be > cleanly expressed by the current SemVer scheme? > -- 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: Readable names
On Nov 10, 3:50 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > > With this in mind it surprises me ( and disappoints a little ) that > > there are still abbreviated function names in many places - aget, > > aset, assoc, conj, coll?, comp, and so on. Is there any need for > > this in the 21st century? > > I think so, but I understand this is somewhat subjective. It is useful > to look at the 'competition' here (from random other languages): > > array-get -> [] > associate -> put > conjoin -> add > compose -> . > > I don't see people coming from a language where array access is [] > feeling good about the verbosity of array-get. You're right. We don't. Not only that. I can't think how aget instead of [] (and all the similar verbosity, as it were) fits into "Almost no syntax" and "Core advantage still code-as-data and syntactic abstraction" of the "Lisp is a good thing" section of the (current) Clojure rationale. While "Almost no syntax" may be a good thing for the development of Clojure itself, from my point of view a[5] is less "syntax" than (aget a 5). I'm not saying my opinion won't change. Through everyday usage it probably will, but it'll take longer than it would have if the "syntax" had been a little bit friendlier. Which brings me to another issue: I bet that for newcomers, non-abbreviated names would make a transition to Clojure a lot smoother. Now, such thinking caused quite a reaction from established "believers" as I can see. Which leaves us with only one option: make both notations possible / available. This is by no means a new invention (see "man less" -> OPTIONS for example). Which, yet again, brings me to another issue: switching between the two "perspectives" in a decent IDE should be a click of a button (or a key-press) away: an extended pretty-printer/formatter if you will. There, I've said it. I. D. E.. Without it the whole thing (Clojure, that is) is in danger of remaining (merely) academic, joining a long line of other Lisps. Not even Smalltalk(s), with somewhat "more of a syntax" yet still close to "code-as-data", could escape this fate. > put and add have imperative connotations that don't fit what assoc and > conj do, so using them would only confuse people more. Confusion is in the eyes of the beer-holder, right? I bet newcomers would feel less confused looking at "verbosity" than "almost-no-syntax- code-as-data". At least for the duration of the transition period. > IDEs can be great, but having to rely on them is a real problem. > People stumble over Lisps due to editors without adequate paren > matching, and if my experience with Clojure users is a guide, people > tend to try to stick with the editor they already know, leaving them > waiting for specific language support. Adding completion to the > 'things your editor must do before you can write Clojure effectively' > sets a high bar. It does, yes. Which is why "project Clojure" should have it's own IDE (not only a REPL). > > Using full words as function names leads to more readable code .. > > which can only be a good thing. > > They do only to a point, and then the code gets larger and harder to > scan, lines spill etc. Which should be a matter of one click (key-press) as I explained above. > Well, people have to learn something new when they approach a new > language. I'm not sure associate or conjoin would be more readily > understood without some background on persistent immutable data > structures. But at least it's not a lot of arbitrary syntax and > associativity rules, and most of the short names are true > abbreviations. Short names are one way Clojure can compete for brevity > with languages that get their brevity from syntax. If it's only brevity that you're after then aget could be abbreviated still, I guess: ag anyone? > IMO, it's more > approachable than Haskell, Erlang, Scala or any of the ML variants. > > array-get, associate, conjoin and compose etc are all still available. > I wonder - would people use them if they were provided as aliases? I > know I wouldn't. The vocabulary of seqs and collections is so small. > While I appreciate the approachability argument, a language is > ultimately for its practitioners. Right. Potential practitioners however, can get scared away not only by their own "fears" (taking root at least in part in the aforementioned abbreviations), but by their bosses' ones also. If Clojure isn't widely accepted, in the development community as well as in the IT marketing, it's hard to imagine programmers brave enough to confront their bosses with "We'll do it in Clojure!". It's a vicious circle. Maybe a bit more flexibility on the Clojure side could help break it. > I imagine there are those that wish > assoc/conj/apply et al were even shorter, or dedicated symbols... Maybe not only dedicated symbols but a bit more syntax, too. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure"
Re: Readable names
On Nov 12, 1:40 pm, "Michael Wood" <[EMAIL PROTECTED]> wrote: > Your hypothetical IDE, could provide what you want whether or not > longer aliases exist. There's nothing stopping someone from writing > an IDE that converts aget to array-get or [] when it reads in a file > and does the opposite when it writes it. On Nov 12, 1:47 pm, Dave Newton <[EMAIL PROTECTED]> wrote: > --- On Wed, 11/12/08, David <[EMAIL PROTECTED]> wrote: > > > You're right. We don't. Not only that. I can't think how aget > > instead of [] (and all the similar verbosity, as it were) fits > > into "Almost no syntax" and "Core advantage still code-as-data and > > syntactic abstraction" of the "Lisp is a good thing" section of the > > (current) Clojure rationale. > > The "almost no syntax" part is because (aget a 5) introduces no additional > syntactical elements, whereas a[5] does. That doesn't mean it's better or > worse, it just means there's less syntax. > > > [...] from my point of view a[5] is less "syntax" than (aget > > a 5). I'm not saying my opinion won't change. > > We're just using different definitions of syntax. The Lispy idea of syntax is > that everything looks like same: (fn-or-special-form args). a[5] breaks that > regularity, value judgments aside. That's why I put my "syntax" in quotes. From my chair having almost no syntax is a non-issue. I'd trade in syntax smallness for readability any time. > > There, I've said it. I. D. E.. Without it the whole > > thing (Clojure, that is) is in danger of remaining (merely) > > academic, joining a long line of other Lisps. Not even > > Smalltalk(s), with somewhat "more of a syntax" yet still > > close to "code-as-data", could escape this fate. > > That, IMO, had absolutely nothing to do with IDE support. Smalltalk IDE's of > the day blew everything else out of the water (as did many of the Lisp IDEs) > and it's only relatively recently that we're seeing similarly-functional > non-Lisp/Smalltalk IDEs. Maybe I wasn't clear enough. I wasn't implying that having IDEs is the only factor in making it in the real world. I'm just saying that not having them doesn't improve the odds. > > If it's only brevity that you're after then aget > > could be abbreviated still, I guess: ag anyone? > > There's "terse", and there's "concise". I know you're attempting humor, but > IMO there's a difference between "association"/"assoc" and "assoc"/"a" in the > amount of information being lost in each pair. Nothing stopping anybody from > writing "verbose mode" macros. Michael also stated (see above) that nothing was stopping anyone from doing anything. Surely you're not proposing that we all write our own IDEs and/or macros? That would really make .cjls more colourful. It would, however, also make them unmaintainable. Take a look at the following code, for example: http://www.cs.bgu.ac.il/~omri/Humor/verbose-c.html Now think away the macros for a moment... No, I think that, if at all, we need a single set of macros. As far as the IDEs are concerned, if we all try "inventing" our own (or plugins for the existing ones), they will all be half-done at best. It's better to focus on one project than spread the effort across several ones. At least until the developer base is large enough to be able to afford such a distribution. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: POLL: Domain name for project hosting site.
I'm not in favour of slangish derivatives. They're good for code- names, but when you get serious, a silly name is an obstacle. First of all, pronunciation descriptors after the name are down-right silly. People start making remarks that you sound like a Wikipedia article. Moreover, it's hard to make a good pitch when you get stuck on a name before the actual pitch begins. Clojure is no different, BTW. "No, sir, it's actually pronounced cloe-shur, like closure with an ess. This way we'll be able to tell it apart from Java closures due in one of the next releases of the JVM. No, not ass. Ess. Let me write it down for you. ..." That being said, why can't clojure.org be used for that purpose? If I remember correctly, all it takes is some DNS magic, and we have a, say, project.clojure.org. Hosted on another physical machine, if need be. On Nov 17, 8:52 pm, Drew Crampsie <[EMAIL PROTECTED]> wrote: > Hey All, > > I've finally found some time to start getting the project hosting site > together, and i need a name.. so lets put it to a vote. > > Here are some suggestions so far, but please feel free to chime in > with your own as well. > > - projecture > - clojr > - proj4cloj > - clojforge, cloforj, > - forj > - clojects > - clojury > - openjure > > Thanks for the help Clojurians! > > Cheers, > > drewc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Lazy living, without variables
Hi, On the subject of with-local-vars, I noticed that I could use @ to deference them in addition to var-get. Is that intended behaviour? I didn't see it documented anywhere. -- 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: jEdit Mode for Clojure
Hi, just saw this thread. I had made some modifications to the edit mode and uploaded it for inclusion (as a patch) here: http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&group_id=588&atid=300588 . I haven't checked the status in a while as my internet is very intermittent ATM. Please let me know if there is anything missing from it or if I can in any way enhance the mode. Kind Regards, David. 2008/12/11 Randall R Schulz > > On Thursday 11 December 2008 10:34, Daniel Spiewak wrote: > > It's been too long since I've looked at this thread... > > > > I took a look at the mode you linked. My mode is quite a bit more > > powerful, particularly with the changes I added today. ... > > Where do we find your latest version? Or do you want / need to refine it > further? > > I never really thought I'd go back to jEdit, but Enclojure's still > broken and Peter's just getting started on his IDEA plug-in. > > > > Daniel > > > Randall Schulz > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: jEdit Mode for Clojure
Daniel, To be honest, the colours are the least important, much more relevant is that structures are recursed properly and that the base language is defined. Let me know how you get on refining your mode and I'll have a look. When we have agreed on something I can update the jedit patch so we have the best superset in the editor. Does it sound like a plan? Kind Regards, David. 2008/12/12 Daniel Spiewak > > Which highlighting does it use? > > Daniel > > On Dec 12, 5:10 am, blackdog wrote: > > If anyone on this thread is interested I uploaded clj-jedit.tar.gz to > > the group file section on an incompletejeditplugin for clojure. It > > has the hilighting, repl, and namespace browser (courtesy of enclojure) > > - anyone want to take it on and improve it, I don't have time right > > now?? It was based on the scheme plugin. > > > > bd > > > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) > > > > > > > > Daniel Spiewak wrote: > > > > > I merged in all the interesting stuff from David Moss's ClojurejEdit > > > mode. We do highlight things in very different colors, but all of the > > > elements that his recognizes are also recognized by mine now. Also, I > > > fixed the annoying issue with def: > > > > > (def this)(def that) > > > > > The above now highlights correctly. > > > > > Feedback is welcome. I'm certainly willing to change the way things > > > are highlighted, add highlighting or remove it. > > > > > Daniel > > > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > > > Hi, just saw this thread. I had made some modifications to the > > > > > edit mode and uploaded it for inclusion (as a patch) > > > > > here: > http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... . > > > > > > > I haven't checked the status in a while as my internet is very > > > > > intermittent ATM. Please let me know if there is anything missing > > > > > from it or if I can in any way enhance the mode. > > > > > > I'll have to take a closer look at your new version. We probably > > > > should merge our efforts. Your mode does do some things that mine > > > > doesn't, and it doesn't really benefit anyone to have three > > > > competing Clojure modes. :-) My mode is pretty convoluted in the > > > > way it uses some tricks to highlight things like (def > > > > blah), so it's probably easier if I steal your improvements and > > > > merge them into mine. I'll give that a try later today and post > > > > back with the results. > > > > > > Daniel > > > > -- > > None are more hopelessly enslaved than those who falsely believe they > > are free — Goethe > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: jEdit Mode for Clojure
I've had a really quick look at your mode, it looks good, and I like the regularity in keyword highlighting. I'm going to have a proper look sometime later on the weekend and will get back to you when I have done. Kind Regards, David. 2008/12/12 Daniel Spiewak > > Sounds like a good plan. :-) At the moment, I think that what's in > the mode is pretty solid, meaning I don't have anything planned to > refine it further. (except for regexp syntax, which I don't know > anything about) So, if you want to evaluate it now, that'd be great! > > As a minor aside, I don't actually recursively parse S-expressions. > It's not a bad idea, but jEdit's weird treatment of eager-vs-lazy > matching sometimes gets in the way. Instead, I just define TYPE="OPERATOR">( and ). I don't > really know when I'm in an S-exp, but I don't think that's too much of > a limitation. The only exception to the above is my highlighting of > "blah" in (def blah 123). That's done with an EOL_SPAN_REGEXP which > delegates to a new ruleset. This ruleset then in turn delegates back > to main in the case where the S-exp is closed prior to the end-of- > line. It's not a normal idiom for jEdit highlighting modes, but it > seems to work fine. At least I didn't have to resort to *really* > bizarre tricks like I did in my SASyLF and ReST modes (opening a SPAN > that terminates on an assumed non-existent character, etc). > > Daniel > > On Dec 12, 1:15 pm, "David Moss" wrote: > > Daniel, > > > > To be honest, the colours are the least important, much more relevant is > > that structures are recursed properly and that the base language is > defined. > > > > Let me know how you get on refining your mode and I'll have a look. When > we > > have agreed on something I can update the jedit patch so we have the best > > superset in the editor. > > > > Does it sound like a plan? > > > > Kind Regards, > > > > David. > > > > 2008/12/12 Daniel Spiewak > > > > > > > > > Which highlighting does it use? > > > > > Daniel > > > > > On Dec 12, 5:10 am, blackdog wrote: > > > > If anyone on this thread is interested I uploaded clj-jedit.tar.gz to > > > > the group file section on an incompletejeditplugin for clojure. It > > > > has the hilighting, repl, and namespace browser (courtesy of > enclojure) > > > > - anyone want to take it on and improve it, I don't have time right > > > > now?? It was based on the scheme plugin. > > > > > > bd > > > > > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) > > > > > > Daniel Spiewak wrote: > > > > > > > I merged in all the interesting stuff from David Moss's > ClojurejEdit > > > > > mode. We do highlight things in very different colors, but all of > the > > > > > elements that his recognizes are also recognized by mine now. > Also, I > > > > > fixed the annoying issue with def: > > > > > > > (def this)(def that) > > > > > > > The above now highlights correctly. > > > > > > > Feedback is welcome. I'm certainly willing to change the way > things > > > > > are highlighted, add highlighting or remove it. > > > > > > > Daniel > > > > > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > > > > > Hi, just saw this thread. I had made some modifications to the > > > > > > > edit mode and uploaded it for inclusion (as a patch) > > > > > > > here: > > >http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... > . > > > > > > > > > I haven't checked the status in a while as my internet is very > > > > > > > intermittent ATM. Please let me know if there is anything > missing > > > > > > > from it or if I can in any way enhance the mode. > > > > > > > > I'll have to take a closer look at your new version. We probably > > > > > > should merge our efforts. Your mode does do some things that > mine > > > > > > doesn't, and it doesn't really benefit anyone to have three > > > > > > competing Clojure modes. :-) My mode is pretty convoluted in > the > > > > > > way it uses some tricks to highlight things like (def > > > > > > blah), so it's probably easier if I steal your improvements and > > > > > > merge them into mine. I'll give that a try later today and post > > > > > > back with the results. > > > > > > > > Daniel > > > > > > -- > > > > None are more hopelessly enslaved than those who falsely believe they > > > > are free — Goethe > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: jEdit Mode for Clojure
I been thinking about this during the weekend, and I think I prefer the mode to be aware of nesting (unless you can cause it to blow the stack on a large file or something, which I think would be unlikely anyway), so I'm going to take the keywords from your mode and bolt on the set structures I had in my mode, maybe changing them all to the same colouring. Will let you know when done (sometime later this week or so) so that you can have a look. I'm also thinking that regexps should have some highlighting... I may even push that into the Perl mode as it pisses me off greatly that regexps don't even know about variable substitution. Kind Regards, David. 2008/12/13 David Moss > I've had a really quick look at your mode, it looks good, and I like the > regularity in keyword highlighting. I'm going to have a proper look sometime > later on the weekend and will get back to you when I have done. > > Kind Regards, > > David. > > > 2008/12/12 Daniel Spiewak > > >> Sounds like a good plan. :-) At the moment, I think that what's in >> the mode is pretty solid, meaning I don't have anything planned to >> refine it further. (except for regexp syntax, which I don't know >> anything about) So, if you want to evaluate it now, that'd be great! >> >> As a minor aside, I don't actually recursively parse S-expressions. >> It's not a bad idea, but jEdit's weird treatment of eager-vs-lazy >> matching sometimes gets in the way. Instead, I just define > TYPE="OPERATOR">( and ). I don't >> really know when I'm in an S-exp, but I don't think that's too much of >> a limitation. The only exception to the above is my highlighting of >> "blah" in (def blah 123). That's done with an EOL_SPAN_REGEXP which >> delegates to a new ruleset. This ruleset then in turn delegates back >> to main in the case where the S-exp is closed prior to the end-of- >> line. It's not a normal idiom for jEdit highlighting modes, but it >> seems to work fine. At least I didn't have to resort to *really* >> bizarre tricks like I did in my SASyLF and ReST modes (opening a SPAN >> that terminates on an assumed non-existent character, etc). >> >> Daniel >> >> On Dec 12, 1:15 pm, "David Moss" wrote: >> > Daniel, >> > >> > To be honest, the colours are the least important, much more relevant is >> > that structures are recursed properly and that the base language is >> defined. >> > >> > Let me know how you get on refining your mode and I'll have a look. When >> we >> > have agreed on something I can update the jedit patch so we have the >> best >> > superset in the editor. >> > >> > Does it sound like a plan? >> > >> > Kind Regards, >> > >> > David. >> > >> > 2008/12/12 Daniel Spiewak >> > >> > >> > >> > > Which highlighting does it use? >> > >> > > Daniel >> > >> > > On Dec 12, 5:10 am, blackdog wrote: >> > > > If anyone on this thread is interested I uploaded clj-jedit.tar.gz >> to >> > > > the group file section on an incompletejeditplugin for clojure. It >> > > > has the hilighting, repl, and namespace browser (courtesy of >> enclojure) >> > > > - anyone want to take it on and improve it, I don't have time right >> > > > now?? It was based on the scheme plugin. >> > >> > > > bd >> > >> > > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) >> > >> > > > Daniel Spiewak wrote: >> > >> > > > > I merged in all the interesting stuff from David Moss's >> ClojurejEdit >> > > > > mode. We do highlight things in very different colors, but all of >> the >> > > > > elements that his recognizes are also recognized by mine now. >> Also, I >> > > > > fixed the annoying issue with def: >> > >> > > > > (def this)(def that) >> > >> > > > > The above now highlights correctly. >> > >> > > > > Feedback is welcome. I'm certainly willing to change the way >> things >> > > > > are highlighted, add highlighting or remove it. >> > >> > > > > Daniel >> > >> > > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: >> > > > > > > Hi, just saw this thread. I had made some modificatio
Re: Blogging About Clojure?
Lots of possibilities, but a simple solution is that you could find a hosting service that supports easy WordPress setup and pick a minimal theme that's to your liking. David On Tue, Dec 16, 2008 at 1:05 PM, Randall R Schulz wrote: > > Hi, > > Wordy though I am, I've never done any blogging before, but now that I'm > finally beginning to get up-to-speed on Clojure, I think I might have > some things to say. > > So I was wondering if anyone could recommend a good blog site for this > purpose? Naturally, I'll want to include source code, so it should be > able to present that easily and cleanly. Apart from that, I don't think > I need much in the way of fanciness. I'd prefer a site whose > presentation is clean and uncluttered. > > Does anyone have any recommendations? > > > Randall Schulz > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A quasiquote for Clojure?
You can have unresolved symbols within a macro with: ~'symbol David On Wed, Dec 17, 2008 at 3:30 AM, Meikel Brandmeyer wrote: > > Hi, > > I'd like to propose/put up for discussion a change to the unquote > handling. > I basically ran into the following problem: > > I'd like to embed a DSL into my system. Using macros it should be > possible > to define a language, which looks like usual Clojure. Simply quote the > form > and pass it to a function, which knows how to handle the commands. > > However I hit a roadblock. Coming from Scheme, I tried the following > approach. > > A hypothetical SQL embedding: > > (def x 5) > (sql col1 from table1 where col2 = ~x) > > Or a hypothetical cljsh (inspired by scsh): > > (def *cmd* "/usr/bin/command") > (run (~*cmd* -option 1 -another argument foo bar)) > > In Scheme this is done, by quoting the macros argument using the > quasiquote form. In Clojure, however, this style is not possible since > we are > missing quasiquote. Here a short list of examples on how the different > quotations work: > > (quote (foo ~x bar)) > => Failure in Clojure. > => In some Schemes: (foo (unquote x) bar), where , (aka. ~) translates > to some unquote form. It just quotes everything. Also the unquote. > > (quasiquote (foo ~x bar)) > => Not available in Clojure. > => (foo 5 bar) in Scheme > > (syntax-quote (foo ~x bar)) > => (assuming ` would have a syntax-quote form as ' does with quote) > (my.ns/foo 5 maybe.some.other.ns/bar) > => Not available in Scheme, AFAIK. > > So as you see, the above style is not possible, since in Clojure you > only > have the choice to be static or resolve all the symbols. If I want to > use > the style anyway, I have to jump through hoops and rewrite the quoted > form in my handler function, be it replacing somehow marked or named > symbols with values from the environment or be it renormalising all > the > symbols. (But what if the user injected a qualified symbol with ~?) > > So I came to the question of whether it is possible to include a > similar > quasiquote form, which does not resolve the symbols inside? It would > be a philosophy of "Unquote, what the user wants to be unquoted, and > leave the rest to me. I know how to handle it." > > And when were are at it: maybe also provide a syntax-quote, unquote > and unquote-splice forms? > > Finally, I skipped the obvious question: Does this make sense at all? > I like this way of including a sub-language. However, is it > "idiomatic"? > (for some definition of "idiomatic") > > Maybe there is already a different solution, which I just don't see at > the moment. > > 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 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: Blogging About Clojure?
For syntax highlighting in WordPress this is a good solution<http://wordpress.org/extend/plugins/wp-syntax/>. It was originally written to be used for the EmacsBlog so it should handle Clojure just fine. David On Fri, Dec 19, 2008 at 7:09 PM, Jason wrote: > > Hi Randall, > > I'm in the same boat: I just set up my first blog yesterday so I could > post some gotchas i've found and experiments i've done with clojure. > I went the route David suggests: dreamhost.com has a special now, $10 > for a domain and 6 months free hosting, and they have a one-click > wordpress install. I'm not sure how best to post code, but for now > simple seems to work OK. > > -Jason > > On Dec 16, 11:05 am, Randall R Schulz wrote: > > Hi, > > > > Wordy though I am, I've never done any blogging before, but now that I'm > > finally beginning to get up-to-speed on Clojure, I think I might have > > some things to say. > > > > So I was wondering if anyone could recommend a good blog site for this > > purpose? Naturally, I'll want to include source code, so it should be > > able to present that easily and cleanly. Apart from that, I don't think > > I need much in the way of fanciness. I'd prefer a site whose > > presentation is clean and uncluttered. > > > > Does anyone have any recommendations? > > > > Randall Schulz > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure and clojure-contrib github projects updated
Thanks! On Sat, Dec 27, 2008 at 2:01 PM, Kevin O'Neill wrote: > Hi all, > I've updated the github svn clones to pull from google code. I've also > pushed the 20081217 branch so it's now accessible from git. > > Any problems please let me know. > > -k. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Fibonacci sequence
> > (defn fib-helper [a b] > (fib-helper b (+ a b))) > > (defn fib (fib-helper 0 1)) ; This doesn't work either: (defn fib (fib- > helper '(0 1))) You're missing your argument list for fib. > (println (take 5 fib)) take creates a lazy list from a collection: (take n collection) Your fib does not produce a collection. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: why two list comprehensions are different?
> > Yes, but I think maybe there is a bug in Clojure that causes the first > case to "work" when it should give a syntax error. If it is not a bug > I do not understand why it ignores the expression. > It's not a "bug" in Clojure because Clojure doesn't really have syntax in the way that you seem to be referring to, and I assume that you mean this in the sense that Python has list comprehensions as a syntactical feature of the language. A list comprehension in Clojure is just a macro not any part of the "core" language so to speak. Much of Clojure is like this. The macro could do some sort of syntactical checking. But in this case it doesn't really seem like it's worth it. You could of course re-implement your own version of list comprehension that does incorporate this. Unlike Python where this is probably not realistic (you can't easily implement new Python syntax for yourself), Clojure being a Lisp makes this quite easy. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: newbie question!!
(:name @(first (:friends @bill))) You need to dereference before trying to access name. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: is it type hint?
Just made sense to me today as well.
#^Class
is short form for saying set the metadata for the symbol being defined (in
this case list) to the map {:tag Class}.
#^ is a reader macro for setting metadata for the compiler. That code is
simple tagging the symbol clojure/list.
(meta #'list)
will give you the map representing the metadata. :tag is used by the
compiler, but it's not clear to me in what cases...
On Fri, Jan 16, 2009 at 9:46 PM, wubbie wrote:
>
> Hi,
>
> is #^ type hint below? I don't see any type at all.
> It's from clojure core.
>
>
> (def
> #^{:arglists '([& items])
>:doc "Creates a new list containing the items."}
> list (. clojure.lang.PersistentList creator))
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Inheritance & multiple inheritance using structs
After a couple of days of hacking it's clear that Clojure can support OO
structures really, really, well. I've whipped up a little thing, jokingly
called CLJOS. I'm curious to know what people think. It's a fairly simple
affair combining structs, hierarchies, and some helper functions.
It's my first attempt at Clojure programming so I'm sure it could use some
cleanup, but it works. Of course open to any thoughts improvements etc. In
particular I'm using refs to deal with changes to the hierarchy and the
class initializers.
You can compose structs, here's a very nonsensical example:
;; multiple inheritance
(defclass beaver [object]
(:tail true))
(defclass duck [object]
(:bill true))
(defclass platypus [beaver duck]
(:marsupial true))
(def aplatypus (make-instance platypus))
(isaa? aplatypus ::duck) ;; yield true
(isaa? aplatypus ::beaver) ;; yields true
isaa? takes an instance and matches it against a fully namespaced keyword.
It supports default values for keys, they are overridden according to the
class hierarchy.
(defclass shape [object]
(:position [0 0]))
(defclass circle [shape]
(:radius 10))
(make-instance circle :raduis 20]) ;; creates struct -> {:position [0 0],
:tag :cljos-example/circle, :radius 20}
And it support a simple system for calling multimethods up the inheritance
chain simply by re-assigning the :tag.
(defmulti area :tag)
(defmethod area ::shape [s]
(print "Abstract method!\n"))
(defmethod area ::rect [r]
(print "Area of rect\n")
(area (super r))
(* (:width r) (:height r)))
http://github.com/swannodette/clojure-stuff/blob/d5df8ad710fdb139d78b95a41ab914c30db53d6d/cljos.clj
Of course it blows my mind that this can be done in less than 100 lines of
code (Clojure is amazing!). It seems to me a decent way to deal with OO
style coding if you want to stick with pure clojure and don't need the Java
interop of gen-class.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Inheritance & multiple inheritance using structs
Of course it might be the case that not many people are interested in the implementing ideas from CLOS for Clojure especially since there's a lot of exciting new functional ground to cover in Clojure first ;) I come from a UI background so I'm interested in the OO implications/possiblities of Clojure. In any case a couple half-thought out notes about make-instance performance characteristics: make-instance is about as fast as struct-map even tho it dynamically looks up key initializers (make sense since it's just a macro that unfolds into a struct-map). On a new MBP 2.4ghz you can allocate 1,000,000 instances (3 fields) in ~700ms. Same for struct-map. struct is a little less than 4 times faster it seems that struct-map. One possible optimization for make-instance would be to make make-instance automatically order all keys (seems like a bit of work especially with multiple inheritance). As a comparison using a hash-map directly gives another 3-4x performance increase. As a comparison of other implementations (probably not a fair one since CLOS does way more bookkeeping than my measly hack ;): SBCL instantiates 1,000,000 instances of a class with 3 fields in ~70ms (could get closer to ~250ms in Clojure with auto-ordering of keys, if the sorting algorithm was quick enough). Clozure CL 64 does the same in ~1.5secs. Cool stuff. Clojure is zippy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A couple of questions concerning syntax-quote
The multiple syntax-quote and unqote behavior above seems to work in Clojure just fine and like CL as well. On Mon, Jan 19, 2009 at 5:58 AM, Rock wrote: > > I'm trying to make the documentation (still awaiting approval) in the > "Learning Clojure" WikiBook regarding syntax-quote expansion as > accurate as possible (like in the CL HyperSpec). > > I've recently noticed something. In "The Reader" section of the > Clojure Reference, where it explains syntax-quotes, it says: > > "For all forms other than Symbols, Lists, Vectors and Maps, `x is the > same as 'x." > > Yet, I noticed that for *values* such as numbers, strings etc... > that's not exactly so. Let's expand a syntax-quote expression like the > following: > > `(x 5) ===> (clojure.core/concat (clojure.core/list (quote user/x)) > (clojure.core/list 5)) > > See the difference between what happens to the symbol x ===> (quote > user/x) and what happens to 5? > > It looks like `5 gets expanded to 5 and not (quote 5). Now I know that > they evaluate to the same identical thing. But what I'm interested in, > is the precise expansion algorithm. > > So my first question is: > > 1) Is it true that, for values, we have for instance `5 ===> 5 in a > syntax-quote expansion (not evaluation!). > > There's another thing I'm curious about. Syntax-quotes are there to > simplify such things as wiriting macros (especially) for us. Now I'm > trying to be rigorous in the docs so that everything is clear. But the > whole reason for syntax-quotes is to make life easier, so there's no > point in someone having to mentally expand those expressions every > time even if he/she knows the precise rules. > > Paul Graham discusses this in Ansi Common Lisp. He also illustrates > there an equivalent way of expanding backquote expressions which is > truly useful and possibly less confusing for a human mind especially > when dealing with notoriously difficult nested backquotes (or syntax- > quotes in our own terminology :-) ). I think it was taken from Scheme, > but I'm not certain. Anyway it's pretty simple and straightforward. It > works like this: > > "To evaluate a backquoted expression, you remove the backquote > and each matching comma, and replace the expression following each > matching > comma with its value. Evaluating an expression that begins with a > comma causes an > error. >A comma matches a backquote if there are the same number of commas > as > backquotes between them, where b is between a and c if a is prepended > to an expression > containing b, and b is prepended to an expression containing c. This > means that in a > well-formed expression the outermost backquote matches the innermost > comma(s). >Suppose that x evaluates to a, which evaluates to 1; and that y > evaluates to b, > which evaluates to 2. To evaluate the expression > > ``(w ,x ,,y ) > > we remove the first backquote and evaluate what follows any matching > comma. The > rightmost comma is the only one that matches the first backquote. If > we remove it and > replace the expression it's prepended to, y, with its value, we get: > > `(w ,x ,b) > > and if we evaluate that in turn we get: > > (w a 2)" > > That's Common Lisp notation so mentally replace commas with ~. It took > me some getting used too! :-) > > Now my other question is this: > > 2) Given that in Clojure a syntax-quote (`) doesn't just quote a > *symbol* but *resolves* it in the current context, would the above > method still be applicable or is it compromised because of this? > That's something that isn't clear to me yet. > > Thanks. > > Rock > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: is it type hint?
Thanks much.
On Mon, Jan 19, 2009 at 11:03 AM, Michael Reid wrote:
>
> On Fri, Jan 16, 2009 at 9:57 PM, David Nolen
> wrote:
> > Just made sense to me today as well.
> > #^Class
> > is short form for saying set the metadata for the symbol being defined
> (in
> > this case list) to the map {:tag Class}.
> > #^ is a reader macro for setting metadata for the compiler. That code is
> > simple tagging the symbol clojure/list.
> > (meta #'list)
> > will give you the map representing the metadata. :tag is used by the
> > compiler, but it's not clear to me in what cases...
> >
>
> The most common case where :tag is used by the compiler is to generate
> direct method calls into Java code rather than using reflection to do
> the call, which is much slower, e.g:
>
> (defn index-of [s substr]
> (.indexOf s substr))
>
> The call to String.indexOf will likely be compiled as a reflective
> call because in the general case, the compiler doesn't know that 's'
> and 'substr' are meant to be instances of java.lang.String. If however
> you add a couple of type hints:
>
> (defn index-of [#^String s #^String substr]
> (.indexOf s substr))
>
> Then the compiler will generate an optimized code path that directly
> invokes String.indexOf(String,String), and the other which will fall
> back to the reflective invocation. The reason that two code paths are
> needed is because Clojure is dynamically typed. Therefore it is
> perfectly legal to pass in any type of objects as the parameter in
> which case you want the call to .indexOf to succeed if the passed in
> instance does in fact have a method named indexOf that can accept
> 'substr' as its argument.
>
> To see where the compiler needs to help you can use the
> *warn-on-reflection* flag to ask for warnings where the compiler can't
> resolve the calls. See:
>
> http://clojure.org/java_interop#toc35
>
> for example usage.
>
> /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
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
-~--~~~~--~~--~--~---
#^ Reader Macro Issues was Re: function equivalents of macro characters
On Mon, Jan 19, 2009 at 12:24 PM, Chouser wrote: > > #^ - metadata > > #^ adds metadata at read-time, so there's no way for a function to do > exactly the same thing, though 'with-meta' does something similar at > runtime. > I've noticed this as well. It seems to me that this prevents you from dynamically defining a var (like in a macro) that has metadata attached to it or it's arguments (if it's a function). Is there no way around how the reader works? Can the reader delay processing #^ until after all macros have been expanded? Seems to me it could be useful behavior since one might want to dynamically create functions with tagged arguments and return values right? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: #^ Reader Macro Issues was Re: function equivalents of macro characters
Wow, nice! On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra wrote: > > On Jan 19, 1:15 pm, David Nolen wrote: > > I've noticed this as well. It seems to me that this prevents you from > > dynamically defining a var (like in a macro) that has metadata attached > to > > it or it's arguments (if it's a function). > > You can also use the new alter-meta! function, which works on > anything: > > - > clojure.core/alter-meta! > ([iref f & args]) > Atomically sets the metadata for a namespace/var/ref/agent/atom to > be: > > (apply f its-current-meta args) > > f must be free of side-effects > > > -Stuart Sierra > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: #^ Reader Macro Issues was Re: function equivalents of macro characters
Actually, so this can't be used on structs for fns? On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra wrote: > > On Jan 19, 1:15 pm, David Nolen wrote: > > I've noticed this as well. It seems to me that this prevents you from > > dynamically defining a var (like in a macro) that has metadata attached > to > > it or it's arguments (if it's a function). > > You can also use the new alter-meta! function, which works on > anything: > > - > clojure.core/alter-meta! > ([iref f & args]) > Atomically sets the metadata for a namespace/var/ref/agent/atom to > be: > > (apply f its-current-meta args) > > f must be free of side-effects > > > -Stuart Sierra > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: #^ Reader Macro Issues was Re: function equivalents of macro characters
Works. amazing. On Mon, Jan 19, 2009 at 4:51 PM, David Nolen wrote: > Actually, so this can't be used on structs for fns? > > On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra < > the.stuart.sie...@gmail.com> wrote: > >> >> On Jan 19, 1:15 pm, David Nolen wrote: >> > I've noticed this as well. It seems to me that this prevents you from >> > dynamically defining a var (like in a macro) that has metadata attached >> to >> > it or it's arguments (if it's a function). >> >> You can also use the new alter-meta! function, which works on >> anything: >> >> - >> clojure.core/alter-meta! >> ([iref f & args]) >> Atomically sets the metadata for a namespace/var/ref/agent/atom to >> be: >> >> (apply f its-current-meta args) >> >> f must be free of side-effects >> >> >> -Stuart Sierra >> >> >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Possible feature: consider aliases when reading namespace-qualified keywords.
My OO example from earlier deals with this case by completely removing any need to manually derive tags. This is done by having CLJOS keep it's own internal hierarchy (via make-hierarchy) rather than using the default one. By modifying metadata on the vars holding structs created by defclass (using alter-meta!) and tagging instances as described in existing Clojure literature you can provide functions to shuffle away the annoyance of dealing with keywords and their namespaces entirely. On Mon, Jan 19, 2009 at 7:29 PM, Jason Wolfe wrote: > > I've been doing some OO-type Clojure programming, and have run into > the following (quite minor) annoyance: > > I've defined a struct with a :class of ::Foo in namespace > my.long.namespace.foo. > > In another namespace my.long.namespace.bar, I want to define a > subclass of this struct. > In this namespace, I require [...foo :as foo], so that I can refer to > multimethods like foo/method1. > > However, it seems I'm still required to write > (derive ::Bar :my.long.namespace.foo/Foo) > when I'd like to write > (derive ::Bar :foo/Foo) > > I'm not sure if this is even feasible, since given my limited > experience it seems that aliases for symbols are handled at resolution- > time and not read-time, and that wouldn't work for keywords. On the > other hand, this state of affairs seems to be possibly-confusing and a > perhaps-needless difference between symbols and keywords. What do > others think about this? > > Thanks, > Jason > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Multimethod Reflection?
Looking at the multimethod implementation (MultiFn.java) I noticed that multimethod keeps an internal persistent map of dispatch values in a field call methodTable. It seems to me it would pretty simple to expose this field (or a copy of it anyway) so that multimethod reflection can take place. (responds? astruct amultifn) It's seems to me to be a minor change that would add a considerable amount of reflective power to multimethods, as well providing support for something like who-specializes in SLIME or any other IDE. Thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Multimethod Reflection?
Thanks! On Tue, Jan 20, 2009 at 7:28 PM, Rich Hickey wrote: > > > > On Jan 20, 6:48 pm, David Nolen wrote: > > Looking at the multimethod implementation (MultiFn.java) I noticed that > > multimethod keeps an internal persistent map of dispatch values in a > field > > call methodTable. It seems to me it would pretty simple to expose this > > field (or a copy of it anyway) so that multimethod reflection can take > > place. > > (responds? astruct amultifn) > > > > It's seems to me to be a minor change that would add a considerable > amount > > of reflective power to multimethods, as well providing support for > something > > like who-specializes in SLIME or any other IDE. > > > > Thoughts? > > Fine idea - try SVN 1219 ;) > > 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 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: struct question
Finally started a GitHub repo just for this project. http://github.com/swannodette/cljos/tree/master The earlier version of course was very flawed/buggy. OK start, but the macros in it were written with little/no understanding about how symbols are resolved into their namespaces in Clojure (or Lisp for that matter). If anybody is interested at all please feel free to fork or to leave comments. In particular I found no way to capture the symbols and their true namespaces without resorting to eval and some wacky macros. That said, it does indeed work. defclassed structs always refer to the namespace in which they were declared, and parents correctly reflect their originating namespace as well. New stuff: (instance-of? my-platypus platypus) (member-of? a-circle shape) No need for tags. The only time you need tags is when defining multimethods. There's no real clean way to get around this except implementing a macro around defmethod, and I'm not really sure creating a macro around defmethod is so hot. The discussion earlier about multiple hierarchies for multimethod, especially predicate support would solve this cleanly. defclass now returns the struct. I've also been toying around with an optional Smalltalk message based dispatch. Note the special applym, a special version of apply that first checks to see if a struct responds? to a multimethod. If not it checks to see if there is a proxy and forwards the message with the args to proxy. This could allow for some interesting interactions. (defclass my-spore-animal [platypus] (:third-eye true)) (defclass bacteria [object] (:digest-grass true)) (def my-spore (make-instance my-spore-animal)) (def my-parasite (make-instance bacteria)) (defmulti digest :tag) (defmethod digest ::bacteria [obj] (println "Munch munch!")) ;; we can pass messages to a proxy class (applym digest (assoc my-spore :proxy my-parasite)) ;; "Munch Munch!" The most exciting thing however is multimethod reflection (many thanks to Rich). The following is all the code it takes to see all the multifns that specializes a particular tag. In fact, really it should check all the ancestors of the tag as well in order and I'm open to suggestions on what the best way to implement that would be. (defn has-dispatch? [multifn tag] (not (= (tag (methods multifn)) nil))) (defn responds? [obj multifn] (has-dispatch? multifn (:tag obj))) (defn is-multi? [metadata] (and (:tag metadata) (= clojure.lang.MultiFn (:tag metadata (defn who-specializes-tag? [tag] (filter #(and (is-multi? (meta %)) (has-dispatch? (var-get %) tag)) (flatten (map #(vals (ns-interns %)) (all-ns) (defmacro who-specializes? [constructor] `(who-specializes-tag? (:class (meta (var ~(symbol (name constructor))) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: struct question
> > I am not entirely happy with this approach though. If everyone starts > to use metadata for various purposes, such type tags may well > disappear by some function replacing the metadata on an object > without preserving the tags that are already there. This is all the > more likely because there is nothing in the standard library to add a > tag to an existing metadata map. All there is is (with-meta ...), > which replaces the metadata map completely. > > Konrad. Permanently changing the tag of an object after instantiation probably isn't such a safe thing to do anyway. That's where functions like pose-as and applym can come in handy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: struct question
Can't some elements of the problem be solved with some form of predicate dispatching as proposed by Meikel? Predicate dispatching would allows us to use _anything_ as a type (i.e. structs themselves), as well as allowing user defined functions to do the matching instead of being limited to isa? and the global hierarchy. This of course has some performance implications I imagine... http://groups.google.com/group/clojure/browse_thread/thread/f8b1be403c927b03/438c21a80072a105?lnk=gst&q=hierarchy#438c21a80072a105 I have to say that I find the lack of a type system around structs to be fairly liberating. You can invent one if you need one, but you are not constrained by it. However, if somebody comes up with something like CLJOS as a set of handy macros, or extracts whatever parts they deem relevant, why not put that in clojure-contrib so that people can at least have something to use for the simple cases as pointed out by Konrad? On Thu, Jan 22, 2009 at 10:25 AM, Konrad Hinsen wrote: > > On 22.01.2009, at 15:26, Rich Hickey wrote: > > > It's pretty easy to write a trivial struct system, much harder to > > address performance, interop, compilability, dynamicity etc > > constraints. > > Indeed. > > > As a simple case, if a defstruct is re-evaluated, will objects created > > after that be of the same 'type' as objects created before? > > I'd say no, which resolves the next question: > > > What if fields have been added/removed? > > Anyway, I don't think that re-evaluation is a serious issue, except > in interactive development sessions. The typical use would be > defining a struct once and then not touch it any more. > > > I'd prefer people experiment with libraries built on the existing > > facilities, with an open mind as to the possibilities of categorizing > > things other than by their structure. > > The added flexibility of multimethods is quite appreciable in non- > trivial situations. But at the moment there is no simple way to > handle simple situations. Using structs is straightforward and > familiar from other languages. It is certainly not *the* solution to > categorizing, but it's a simple one that is good enough for many > applications. > > Konrad. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: struct question
http://lispnyc.org/soc2009.clp Forget most of what I said, it seems the BDFL already has these things in mind ;) Enough of types and structs for me, time for me dive into the less familiar territory of Clojure. On Thu, Jan 22, 2009 at 12:25 PM, David Nolen wrote: > Can't some elements of the problem be solved with some form of predicate > dispatching as proposed by Meikel? Predicate dispatching would allows us to > use _anything_ as a type (i.e. structs themselves), as well as allowing user > defined functions to do the matching instead of being limited to isa? and > the global hierarchy. This of course has some performance implications I > imagine... > > http://groups.google.com/group/clojure/browse_thread/thread/f8b1be403c927b03/438c21a80072a105?lnk=gst&q=hierarchy#438c21a80072a105 > > I have to say that I find the lack of a type system around structs to be > fairly liberating. You can invent one if you need one, but you are not > constrained by it. However, if somebody comes up with something like CLJOS > as a set of handy macros, or extracts whatever parts they deem relevant, why > not put that in clojure-contrib so that people can at least have something > to use for the simple cases as pointed out by Konrad? > > > On Thu, Jan 22, 2009 at 10:25 AM, Konrad Hinsen > wrote: > >> >> On 22.01.2009, at 15:26, Rich Hickey wrote: >> >> > It's pretty easy to write a trivial struct system, much harder to >> > address performance, interop, compilability, dynamicity etc >> > constraints. >> >> Indeed. >> >> > As a simple case, if a defstruct is re-evaluated, will objects created >> > after that be of the same 'type' as objects created before? >> >> I'd say no, which resolves the next question: >> >> > What if fields have been added/removed? >> >> Anyway, I don't think that re-evaluation is a serious issue, except >> in interactive development sessions. The typical use would be >> defining a struct once and then not touch it any more. >> >> > I'd prefer people experiment with libraries built on the existing >> > facilities, with an open mind as to the possibilities of categorizing >> > things other than by their structure. >> >> The added flexibility of multimethods is quite appreciable in non- >> trivial situations. But at the moment there is no simple way to >> handle simple situations. Using structs is straightforward and >> familiar from other languages. It is certainly not *the* solution to >> categorizing, but it's a simple one that is good enough for many >> applications. >> >> Konrad. >> >> >> >> >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Possible feature: consider aliases when reading namespace-qualified keywords.
Nice :) On Fri, Jan 23, 2009 at 2:10 PM, Jason Wolfe wrote: > > On Jan 19, 4:29 pm, Jason Wolfe wrote: > > I've been doing some OO-type Clojure programming, and have run into > > the following (quite minor) annoyance: > > > > I've defined a struct with a :class of ::Foo in namespace > > my.long.namespace.foo. > > > > In another namespace my.long.namespace.bar, I want to define a > > subclass of this struct. > > In this namespace, I require [...foo :as foo], so that I can refer to > > multimethods like foo/method1. > > > > However, it seems I'm still required to write > > (derive ::Bar :my.long.namespace.foo/Foo) > > when I'd like to write > > (derive ::Bar :foo/Foo) > > On IRC, "duck1123" just showed me that this is already implemented; > you just have to use the "::" form. > > (derive ::Bar ::foo/Foo) > > You learn something new every day... > > -Jason > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure for Games/Simluation/Art (Optimization in Clojure)
Dear Clojurians,
After my obsessed stint with object orientation, I went on to a new obsessed
stint with basic functional programming with the hope of converting a nice
Java boid simulation written in the popular Processing pedagological tool.
I would like to find out if anyone has pointers on improving the
performance of a simulation (and yes, I've read the performance
threads/docs, I have notes below about what I tried). For reference a nice
small example of the flocking algorithm I tried to reimplement in Clojure
(along with code) can be found here:
http://www.shiffman.net/itp/classes/nature/week05_s07/flocking/
The technique was first described by Craig Reynolds in the 1980s and has
since then made it's way into many contemporary games. The algorithm is
interesting in that it's fairly computationally intensive. Each boid's
motion is determined by calculating it's distance from every other boid. If
the other boids are within a threshold, 3 different vector values (cohesion,
alignment, separation) are calculated based on the location and velocites
from all other boids that are within the said neighborhood. There's a lot
of interation, 67500 (150x150x3) iterations for 150 boids per update/render
loop.
When running this in the Processing app, you can calculate and render 150
boids in about 6-8ms (new Macbook Pro 2.4ghz).
I thought this little project would be a good exericise to get into deeper
Clojure, and to put aside my OO leanings. First pass, I avoided premature
optimization. I used only mapping operations and Clojure's built in
vectors. This of course was horribly slow but I just wanted to see how
nicely the algorithm could be expressed.
Personally I think the algorithm is far more clear in the Clojure-centric
version. However this version was awful in terms of performance. About
100-110ms to calculate all the new positions for 150 boids.
http://github.com/swannodette/clojure-stuff/blob/a3b35bdd1254763bf3d535139f7ddab9f929fd3f/flocking.clj
I then proceeded to read about how something like this might be optimized,
and I tried a lot of things. I struggled several days, read up a lot on
type hinting, on using Java Arrays in Clojure and I learned many many
interesting things related to raw performance (on OS X at least).
I have to say my experience with coding in Clojure thus far has been
fantastic. Most of the performance metrics were determined simply by having
the program run and recompiling functions on the fly while dumping the
timing information into the REPL. I could remove a single aget call and see
how that affected performance without needed to stop the running program.
So here are some observations (would love to know if I'm way off on
anything):
1. Don't use multidimensional Java arrays. You get a access time hit for
each dimension EVEN if you store the embedded array in a let binding.
2. aget is at least if not more expensive than a math operation.
3. Reuse Java arrays. Making new arrays each time through a tight loop is
too demanding. Implications for multithreading. I would love to hear
alternative ways to implement this algorithm as well if anyone has any ideas
how to make it thread safe.
4. In Clojure functions are dirt cheap, blazingly fast, almost no overhead
here as far as I can tell. Invisible almost.
After all of these optimization, I finally cut the framerate by a little
more than half, and now the code takes bout 41ms to update and render 150
boids:
http://github.com/swannodette/clojure-stuff/blob/e81308902cba849efbbaf197b6945c86e89e00ad/flocking.clj
Almost all the time is spent in the three functions, separate, cohesion, and
align They all look pretty much like this:
(defn separate [{loc :loc, :as boid} #^floats distsv #^floats xs #^floats
ys]
(let [dsep (float 25.0)
len (int (dec *boid-count*))
[sum acount] (loop [i (int 0) rcount (int 0) result [0 0]]
(if (> i len)
[result rcount]
(let [x (float (aget xs i))
y (float (aget ys i))
d (float (aget distsv i))
inhood (and (> d (float 0))
(< d dsep))
ncount (int (if inhood (unchecked-inc
rcount) rcount))
nresult (if inhood
(add result
(div (unit (sub loc [x y]))
d))
result)]
(recur (unchecked-inc i) ncount nresult]
(if (> acount (int 0))
(div sum acount)
sum)))
With a 150 boids, rendering consumes about 10ms (overhead from talking to
proxied Java class?) separate, cohesion, and align together add an
additional 30ms.
I am pretty much out of ideas on how to optimize this further in pure
C
Re: Clojure for Games/Simluation/Art (Optimization in Clojure)
> > For the purpose of game development, I think it is a mistake to perform > these calculations for every pair of birds. If you had an error of 1% in > each of the three characteristics (cohesion, alignment, separation) would > that still be good enough? Would this be an acceptable loss if you got a > factor of 100 performance improvement? > Good point. > In "Objective CAML for Scientists" [1] pages 92-101 Jon Harrop demonstrates > a rapid numerical solution for a multibody gravitation problem, which looks > similar to the problem you are solving. He refers to the method as Fast > Multipole Method [2,3]. It trades a little accuracy for a big performance > gain. Oh, and his implementation in OCaml uses only immutable data > structures. No guarantees, but I have a feeling that this would completely > eliminate your performance issues. > Very interesting, these book(s) look amazing! Thanks much. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure for Games/Simluation/Art (Optimization in Clojure)
On Wed, Jan 28, 2009 at 6:59 AM, bOR_ wrote: > > There is many ways in which you can improve the algorithm. I have seen > flocks of 10,000 birds being rendered real-time on a laptop by Hanno > Hildenbrandt, theoretical biology Utrecht. > > > http://www.rug.nl/biologie/onderzoek/onderzoekgroepen/theoreticalbiology/peoplePages/hannoPage > > Also, Craig Reynolds himself has been working on speeding up crowd > behaviour (was in contact with him a while ago about Hanno's model). > http://www.research.scea.com/pscrowd/ More great references and readings, 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 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: pretty-printing?
Agreed ;) On Wed, Jan 28, 2009 at 9:54 AM, Matt Moriarity wrote: > > I say go for it. maybe swank could use it for macroexpansions and > stuff. the lack of pretty-print drives me crazy! > > On Jan 27, 10:56 am, Mike DeLaurentis wrote: > > Hi, > > > > Is anyone aware of a pretty-print function for Clojure? I saw there > > was some discussion about it on this thread a while ago, but I don't > > seem to see anything related to pretty-print in either the core or > > clojure-contrib. If no one's working on implementing it, I might take > > a stab at it. > > > > Thanks, > > > > 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 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: Object system for Clojure?
At this point you have to roll your own, I have an experimental thing I plan on fleshing out temporarily called CLJOS. I've implemented field inheritance, type inheritance, basic multiple inheritance, basic introspection. Search the mailing list for CLJOS and you'll see more details. It only took 200 lines of code You mention in particular field inheritance. In CLJOS, you can define default initializers for fields. When you inherit from a class(es), a look up table of default initializers is consulted, the values are merged in the direction of the inheritance chain. Admittedly, it is a bit of a toy example at this point, but it shows that without too much effort you could build a very powerful object system based on structs, and I've already found CLJOS to useful in my own hacking. In fact I would be happy to collaborate on something more substantial. http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos.clj Examples here and here: http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos_example.clj http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos_example_two.clj Not too many people are doing heavy or fancy GUI related stuff (as far as I can tell) so I can understand why this hasn't come up often. I note that you work with weblocks so I can see where you're coming from and I'm glad you're bringing it up. That said, I imagine if a decent, useful, and complete lightweight object system could be designed I'm sure it could get rolled into clojure-contrib without too much brouhaha. On Fri, Jan 30, 2009 at 1:09 PM, Jan Rychter wrote: > > There is something I don't understand about Clojure. There are > multimethods (great), but I can't seem to find objects they can operate > on. I come to Clojure from a Common Lisp background, having done a fair > bit of CLOS programming. Mind you, I am not necessarily a fan of overly > complex object hierarchies. But still -- I've been trying and I just > can't seem to make objects in Clojure work. > > From what I read, the reasoning is that Clojure provides extremely > general multimethods where you have to define a dispatch function. On > the object side, there is metadata and you can do with it whatever you > want. But this seems to leave a gaping hole saying "fill me with an > object system". Is the goal for everyone to roll their own? > > I'm against overusing objects, but there are things which quite > naturally map into the object-oriented paradigm. Let's take windowing > systems for example -- let's assume you have various kinds of windows, > each with its own unique attributes and attributes which are inherited > (e.g. a window-id attribute is common to all windows). I can't see how > you'd implement that in Clojure when you can't inherit structmap > attributes. How do I build my-special-window which is a kind of window > and also inherits window's window-id attribute? I know how to inherit > behavior, but there is behavior that requires data, and I have no idea > how to store and inherit that data. I looked at merge, but it seems you > can't merge structure basis objects. > > Unfortunately, all discussion on Clojure polymorphism, multimethods and > objects that I could find seems to use overly simplified examples (it > really only shows that there are multimethods which can do multiple > dispatch on anything), and doesn't really help. Even Stuart Halloway's > beta "Programming Clojure" book has very simple examples that don't > inherit attributes, just use different type tags for the same > information. > > --J. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Object system for Clojure?
>
> (defn make-window [id]
> {:tag ::window, :id id})
>
> (defn make-color-window [id color]
> (assoc (make-window id)
>:tag ::color-window
>:color color))
>
> (derive ::color-window ::window)
>
> (defmulti describe-window :tag)
>
> (defmethod describe-window ::window [w]
> (println "Window with ID" (:id w)))
>
> (defmethod describe-window ::color-window [w]
> (println (:color w) "Window with ID" (:id w)))
>
> (let [w (make-color-window 24 "blue")]
> (describe-window w))
> ;; => prints "blue window with ID 24"
In any fairly large UI system this would become tedious in no time and a hit
on readability. For example consider building a UI system from scratch for
a JOGL game of even medium complexity in pure Clojure (scrollbars, views,
zoomable views, sprites, physics, icons, buttons, et al.). A higher level
abstraction is required. I'm not arguing that the language needs to provide
it directly, but at least have the framework in place so that it can be done
via macros (which already is the case).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Object system for Clojure?
> > On Jan 30, 3:16 pm, Stuart Sierra wrote: > > > > I think the goal is to provide object-like capabilities without > > needing actual objects. > > Why is that the goal? I mean, the JVM provides a well defined, high > performance object oriented system. Clojure can already generate > classes - the main issue I see looking at the API is that it doesn't > look convenient to make "property bag" classes. > Except that compared to Clojure's multihierarchy multimethod system, Java's object system seems a bit, shall we say, weak. And why program in Java when you can program in Clojure? Why deal with Java UI interop if you don't need/want it? Just saying the OP has a valid point. Perhaps someone wants to build a web based UI framework along the lines of weblocks. Perhaps you want to define easily extendable widgets in this UI framework... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure is "not a serious language"
Agreed :) On Fri, Jan 30, 2009 at 11:40 PM, Jon Harrop wrote: > > > Apologies if you've seen this before but I just thought it was absolutely > hillarious: > > http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/ > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
CLJOS -> Spinoza, 3X faster than struct-map ;)
I've changed the name of my project since that was a joke anyway. http://github.com/swannodette/spinoza/tree/master Spinoza isn't just for people who want object oriented behaviors. It's also for anyone who plans on instantiating many structs. Spinoza's make-instance macro automatically orders your key/values and uses struct not struct-map. (defclass shape [object] (:position [0 0])) (defclass rect [shape] (:position [5 5]) :width :height) (time (dotimes [x 100] (make-instance rect :height 100 :width 150))) > ~280ms (defstruct rect-struct :tag :position :width :height) (time (dotimes [x 100] (struct-map rect-struct :tag ::rect :position [50 50] :width 100 :height 190))) > ~800ms Also, it is now available under an MIT license, feel free to fork, send patches at will etc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
Just to be clear make-instance is a macro on struct: (defmacro make-instance "Takes a defclassed struct-basis and creates a struct. Initializes properties to default values." [aclass & initializers] (let [class-key (eval (make-pair aclass)) class-sym (symbol (name aclass)) class-inits (get-all-initializers-for-class class-key) layout(rest (class-key @*layouts*)) layout-map (zipmap (reverse layout) (replicate (count layout) nil)) rinitializers (vals (merge layout-map class-inits (apply hash-map initializers)))] `(struct ~class-sym ~class-key ~...@rinitializers))) make-instance and struct are equivalent. make-instance just follows the principle that the programmer should haven't to do anything a computer can do for you (I'm still a macro noob, let me know if I'm doing anything particularly nonsensical here). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure speed
Heh, this is a more reasoned reply than my own as it points out an actual implementation difference between Python and Clojure. And of course you might need arbitrary precision arithmetic in your program, but again this just reinforces the insignificance of microbenchmarks without some context of what you are actually trying to achieve. On Mon, Feb 2, 2009 at 2:12 PM, Christian Vest Hansen wrote: > > It is safe to assume that Python uses the GMP library for its infinite > precision math, no? This could be a big part of the explanation as, if > the language shootouts are to be believed, BigInteger and BigDecimal > have inferior performance when compared to what can be achieved with > GMP. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure speed
Please do the list a favor and read the very long threads about performance.
You cannot expect to enter a new language run a microbenchmark you would
never see in a running programming and expect that to be anything like a
real comparison.
Here's something unlikely but far less so (something like it might
_actually_ appear in a real program):
t=timeit.Timer('class Sprite():\n\tx = 5\n\ty = 5\n\tvel = (5, 5)\n\tdef
__init__(self, nx, ny,
nvel):\n\t\tself.x=nx\n\t\tself.y=ny\n\t\tvel=nvel\n\n\nfor n in
range(100):\n\tSprite(5, 5, (9, 10))')
> 1.1212704896926879
vs.
(defstruct sprite :x :y :vel)
(time (dotimes [x 100]
(struct sprite 5 5 [9 10])))
> 262.041ms
4X faster. But it really doesn't prove anything any more than your example
does. Play around with Clojure long enough, and you'll find for many many
things, it is far faster than Python.
This is not a rag on Python, I enjoy Python hacking myself.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
Hey, it is an extremely simplified example ;) Which is more readable in the long run? (struct sprite ::foobar 98 ::hunta ::laser [5.5 3.3] 4.01 78) or (make-instance foobar :id 98 :mode ::hunta :weapon ::laser :position [5.5 3.3] :velocity 4.01) :targetid 78] With Spinoza the two are equivalent, just make-instance is more readable. make-instance is also programmer friendly. You don't need to memorize the layout of a complex set of properties (imagines a sub-subclass of this sprite both which add 3 properties). That's 13 properties you have to remember to type in the right order. Say you have several different kinds of sprites. With struct you would have to manually define the layout for each different kind of sprite you want to use (a lot of redundancy). That or you have to defstruct a struct with all the properties predetermined and create functions that create instances of the different types (then why not use defclass at that point ? ;) If you relied on struct and decide to change the properly layout you have to go modify all the places where you used struct. No so with make-instance. Anyways, this was a goal stated earlier. I wanted make-instance to have the readability of struct-map with the performance of struct. Cheers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: special forms vs. functions and macros
I think the special forms list on the Clojure main page lists all the constructs that are not written in Clojure itself. It seems most everything else can be found in the .clj files in the src directory. I'm constantly looking in there when I'm curious how something works or is implemented, especially if the terse argument list doesn't make sense to me. On Mon, Feb 2, 2009 at 9:28 PM, Mark Volkmann wrote: > > I understand that special forms are all recognized by the Clojure > compiler clojure.lang.Compiler. Is it the case that all function and > macro definitions can be found in some .clj file, whether supplied > with Clojure or not? Asked another way, are there any functions or > macros that are included with Clojure that are implemented entirely in > Java code? > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: need some help getting jacob com library to work
You need to add it to -cp argument when starting up the REPL, not your environment CLASSPATH. On Mon, Feb 2, 2009 at 9:05 PM, greg wrote: > > I have recently enjoyed exploring clojure. > > I can use java... > C:\myprograms\clojure>java -cp clojure.jar clojure.lang.Repl > Clojure > user=> (into [] (.list (new java.io.File "c:/myprograms/clojure"))) > ["build.xml" "changes.txt" "clj.ico" "clojure.jar" "epl-v10.html" > "fractal.clj" > "Mandelbrot.class" "Mandelbrot.java" "pi.clj" "pom.xml" "readme.txt" > "REPL.bat" > "snake.clj" "src" "svninfo.txt" "test.clj"] > > I am having trouble getting jacob to work. Jacob is in my PATH and > CLASSPATH > > user=> (import '(com.jacob.com Dispatch)) > java.lang.ClassNotFoundException: com.jacob.com.Dispatch > (NO_SOURCE_FILE:0) > user=> > > pointers? > -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 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 speed
Even more constructive is to take a real Python program that you've written where you actually care about it's performance. Rewrite it Clojure. Do some investigation about which parts seem slow to you. Spend some time on this. Come back with some code and questions and you'll probably get some great answers. At that point you might start to understand what the performance characteristic of the language actually are. Perhaps some idioms in Python are faster, perhaps you need to learn new idioms to express them more efficiently in Clojure. Perhaps you'll find out some things are ungodly faster in Clojure and, of course, some things, like BigInteger math, aren't. 2009/2/3 Gregory Petrosyan > > On Feb 3, 12:50 pm, André Thieme wrote: > > > Hi, welcome in the group. > > Can you please write that program in Java and see how well it > > performs for you? > > Will try to compare Java and Clojure later. > > Here http://leonardo-m.livejournal.com/75825.html you can find similar > microbenchmark. Java is more than 3х slower than Python's built-in > integers, and more than 10x slower than GMPY ones. Seems like Java's > BigIntegers have some problems with performance, hm? > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
Haha, nope that's probably beyond the scope of what I'm trying to achieve. Spinoza just adds some object orientedness to struct-maps that's all. As far as I can tell there not much explicit control over memory consumption in Clojure. On Tue, Feb 3, 2009 at 2:56 PM, Bradbev wrote: > > On Feb 1, 5:22 pm, David Nolen wrote: > > I've changed the name of my project since that was a joke anyway. > http://github.com/swannodette/spinoza/tree/master > > > > Spinoza isn't just for people who want object oriented behaviors. It's > also > > for anyone who plans on instantiating many structs. Spinoza's > make-instance > > macro automatically orders your key/values and uses struct not > struct-map. > > > > (defclass shape [object] > > (:position [0 0])) > > > > (defclass rect [shape] > > (:position [5 5]) > > :width > > :height) > > > > (time (dotimes [x 100] > > (make-instance rect :height 100 :width 150))) > > > > > ~280ms > > > > (defstruct rect-struct :tag :position :width :height) > > (time (dotimes [x 100] > > (struct-map rect-struct :tag ::rect :position [50 50] :width 100 :height > > 190))) > > > > > ~800ms > > > > Also, it is now available under an MIT license, feel free to fork, send > > patches at will etc. > > Does Spinoza do anything to optimize the size of the object? I'm > tinkering with a project that will have several million objects in > it. Currently I'm using struct-maps with around 7 keys, and the > overhead appears to be around 200 bytes per map - I'd like it to be > around 32 bytes ideally. I'm planning on eventually using Java > objects to shrink the size, but it would be nice if there were a > Clojure library I could use. > > Cheers, > Brad > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Macro error
{} is a reader macro for hash-map I believe, try something like this:
(defmacro foobar [& rest]
`(hash-map ~...@rest))
(foobar :first 1 :second 2)
On Tue, Feb 3, 2009 at 7:45 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:
>
> Btw, I fixed the ~ needed on relation. It didn't help. It seems I
> just can't put a ~@ form inside of a { } set builder.
>
> On Feb 3, 7:43 pm, Jeffrey Straszheim
> wrote:
> > I'm trying to define a macro:
> >
> > http://paste.pocoo.org/show/102695/
> >
> > But whenever I try to compile it I get:
> >
> > java.lang.ArrayIndexOutOfBoundsException: 1
> > java.lang.Exception: Unmatched delimiter: )
> > java.lang.Exception: Unmatched delimiter: )
> >
> > Note, this is when compiling the macro itself, not executing it. I
> > don't understand.
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Type hint Java array of your own Java class
(defn foobar [#^MyClass[] myarray]) This syntax doesn't seem to work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Type hint Java array of your own Java class
Many thanks. On Wed, Feb 4, 2009 at 12:49 PM, Christophe Grand wrote: > > David Nolen a écrit : > > (defn foobar [#^MyClass[] myarray]) > > > > This syntax doesn't seem to work. > Indeed it's a bit tricky: > #^"[Lyour.package.YourClass;" > > You can find it by doing: > user=> (class (into-array [(your.package.YourClass.)])) > [Lyour.package.YourClass; > > Christophe > > -- > Professional: http://cgrand.net/ (fr) > On Clojure: http://clj-me.blogspot.com/ (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 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: anyone going to FOSDEM?
Raphaël, I will be there presenting the open source meta web project ShiftSpace ( http://shiftspace.org) at the art festival Artefact ( http://www.artefact-festival.be/). Unfortunately this project isn't really Clojure related, it's primarily written in Javascript :) However, two people (including myself) have been playing around with Clojure and wouldn't mind meeting a fellow Clojurian! We arrive on Sunday and are planning on checking FOSDEM out. We're also giving a developer workshop on ShiftSpace in Brussels on the 12th so if you're around come check that out as well. David 2009/2/5 rb > > Hi, > > are any clojure developers going to FOSDEM, next week-end in Brussels > (Belgium)? > > It would be cool to meet there. (I'm a complete newbie at clojure, but > that would make it the more interesting for me to meet other clojure > developers:-) > > Cheers > > Raphaël > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure Simulation Redux (more on Clojure Optimization)
For those who are interested in Clojure performance, I've updated my flocking example from earlier, which uses Roland's excellent Processing library. http://github.com/swannodette/clojure-stuff/blob/80035bb3b76c21d39d6f8011e9a27aa1116b/flocking.clj It is twice as fast as the previous version and purely functional, no reusing Java arrays or reusing PVector objects. 1. Use make-arrays wisely and it works well. 2. Do your math in Java (PVector in my case), Clojure's built in vectors just aren't designed for it, which is FINE. 3. Type-hint very very very very agressively. *warn-on-reflection* is a life saver, thanks Rich. It's still a bit slower (2X-3X) than the Processing version, but I prefer the fact that this one is functional over the original, no changing vector objects in place. This pretty much as far as I can see it going down this path, it is pretty much a direct translation of the Java version minus mutation, in the next version I hope to incorporate some of the suggestions in reply to my earlier post (FMM in particular). David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
> > I don't argue that this model is better than what you're doing with > Spinoza, but for years (see > http://www.mactech.com/articles/frameworks/8_2/Protocol_Evins.html > from 1994) I've wanted an object model that explicitly separates > structure from protocol, and since I partially built one in order to > satisfy a need I had in a larger project, I think I'll push ahead with > it a bit to see whether it's worthwhile. Yes this is a good thing, but you get this behavior for free with Clojure's multimethods. For example: (defprotocol clonable) ;; derives ::clonable from ::protocol (defmulti clone dispatch-fn) ;; dispatch-fn -> [::class ::protocol] (defmethod [::my-class ::clonable] ...) In fact, (defprotocol clonable [clone deep-clone ...]) could be a macro that automatically defines all of the base multifns. (protocols object) ;; returns a list of all the protocols an object implements via multimethod reflection This would be easy to add to Spinoza, if you want perhaps we could hash it out and we can add it. Or you can forge out on your own, but I think it's always fun to join forces. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
(isa? [:spinoza-example-one/circle] [:spinoza/object]) ;; true Just to note, the above shows that protocols could have their own inheritance chain. This is insanely powerful and could be implemented very quickly. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
>
> I'm not looking for a way to statically define protocols in which
> classes participate. Consider an example similar to the one I gave in
> my reply to Laurent:
Static defining of anything is just a matter of chose, especially in
Clojure. For example in Spinoza you have pose-as which changes the class of
an object. The primary purpose of Spinoza is structural inheritance and
basic dispatch on type, but I've been thinking about runtime modification
and your post gives me a lot of ideas.
> (make-thing {:models [::vehicle ::airborne]
>:protocols [::thing ::idea]
> :inits {:name "test-thing1" :number 1}})
>
Something like this would be quite simple to build on top of Spinoza. Also
allowing protocols to be defined at class definition time and runtime would
work the same way that pose-as works
(adopt-protocol obj ::some-protocol ::another-protocol)
> Note that no classes are involved. The thing in question is not an
> instance of any class (except incidentallly, by virtue of the fact
> that Clojure's runtime is built on the JVM). I never defined any
> classes, nor did I wish to. A class definition would have been just an
> obstacle, not directly relevant to my goal, which was to instantiate
> an object that reflects these models and participates in these
> protocols.
As I'm alluding above, this direction seems prototypal, and I've been
thinking about allowing for these kind of behaviors in Spinoza.
Of course no collaboration beyond healthy discussion is expected. Thanks
for bringing the topic up again :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
>
> The fly in the ointment is: what happens if both
> protocols specialize frob? Then Clojure will complain that it can't
> tell which method to call. In order to resolve that problem, we must
> use prefer-method to declare that one protocol or the other is
> preferred.
>
> But what if I want to make another thing:
>
> (make-thing {:models [::thing]
> :protocols [::idea ::thing]
> :inits {:name "test-thing2" :number 2}})
>
make-thing could tag your thing with a runtime tag and define a prefer on
this runtime tag.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
> > (prefer-method frob ::idea ::thing) > (prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing]) (prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea]) Provide a dispatch fn that extracts the runtime tag. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
Have thoughts about this, will have to collect them, will reply soon.
On Thu, Feb 5, 2009 at 9:06 PM, mikel wrote:
>
>
>
> On Feb 5, 7:12 pm, David Nolen wrote:
> > > I'm not looking for a way to statically define protocols in which
> > > classes participate. Consider an example similar to the one I gave in
> > > my reply to Laurent:
> >
> > Static defining of anything is just a matter of chose, especially in
> > Clojure. For example in Spinoza you have pose-as which changes the class
> of
> > an object. The primary purpose of Spinoza is structural inheritance and
> > basic dispatch on type, but I've been thinking about runtime modification
> > and your post gives me a lot of ideas.
> >
> > > (make-thing {:models [::vehicle ::airborne]
> > >:protocols [::thing ::idea]
> > > :inits {:name "test-thing1" :number 1}})
> >
> > Something like this would be quite simple to build on top of Spinoza.
> Also
> > allowing protocols to be defined at class definition time and runtime
> would
> > work the same way that pose-as works
> >
> > (adopt-protocol obj ::some-protocol ::another-protocol)
> >
> > > Note that no classes are involved. The thing in question is not an
> > > instance of any class (except incidentallly, by virtue of the fact
> > > that Clojure's runtime is built on the JVM). I never defined any
> > > classes, nor did I wish to. A class definition would have been just an
> > > obstacle, not directly relevant to my goal, which was to instantiate
> > > an object that reflects these models and participates in these
> > > protocols.
> >
> > As I'm alluding above, this direction seems prototypal, and I've been
> > thinking about allowing for these kind of behaviors in Spinoza.
> >
> > Of course no collaboration beyond healthy discussion is expected. Thanks
> > for bringing the topic up again :)
>
> It's not quite the same as the usual prototype-based systems either.
> Generally, in a protoype-based system you have one of two inheritance
> schemes:
>
> 1. structure and behavior are copied (inherited) from one or more
> prototypes (or "parents"), as in Javascript
>
> or
>
> 2. structure is copied from one prototype (the "data parent");
> behavior is copied from another (the "behavior parent") as in Self
>
> The model/protocol/thing stuff does not use parent objects at all. It
> collects field specifications from model objects, but no inheritance
> relationship is established. It uses the protocols to establish
> multimethod dispatch in the manner of derive, but no delegate object
> is used.
>
> Ruben Kleiman's SK8 system had a prototype-based object model that
> would have made it easy to implement all the features of the model/
> protocol/thing subsystem, but his object system was not typical. It
> had more in common with frame systems like KEE than with typical
> class- or prototype-based object models. His object model included per-
> object configurable inheritance (and per-slot configurable accessors--
> in fact, each slot of an object--slot, not value--could itself be an
> arbitrary object with arbitrary model and protocol). I'm not entirely
> sure I want to recapitulate the entire SK8 object model for this
> project, though. :-)
>
> There are a few more things I want to get working:
>
> 1. you should be able to pass a set of map literals as the models
>
> 2. you should be able to pass a set of dynamically computed protocol
> objects (whatever those turn out to be) as the protocols
>
> 3. Given a thing, you should be able to ask it what models it
> represents and what protocols it implements
>
> 4. Given a model and a thing, you should be able to ask whether the
> thing represents the model
>
> 5. Given a protocol and a thing, you should be able to ask whether the
> thing implements the protocol
>
> 6. It should be easy and natural to create models, protocols, and
> things dynamically and without any static declarations being required.
> Classes, if they exist at all, should be optional. It should be
> possible to dynamically create a thing from arbitrary sets of models,
> protocols, and initial map entries (subject to consistency checks).
>
> 7. It should be straightforward to serialize models, protocols, and
> things (this subsystem is not an end in itself, but a component of a
> larger project in which it's important that the data objects be
> amenable to serialization and deserialization, both for storage in
> nonvolatile repositories and for t
Re: CLJOS -> Spinoza, 3X faster than struct-map ;)
> > Yuck. Instead of defining a method on ::idea, you now must define a > method on [something-that-has-no-meaning-in-context ::idea] (because > the dispatch function must now return a vector, which means the > defmethods must now be called on vector dispatch values...). Sure but as you mention below this could be hidden via a macro (defprotocol-method ...). This also could be used to implement something that works like eql specializers... > I was kind of sliding in another direction: I could always implement > CLOS-style method computation and sorting. But of course that might > mean not reusing multifn and its dispatch mechanism, and that seems a > shame. Maybe I could bury the defmethod ugliness in syntactic sugar... Looking at the requirements above it seems like you have something specific in mind for this system so perhaps Spinoza is not well suited for the particular thing you are shooting for. However all of your ideas are quite fantastic. I will definitely add protocol support to Spinoza, but it will probably be something that emphasizes static definitions with good support for runtime modifications. Your system sounds very interesting and it would be great to hear how it develops if only to get more ideas for Spinoza ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Tools for parsing arguments
Is there anything in core or contrib for parsing arguments to a function? Since Clojure fns don't support optional args or even keyword args, is there a standard set of helpers functions to do this? I looked around but I didn't see anything obvious. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
