Re: Jesus, how the heck to do anything?
On 25 March 2011 07:15, Ken Wesson wrote: > On Fri, Mar 25, 2011 at 12:36 AM, ultranewb wrote: [...] >> One other difference with APL is that they removed the old complaint >> of "special characters and keyboards" by changing it to pure standard >> ascii characters. Thing is, I don't particularly like this aspect. I >> much prefer old APL symbols to the new string of plain ascii >> characters which I find ugly. The irony in all of this is that >> Iverson was before his time in creating a language with special >> symbols - some people didn't "get it," you needed special equipment >> and character sets and fonts, etc. So they removed this old complaint >> with J... just with the advent of unicode, which actually allows for >> such things quite easily. > > Er ... not exactly. It may allow representing the special characters > in disk files and network traffic in a manner that will survive being > passed through tool chains and among web users, but I'm aware of no > magic Unicode floppy disc I can stick into my machine, run "make > install" (or "setup.exe") off, and wind up able to *type* the special > characters by simply looking down at my keyboard, finding one of them, > and pushing it. :) > > So it'd mean a lot of annoying alt+numpad foolery, copy-paste, or > memorizing arcane emacs-style chords. > > Maybe in another ten years keyboards will have become multitouch > screens that can serve various other purposes, and when used as > keyboards can have the glyphs changed in software; then maybe you can > just task switch to your J IDE and watch your keyboard F-key and > numpad symbols change as determined by the keymaps defined for the > application with the input focus, or something; and this won't all > cost a ridiculous amount of money. Well, except for the part about not costing a "ridiculous amount of money", this might be what you're looking for :) http://www.artlebedev.com/everything/optimus/ > But that day has not yet arrived. And besides, a touch-screen keyboard > can't be typed on by feel, unless they add software-controlled shape > shifting or something. or unless a separate little screen is embedded in each real key as in the optimus maximus. > I think there are experimental display devices > for the blind that could be put under a flexible oled touchscreen to > make a fully programmable keyboard that actually had keys you could > feel and push down, but that's even longer to make practical and > inexpensive. -- Michael Wood -- 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: Jesus, how the heck to do anything?
I'm sure you are right, but I see asians using American keyboards with English alphabets to write Chinese, Japanese, and everything else every day. And with a few keystrokes, they switch between writing in English and writing in (insert asian language). In theory, I don't know why it would be any different to do the same with APL symbols. In practice, I just don't know enough about the problem, so maybe it is. On Mar 25, 12:15 pm, Ken Wesson wrote: > On Fri, Mar 25, 2011 at 12:36 AM, ultranewb wrote: > > On Mar 25, 8:58 am, Sean Corfield wrote: > >> My final year project at university was to write an APL interpreter > >> (in Pascal, back in '83). APL is a fun language. I haven't looked at J > >> (yet). > > > Awesome! > > > J is APL, but totally "modernized." Everything you would expect in a > > functional language (currying, first class functions, anonymous > > functions, composition, etc) and even more things, like hooks, trains, > > forks, not needing to refer to variables explicitly, etc. Sort of > > scary, when you think of what you could do with ancient APL. > > > One other difference with APL is that they removed the old complaint > > of "special characters and keyboards" by changing it to pure standard > > ascii characters. Thing is, I don't particularly like this aspect. I > > much prefer old APL symbols to the new string of plain ascii > > characters which I find ugly. The irony in all of this is that > > Iverson was before his time in creating a language with special > > symbols - some people didn't "get it," you needed special equipment > > and character sets and fonts, etc. So they removed this old complaint > > with J... just with the advent of unicode, which actually allows for > > such things quite easily. > > Er ... not exactly. It may allow representing the special characters > in disk files and network traffic in a manner that will survive being > passed through tool chains and among web users, but I'm aware of no > magic Unicode floppy disc I can stick into my machine, run "make > install" (or "setup.exe") off, and wind up able to *type* the special > characters by simply looking down at my keyboard, finding one of them, > and pushing it. :) > > So it'd mean a lot of annoying alt+numpad foolery, copy-paste, or > memorizing arcane emacs-style chords. > > Maybe in another ten years keyboards will have become multitouch > screens that can serve various other purposes, and when used as > keyboards can have the glyphs changed in software; then maybe you can > just task switch to your J IDE and watch your keyboard F-key and > numpad symbols change as determined by the keymaps defined for the > application with the input focus, or something; and this won't all > cost a ridiculous amount of money. > > But that day has not yet arrived. And besides, a touch-screen keyboard > can't be typed on by feel, unless they add software-controlled shape > shifting or something. I think there are experimental display devices > for the blind that could be put under a flexible oled touchscreen to > make a fully programmable keyboard that actually had keys you could > feel and push down, but that's even longer to make practical and > inexpensive. -- 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: Jesus, how the heck to do anything?
On Fri, Mar 25, 2011 at 4:40 AM, ultranewb wrote: > I'm sure you are right, but I see asians using American keyboards with > English alphabets to write Chinese, Japanese, and everything else > every day. And with a few keystrokes, they switch between writing in > English and writing in (insert asian language). In theory, I don't > know why it would be any different to do the same with APL symbols. > In practice, I just don't know enough about the problem, so maybe it > is. Oh, it could be done, with special software that provided a way to toggle among several key-maps and interpreted the keys differently in each one. But to use it a user would have to basically learn to type all over again -- this time without the benefit of the key caps accurately showing them what characters they'd be inserting. That would create a very high hurdle to jump before this thing would be at all usable. It would be a considerably-worsened version of the high-bar effect that prevents widespread emacs adoption. -- 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: Jesus, how the heck to do anything?
On Fri, Mar 25, 2011 at 4:08 AM, Michael Wood wrote: > On 25 March 2011 07:15, Ken Wesson wrote: >> On Fri, Mar 25, 2011 at 12:36 AM, ultranewb wrote: > [...] >>> One other difference with APL is that they removed the old complaint >>> of "special characters and keyboards" by changing it to pure standard >>> ascii characters. Thing is, I don't particularly like this aspect. I >>> much prefer old APL symbols to the new string of plain ascii >>> characters which I find ugly. The irony in all of this is that >>> Iverson was before his time in creating a language with special >>> symbols - some people didn't "get it," you needed special equipment >>> and character sets and fonts, etc. So they removed this old complaint >>> with J... just with the advent of unicode, which actually allows for >>> such things quite easily. >> >> Er ... not exactly. It may allow representing the special characters >> in disk files and network traffic in a manner that will survive being >> passed through tool chains and among web users, but I'm aware of no >> magic Unicode floppy disc I can stick into my machine, run "make >> install" (or "setup.exe") off, and wind up able to *type* the special >> characters by simply looking down at my keyboard, finding one of them, >> and pushing it. :) >> >> So it'd mean a lot of annoying alt+numpad foolery, copy-paste, or >> memorizing arcane emacs-style chords. >> >> Maybe in another ten years keyboards will have become multitouch >> screens that can serve various other purposes, and when used as >> keyboards can have the glyphs changed in software; then maybe you can >> just task switch to your J IDE and watch your keyboard F-key and >> numpad symbols change as determined by the keymaps defined for the >> application with the input focus, or something; and this won't all >> cost a ridiculous amount of money. > > Well, except for the part about not costing a "ridiculous amount of > money", this might be what you're looking for :) > > http://www.artlebedev.com/everything/optimus/ > >> But that day has not yet arrived. And besides, a touch-screen keyboard >> can't be typed on by feel, unless they add software-controlled shape >> shifting or something. > > or unless a separate little screen is embedded in each real key as in > the optimus maximus. I considered that, but knew it would make the manufacturing and design so complex as to be very expensive, and it was. Over $2000? Unless that can be brought down to $20, it's a non-starter if you want to see widespread use. (And isn't making it a *color* display overkill? Black-on-white or white-on-black should suffice. In fact, a Kindle-style e-ink display technology would consume the least power, could continue to "look normal" during power-down, and would suffice for this use.) -- 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: Implicit unpacking of a map
On 03/25/2011 01:34 AM, Ken Wesson wrote: What about this? First, use :title and :body keywords instead of "title" and "body" strings as keys in form-params. Then define this utility function: (defn get-seq [m& kws] ((apply juxt kws) m)) which takes a map and one or more keywords (cannot be other types of key) and returns a seq (actually a vector) of the corresponding values, in order; do this I don't get to chose the keys, with wrap-params I get whatever is used in the form as strings, inside a :form-params inside the request map. (defn new-article [path timestamp title body] (Article. path title body timestamp)) Interesting, but you just listed title and body twice, where the goal was to not list them at all (except in the definition of Article and in the html form, of course, though theoretically, the form could be generated from a a bit richer single definition, I suppose). so you can use apply. And then this: (defn save-article [path form-params timestamp] (ds/save! (apply new-article path timestamp (get-seq form-params :title :body By now I'm rather sure this would trigger an error, as nothing but an immediate call of Article. seems acceptable for ds/save!. Really not a big deal, just Java-interop making things un-lispy. is neat and tidy and easily extensible to added form-params later (add them to the end of new-article's arg list and to the get-seq keyword list in the same order; pass them to the amended Article constructor appropriately). -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: gen-class and state...
yes and that's great where the resource usage is scoped on a per-thread basis, but not a per-object basis - but then, I am thinking in OO terms again :-) Jules -- 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: Implicit unpacking of a map
Hi, On 25 Mrz., 10:09, Thorsten Wilms wrote: > Interesting, but you just listed title and body twice, where the goal > was to not list them at all (except in the definition of Article and in > the html form, of course, though theoretically, the form could be > generated from a a bit richer single definition, I suppose). Can you generate a "empty" article and set stuff with setters? Then you could use reflection. (defn save-article [path form-params timestamp] (let [article (Article.)] (doto article (.setPath path) (.setTimestamp timestamp)) (doseq [[k v] form-params] (let [setter (.getMethod article (str "set" k))] (.invoke setter article v))) (ds/save! article))) I don't know how the reflection API works, so just some pseudo calls to get across the idea. And you probably shouldn't use this in speed critical code. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Implicit unpacking of a map
On Fri, Mar 25, 2011 at 5:09 AM, Thorsten Wilms wrote: > On 03/25/2011 01:34 AM, Ken Wesson wrote: >> >> What about this? First, use :title and :body keywords instead of >> "title" and "body" strings as keys in form-params. Then define this >> utility function: >> >> (defn get-seq [m & kws] >> ((apply juxt kws) m)) >> >> which takes a map and one or more keywords (cannot be other types of >> key) and returns a seq (actually a vector) of the corresponding >> values, in order; do this > > I don't get to chose the keys, with wrap-params I get whatever is used in > the form as strings, inside a :form-params inside the request map. Well, that's too bad. (apply juxt (map (fn [k] #(get % k)) kws)) it is, then. >> (defn new-article [path timestamp title body] >> (Article. path title body timestamp)) > > Interesting, but you just listed title and body twice, where the goal was to > not list them at all (except in the definition of Article and in the html > form, of course, though theoretically, the form could be generated from a a > bit richer single definition, I suppose). I extracted them from save-article to what's basically a Clojure-friendlier constructor for Article. Is there a reason for you to consider this goal supremely important? >> so you can use apply. And then this: >> >> (defn save-article >> [path form-params timestamp] >> (ds/save! >> (apply new-article path timestamp >> (get-seq form-params :title :body > > By now I'm rather sure this would trigger an error, as nothing but an > immediate call of Article. seems acceptable for ds/save!. Why do you say that? Either your ds-save! is a function that accepts Article objects, and that apply expression returns one; or else your ds-save! is a macro that accepts an s-expression that will become part of its expansion and which works if it evaluates to an Article object at run-time, which the apply expression does. If for some reason you've made it a macro that accepts an s-expression, but parses it itself and expects it to be a constructor invocation, then I suggest you rewrite it to accept any s-expression. Otherwise, the style should be separate parameters, e.g. (defmacro ds-save! [classname & ctor-args]) to make it simpler to implement and to make it clear to its users that it cannot take general-purpose sexps that return the appropriate Java type. But really, it should accept pure function invocations happening in its context, at least -- and the only possibly-impure thing in the apply/getseq/new-article chain there is the Article constructor invocation itself, which would be there anyway. -- 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: Jesus, how the heck to do anything?
I mean, how is what you are describing any different than what these asians I am referring to do? On another note, I have unfortunately decided that I just can't do Clojure right now. I was never able to get anything to work except for using the command line to "java -cp" a file that way. No editor or IDE ever worked (also ended up installing that IntelliJ thing - it didn't work for me either), and lastly I couldn't get leinigen to interface with emacs. I will check back from time to time to see if any of this stuff gets any easier to use with time. On Mar 25, 3:55 pm, Ken Wesson wrote: > Oh, it could be done, with special software that provided a way to > toggle among several key-maps and interpreted the keys differently in > each one. But to use it a user would have to basically learn to type > all over again -- this time without the benefit of the key caps > accurately showing them what characters they'd be inserting. > > That would create a very high hurdle to jump before this thing would > be at all usable. It would be a considerably-worsened version of the > high-bar effect that prevents widespread emacs adoption. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Namespace and file structuring
I would love to know how better to organize my code: I understand the basics of namespaces and how to use them. But when and why I should use different namespaces eludes me. In Java, the language forces you to have more or less one class pr class-file, and you are encouraged to group class-files in packages. So, is it as simple as saying that that namespaces are analogous to class-files, and clj-files are analogous to packages? But then Java doesn't have anything like rebinding something from one namespace into another, for one. What are the best ways to use namespaces? Also, while we are at it, what are the naming conventions? The same as in Java packages? So I would use: "no.terjedahl.some.namespace.here" ? I would love to here thoughts on this. And any links to web-pages discussing the topic. -- 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
bindings & lazy-seq
Hi, Why when you create a lazy sequence, you need to do the bindings inside the definition?, e.g., (lazy-seq (binding [*in* in#] <-- some code -->)) As opposed to make the bindings first and call the lazy-seq later, e.g., (binding [*in* in#] (lazy-seq <-- some code -->)) Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Your favorite utility function or macro.
Hi,
I'm interested in useful utility which you create.
Please show me your favorite utility.
For example, _-> is that for me.
_-> is like ->, but it can insert expression in arbitrary place by
marking underscore.
(_-> :a (assoc {} _ 1))
;=> {:a 1}
Therefore It can unify -> and ->> behavior.
https://gist.github.com/886748
Thanks.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bindings & lazy-seq
Hi, This might help: http://kotka.de/blog/2009/11/Taming_the_Bound_Seq.html Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Your favorite utility function or macro.
Ah. There it is again: the classic. http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852 -- 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: Your favorite utility function or macro.
This comes in handy for me when I'm dealing with side-effects but can't use doto: (defmacro do-with [[binding-form init-expr] & body] "Evaluates body with binding-form bound to the value of init-expr, then yields that same value." `(let [~binding-form ~init-expr] ~@body ~binding-form)) -- 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: Your favorite utility function or macro.
On Fri, Mar 25, 2011 at 8:21 AM, Meikel Brandmeyer wrote: > Ah. There it is again: the classic. > http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852 It goes back further: http://clojure-log.n01se.net/date/2008-04-14.html#22:10- 23:07 In fact, I would guess people wrote it for other lisps even previous to that. --Chouser http://joyofclojure.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Implicit unpacking of a map
On 03/25/2011 11:37 AM, Ken Wesson wrote: Interesting, but you just listed title and body twice, where the goal was to not list them at all (except in the definition of Article and in the html form, of course, though theoretically, the form could be generated from a a bit richer single definition, I suppose). I extracted them from save-article to what's basically a Clojure-friendlier constructor for Article. Is there a reason for you to consider this goal supremely important? Yes, it was the whole reason to not be satisfied with just destructuring in the signature. To be concise, avoiding any repetition. While perhaps enlightening, anything that makes me end up writing more, not less, is not practical. By now I'm rather sure this would trigger an error, as nothing but an immediate call of Article. seems acceptable for ds/save!. Why do you say that? Either your ds-save! is a function that accepts Article objects, and that apply expression returns one; or else your ds-save! is a macro that accepts an s-expression that will become part of its expansion and which works if it evaluates to an Article object at run-time, which the apply expression does. I say that because of what Meikel said at http://groups.google.com/group/clojure/msg/2f2b97b627da2d1d?hl=en and because my experiments suggest so. If for some reason you've made it a macro that accepts an s-expression, but parses it itself and expects it to be a constructor invocation, then I suggest you rewrite it to accept any s-expression. Otherwise, the style should be separate parameters, e.g. (defmacro ds-save! [classname& ctor-args]) to make it simpler to implement and to make it clear to its users that it cannot take general-purpose sexps that return the appropriate Java type. But really, it should accept pure function invocations happening in its context, at least -- and the only possibly-impure thing in the apply/getseq/new-article chain there is the Article constructor invocation itself, which would be there anyway. I didn't write it, it's part of appengine-magic. It appears in a defprotocol and if I get this right, is mapped to a save!-helper function in a defprotocol. So at my current level, I really couldn't have written that :) https://github.com/gcv/appengine-magic/blob/v0.4.0/src/appengine_magic/services/datastore.clj -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Implicit unpacking of a map
On Fri, Mar 25, 2011 at 9:03 AM, Thorsten Wilms wrote: > On 03/25/2011 11:37 AM, Ken Wesson wrote: > >>> By now I'm rather sure this would trigger an error, as nothing but an >>> immediate call of Article. seems acceptable for ds/save!. >> >> Why do you say that? Either your ds-save! is a function that accepts >> Article objects, and that apply expression returns one; or else your >> ds-save! is a macro that accepts an s-expression that will become part >> of its expansion and which works if it evaluates to an Article object >> at run-time, which the apply expression does. > > I say that because of what Meikel said at > http://groups.google.com/group/clojure/msg/2f2b97b627da2d1d?hl=en > and because my experiments suggest so. He said you can't use (apply Article. constructor-arg seq-of-constructor-args) and he's right -- you can't (apply Class. ...) or (apply .method object ...). But you *can* (defn function [x] (Class. x)) and you *can* then (apply function seq-of-constructor-args). That *should* 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 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
I understand metadata now!
Never used metadata until now. I had an insight yesterday that I want to share with you: http://resatori.com/metadata-insight -- 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: Jesus, how the heck to do anything?
On Mar 25, 6:54 am, ultranewb wrote: > On another note, I have unfortunately decided that I just can't do > Clojure right now. I have been reading usenet for 20+ years, and this whole thread just became one of the most epic trolls I have ever seen. -- 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: I understand metadata now!
On 25 March 2011 10:41, msappler wrote:
> Never used metadata until now.
>
> I had an insight yesterday that I want to share with you:
>
> http://resatori.com/metadata-insight
In my view, it depends whether your :id key is a surrogate key or a natural key.
Object metadata should not affect object equality, so if your :id key
is just an internal database identifier, you could include it as
metadata.
But if your :id key is exposed to the outside world, then it should
not be metadata, because changing the :id would change the external
representation of the object, and therefore affect equality.
I should also point out that if you want information hiding, then
object composition might be a better solution. For example:
(defprotocol Identifiable
(id [self] "Return an object's unique id"))
(deftype DBRef [db-id data]
Identifiable
(id [_] db-id)
clojure.lang.IDeref
(deref [_] data))
(defn db-ref [id data]
(DBRef. id data))
Then we can get information about the reference, and deref it to get
its contents:
(def user
(db-ref 193 {:login "fred"}))
=> (id user)
193
=> @user
{:login fred}
- James
--
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: Jesus, how the heck to do anything?
> On another note, I have unfortunately decided that I just can't do > Clojure right now. I was never able to get anything to work except > for using the command line to "java -cp" a file that way. No editor > or IDE ever worked (also ended up installing that IntelliJ thing - it > didn't work for me either), and lastly I couldn't get leinigen to > interface with emacs. > > I will check back from time to time to see if any of this stuff gets > any easier to use with time. Are you using Mac, Linux or Windows? Okay, let me list few things out for you (assuming you are on Windows): 1. Use a simple editor to write Clojure files and a batch script to run them: http://pastebin.com/dQqycRhv 2. Give Leiningen and Emacs another try: http://charsequence.blogspot.com/2010/07/setup-emacs-for-development-with.html 3. I can upload a bundle of Eclipse with Counter-ClockWise plugin that you can just download (100+ MB!) and run. I only have access to Windows and Linux at the moment. Regards, Shantanu -- 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: I understand metadata now!
On Fri, Mar 25, 2011 at 11:48 PM, James Reeves wrote:
>
> (defprotocol Identifiable
>(id [self] "Return an object's unique id"))
>
> (deftype DBRef [db-id data]
>Identifiable
>(id [_] db-id)
>clojure.lang.IDeref
>(deref [_] data))
>
> (defn db-ref [id data]
>(DBRef. id data))
>
> Then we can get information about the reference, and deref it to get
> its contents:
>
> (def user
>(db-ref 193 {:login "fred"}))
>
> => (id user)
> 193
> => @user
> {:login fred}
Wow, this is incredibly cool!
I guess I just saw Ref's as a really special case, this shows how easy it is
to make one, and extend it! :)
Ambrose
--
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: I understand metadata now!
Would it be possible to create something like CL's multiple values this way?
2011/3/25 James Reeves :
> On 25 March 2011 10:41, msappler wrote:
>> Never used metadata until now.
>>
>> I had an insight yesterday that I want to share with you:
>>
>> http://resatori.com/metadata-insight
>
> In my view, it depends whether your :id key is a surrogate key or a natural
> key.
>
> Object metadata should not affect object equality, so if your :id key
> is just an internal database identifier, you could include it as
> metadata.
>
> But if your :id key is exposed to the outside world, then it should
> not be metadata, because changing the :id would change the external
> representation of the object, and therefore affect equality.
>
> I should also point out that if you want information hiding, then
> object composition might be a better solution. For example:
>
> (defprotocol Identifiable
> (id [self] "Return an object's unique id"))
>
> (deftype DBRef [db-id data]
> Identifiable
> (id [_] db-id)
> clojure.lang.IDeref
> (deref [_] data))
>
> (defn db-ref [id data]
> (DBRef. id data))
>
> Then we can get information about the reference, and deref it to get
> its contents:
>
> (def user
> (db-ref 193 {:login "fred"}))
>
> => (id user)
> 193
> => @user
> {:login fred}
>
> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Jesus, how the heck to do anything?
On Thursday, March 24, 2011 2:34:02 PM UTC+1, tbc++ wrote: > > > I didn't have much trouble getting things running. Is > > the CLASSPATH really so much different to the PYTHONPATH, > > LD_LIBRARY_PATH or even the plain old PATH itself? > > No, it's not that much different, except python is a bit more smart > about how things are setup. For instance, if you startup script.py > python will not only search PYTHONPATH, but also search the directory > where the python executable lives, as well as the current path. > > On top of that, python (unlike lein, and I guess java as well) prefers > that all modules be installed in the python home directory. So the end > effect is I have been able to write python projects for years, and > only once have had to set the PYTHONPATH variable. > The same goes for LD_LIBRARY_PATH. The only time I've had to set that > variable is when I'm doing something funky like writing a plugin. > > But the issue is, all these IDEs out there don't follow any of these > methods. So if you want to launch clojure with penumbra, not only do > you have to set the CLASSPATH, but you also have to set the -D > variable to point to the native libs. Even when I finally knew how to > set all this up, it still took me about 3 hours to get La Clojure to > recognize it all. And that was after trying and giving up on > Enclojure. > > And don't even try to compare all this to the CLR...the gac, Visual > Studio, and the way the CLR links assemblies means that I've > never...ever...had to set a CLR path. And I program C# for a living. > > I program Java for a living, and I never had to set CLASSPATH (in order to program in Java). In general my experience with Java software is that you unpack it where you want and it works as-is. I also use ABCL in my spare time (a JVM Common Lisp - for the purpose of this discussion, it makes no difference with Clojure). There, when I don't launch my program through Eclipse (which manages the classpath for me), I just put all the jars in a lib/ directory under the project directory and run java -cp ".*:lib/*" ... yes, you have to write a script once, but then you just forget about it. -- 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: Jesus, how the heck to do anything?
On Mar 25, 11:05 pm, Shantanu Kumar wrote: > Are you using Mac, Linux or Windows? > > Okay, let me list few things out for you (assuming you are on > Windows): Yes, on Windows. Okay, I can give these things a try late tomorrow and post my results back. Thanks for helping. -- 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: I understand metadata now!
It's already possible, but metadata is the wrong tool. Wrap all return
values that "might" have multiple values in a vector, and return/bind
as many elements as you want. Add macros to make it less ugly, stir
awhile, and you have multiple values.
Using metadata for this purpose would have real problems: the metadata
for multiple-values would bubble up unintentionally from some
functions, and not from others, giving the mistaken impression that
the higher-level functions are returning multiple values. Consider:
(defn values [v & vs]
(vary-meta v assoc ::values vs))
(defmacro mv-bind [names val & body]
`(let [~names (cons ~val (-> ~val meta ::values))]
~@body))
(mv-bind [x y] (values {:age 20} "steve")
(if-not y
x
(assoc x :name y)))
This all looks good (aside from the fact that it won't work for types
that can't have metadata, such as integers), right? But from what I
understand of Common Lisp (and that's not a lot), this is a broken
version of its multiple values. Specifically, a function that's not
concerned at all with multiple values, such as conj, will accidentally
return multiple values if its args were carrying around multiple-value
metadata:
(mv-bind [x y] (conj (values [1 2] "whatever") 3 4)
[x y]) ; returns [[1 2 3 4] "whatever"]!
In contrast, here's a snippet of me trying something similar at an
SBCL repl:
* (multiple-value-bind (x y) (values 1 2) (list x y))
(1 2)
* (multiple-value-bind (x y) (identity (values 1 2)) (list x y))
(1 NIL)
On Mar 25, 9:19 am, Joop Kiefte wrote:
> Would it be possible to create something like CL's multiple values this way?
>
> 2011/3/25 James Reeves :
>
>
>
>
>
>
>
> > On 25 March 2011 10:41, msappler wrote:
> >> Never used metadata until now.
>
> >> I had an insight yesterday that I want to share with you:
>
> >>http://resatori.com/metadata-insight
>
> > In my view, it depends whether your :id key is a surrogate key or a natural
> > key.
>
> > Object metadata should not affect object equality, so if your :id key
> > is just an internal database identifier, you could include it as
> > metadata.
>
> > But if your :id key is exposed to the outside world, then it should
> > not be metadata, because changing the :id would change the external
> > representation of the object, and therefore affect equality.
>
> > I should also point out that if you want information hiding, then
> > object composition might be a better solution. For example:
>
> > (defprotocol Identifiable
> > (id [self] "Return an object's unique id"))
>
> > (deftype DBRef [db-id data]
> > Identifiable
> > (id [_] db-id)
> > clojure.lang.IDeref
> > (deref [_] data))
>
> > (defn db-ref [id data]
> > (DBRef. id data))
>
> > Then we can get information about the reference, and deref it to get
> > its contents:
>
> > (def user
> > (db-ref 193 {:login "fred"}))
>
> > => (id user)
> > 193
> > => @user
> > {:login fred}
>
> > - James
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure in Small Pieces -- Literate Clojure
Hello,
I only had time now to look at this.
I am running Ubuntu 10.04 LTS "Lucid Lynx" and on my machine running the
tangle program had always the effect that the clojure.pamphlet file was
reduced to file size 0.
Looking ad the man page for the open system call (man 2 open) says that
there is no version of the open system call with only one parameter.
I've modified the tangle program and now its working.
I've attached the patch.
I cannot imagine that I am the only one with that problem. Am I?
Thanks,
Christian
daly wrote:
On Wed, 2011-03-23 at 00:31 -0700, Christian Schuhegger wrote:
Does a public repository exist (e.g. on github) where people could
clone the repository and potentially contribute?
There is no repository. Everything (including all of the runnable
source) is in a single book. To build a running Clojure REPL and
a PDF copy of the book do:
wget http://literatesoftware.com/clojure.pamphlet
wget http://literatesoftware.com/tangle.c
(the tangle.c source is also in the book so you could extract
it from the pamphlet file instead)
wget http://literatesoftware.com/clojure.pdf
(not really necessary as the next step will create the pdf
but you might want to read it first)
gcc -o tangle tangle.c
tangle clojure.pamphlet Makefile>Makefile
make
You end up with a running Clojure REPL and a PDF of the book.
To make changes just modify the clojure.pamphlet file and type
make
You can send me your complete changed version or do
diff -Naur clojure.pamphlet.original clojure.pamphlet.new>clojure.patch
The basic philosophy of literate programming is that you
are writing for other people, not for the machine. This book
is an attempt to make the Clojure source code readable by
more people. What we are trying to do is start from the ideas
and move to the code so people understand why the code does
what it does.
Tim Daly
--
Christian Schuhegger
http://www.el-chef.de/
--
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--- orig/tangle.c 2011-02-16 15:18:40.0 +0100
+++ tangle.c 2011-03-25 19:37:30.035951116 +0100
@@ -3,6 +3,8 @@
#include
#include
#include
+#include
+#include
#define DEBUG 0
@@ -134,7 +136,7 @@
perror("Usage: tangle filename chunkname");
exit(-1);
}
- fd = open(argv[1]);
+ fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror("Error opening file for reading");
exit(-2);
open o_RDONLY patch applied
Fixed. Thanks. --Tim On Fri, 2011-03-25 at 19:46 +0100, Christian Schuhegger wrote: > Hello, > > I only had time now to look at this. > > I am running Ubuntu 10.04 LTS "Lucid Lynx" and on my machine running the > tangle program had always the effect that the clojure.pamphlet file was > reduced to file size 0. > > Looking ad the man page for the open system call (man 2 open) says that > there is no version of the open system call with only one parameter. > I've modified the tangle program and now its working. > > I've attached the patch. > > I cannot imagine that I am the only one with that problem. Am I? > > Thanks, > Christian > > daly wrote: > > > > On Wed, 2011-03-23 at 00:31 -0700, Christian Schuhegger wrote: > >> Does a public repository exist (e.g. on github) where people could > >> clone the repository and potentially contribute? > > > > > > > > There is no repository. Everything (including all of the runnable > > source) is in a single book. To build a running Clojure REPL and > > a PDF copy of the book do: > > > > wget http://literatesoftware.com/clojure.pamphlet > > wget http://literatesoftware.com/tangle.c > > (the tangle.c source is also in the book so you could extract > > it from the pamphlet file instead) > > wget http://literatesoftware.com/clojure.pdf > > (not really necessary as the next step will create the pdf > > but you might want to read it first) > > gcc -o tangle tangle.c > > tangle clojure.pamphlet Makefile>Makefile > > make > > > > You end up with a running Clojure REPL and a PDF of the book. > > > > To make changes just modify the clojure.pamphlet file and type > > make > > > > You can send me your complete changed version or do > > diff -Naur clojure.pamphlet.original clojure.pamphlet.new>clojure.patch > > > > The basic philosophy of literate programming is that you > > are writing for other people, not for the machine. This book > > is an attempt to make the Clojure source code readable by > > more people. What we are trying to do is start from the ideas > > and move to the code so people understand why the code does > > what it does. > > > > Tim Daly > > > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Jesus, how the heck to do anything?
On Thu, 24 Mar 2011 06:22:49 -0700 (PDT) Meikel Brandmeyer wrote: > On 24 Mrz., 13:09, Baishampayan Ghose wrote: > IMHO the Java bashing is overrated. Coming from a polyglot-but-non- > java background, I didn't have much trouble getting things running. Is > the CLASSPATH really so much different to the PYTHONPATH, > LD_LIBRARY_PATH or even the plain old PATH itself? Actually, that would be Java infrastructure bashing. Java-bashing would be complaining about lack of multiple inheritance, the protection mechanisms it inherited from C++, the variable declaration syntax it inherited from C (anyone care to name another language with a variable declaration syntax baroque (or broke) enough to cause someone to write a program to translate between it and English?), etc. There does appear to be one major difference (at least on Unix) between CLASSPATH and your examples: the default values work for simple scripts. In the case of PYTHONPATH & LD_LIBRARY_PATH, the default is "unset", and the infrastructure takes care of checking the obvious places for things. Maybe that's also true with a good Java install, and the default clojure install just isn't "java-aware" enough to put the clojure jar files in the right place. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Noob Question - Clojure number rounding
Thanks so much for your answers.
OK. So from the solutions above I understand that Clojure does not
have C#'s equivalent of Math.round(7.127298, 2), and requires either
using some custom method or Java's rounding?
I think I'll rather go with the Java-interop approach.
On Mar 23, 11:13 pm, Joost wrote:
> On Mar 23, 8:07 pm, Meikel Brandmeyer wrote:
>
>
>
> > Hi,
>
> > a bit naive, but it seems to work…
>
> > user=> (defn round
> > [x & {p :precision}]
> > (if p
> > (let [scale (Math/pow 10 p)]
> > (-> x (* scale) Math/round (/ scale)))
> > (Math/round x)))
> > #'user/round
> > user=> (round 78.37898794)
> > 78
> > user=> (round 78.37898794 :precision 3)
> > 78.379
>
> > There are probably thousand reasons not to do that…
>
> Most important one being that it won't be reliable. Floats are
> fundamentally not compatible with decimal rounding. You'll have to
> switch to some other representation like (big) decimals, fixed point
> or strings to get it.
--
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: Namespace and file structuring
I try to use namespaces in layers. Each namespace defines an "interface" as a set of functions, and only calls functions of the layer(s) "below" it. I build from small utilities and Java interop at the "bottom" layer, to application-level logic in the "middle" layers, with the external API in the "top" layer. This helps with the one hard-and-fast rule of Clojure namespaces: no circular dependencies. If namespace A depends on namespace B, then namespace B cannot depend on namespace A. For naming, the Java package convention is pretty good at avoiding conflicts. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Namespace and file structuring
On 25 March 2011 01:05, Terje Dahl wrote: > In Java, the language forces you to have more or less one class pr > class-file, and you are encouraged to group class-files in packages. > So, is it as simple as saying that that namespaces are analogous to > class-files, and clj-files are analogous to packages? Typically, each .clj file will have its own namespace. Clojure uses the namespace to find where the corresponding .clj file is on the classpath. > Also, while we are at it, what are the naming conventions? > The same as in Java packages? > So I would use: "no.terjedahl.some.namespace.here" ? Some people use this convention, but the majority of Clojure libraries tend to use the following convention: library-name.some.namespaces For instance, here are some namespaces for the Ring library: ring.middleware.params ring.util.response You can use namespaces of only one part, such as "lancet", but this will result in class-files without a package. As I understand it, this is generally discouraged, so in the cases where a library only needs one namespace part, a ".core" is usually appended, e.g. "clout.core". I don't think there are any official recommendations, but these are the conventions used by many Clojure libraries, and build tools like Leiningen. - James -- 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: Namespace and file structuring
On Fri, Mar 25, 2011 at 6:00 PM, Stuart Sierra
wrote:
> I try to use namespaces in layers. Each namespace defines an "interface" as
> a set of functions, and only calls functions of the layer(s) "below" it. I
> build from small utilities and Java interop at the "bottom" layer, to
> application-level logic in the "middle" layers, with the external API in the
> "top" layer.
>
> This helps with the one hard-and-fast rule of Clojure namespaces: no
> circular dependencies. If namespace A depends on namespace B, then
> namespace B cannot depend on namespace A.
Unless you use dependency injection tricks. E.g.:
(ns foo)
(def somemap (atom {}))
(defn foo-inject [k v]
(swap! somemap assoc k v))
(defn foo-dosomething [a b c]
(let [d ((@somemap :injected-fn) a)]
...))
...
(ns bar)
(defn some-fn [a]
...
... depends indirectly on foo-dosomething,
... but avoids unbounded recursion if called
... by foo-dosomething
...)
(defn bar-init []
(foo/foo-inject :injected-fn some-fn)
...)
As long as bar-init is called before anything that calls
foo-dosomething/bar-init/etc., and the some-fn/foo-dosomething
recursion remains bounded, this is OK.
I had this come up recently in connection with a fairly complex system
that had to bootstrap itself. There was a low-level DAL that had to
fall back on certain in-memory defaults, which had to hold references
to functions that operated at a much higher level, eventually calling
a lookup function in some cases that depended in turn on the low-level
DAL. Cramming the DAL, the lookup engine, and some higher level
abstractions into a single namespace seemed excessive, and I wanted
these as three separate layers, but then the lowest of these layers
needed maps containing objects containing functions defined in the
highest.
To be exact, the lookup engine knows natively how to search data of
type X. But the system is extensible to be able to search data of
types Y, Z, etc. with the added search know-how being itself supplied
as data of type X. So the lookup engine uses the type of search to
first look up the appropriate lookup engine, if the type isn't X. This
leads to the lookup engine calling the DAL, which in turn needs to be
able to supply the "how to search for stuff" data of type X as soon as
the system has started up, which data needs to contain information on
searching for data of type Y as that's built in and not user-defined
and needed at a higher level of the system, and that information
contains search functions themselves, which punt to the lookup engine
...
The only alternative to the in-memory bootstrap procedure noted above
would be to rely on certain disk files being created ahead of the
first execution of the program on a new system. With the bootstrap
procedure, the system can easily generate the disk files if they're
absent, can usually recover if they get scrogged (and certain files
can be deleted to make it recover otherwise), and can eschew wasting
disk space storing "what it already knows", including only user-added
information in disk files.
For managing circular dependencies in general, the only alternative to
using a mutable of some sort to inject them is to defer their
resolution to runtime. Example 1:
(ns foo)
(defn foo-dosomething [a b c]
(let [d ((@(ns-resolve 'bar 'some-fn)) a)]
...))
...
(ns bar)
(defn some-fn [a]
...
... depends indirectly on foo-dosomething,
... but avoids unbounded recursion if called
... by foo-dosomething
...)
This variation just finds some-fn in namespace bar at runtime, so ns
foo will compile without ns bar, ns bar can then be compiled, and then
at runtime everything works. If things are slowed too much at runtime
in foo-dosomething, the resolution can be cached:
(ns foo)
(def some-fn (atom nil))
(defn foo-dosomething [a b c]
(let [f @some-fn
f (if f f (reset! some-fn @(ns-resolve 'bar 'some-fn)))
d (f a)]
...))
or you can define and use a memoized function that wraps @(ns-resolve x y).
If there are going to be many of these calls in your codebase you will
want to sugar things up:
(defn lookup [sym]
@(ns-resolve (symbol (namespace sym)) (symbol (name sym
(def lookup (memoize lookup))
(defmacro use [sym & args]
`((lookup (quote ~sym)) ~@args))
...
(ns foo)
(defn foo-dosomething [a b c]
(let [d (use bar/some-fn a)]
...))
This is nearly as nice as apply, though you have to fully qualify the
symbol bar/some-fn. The downside is, no compile time checking for
typos etc.; if there's no bar/some-fn at runtime you'll get an NPE
thrown out of lookup when foo-dosomething is called, as ns-lookup will
return nil and (deref nil), well ...
--
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...@
Re: Jesus, how the heck to do anything?
Hi, I actually created ClojureW for exact reason. No need to know jar files, lein, bash, maven.. nothing. It does not matter if you use Window, Linux, Mac, or Cygwin. Here is how easy it is: 1. download this file: https://bitbucket.org/kasim/clojurew/get/tip.zip 2. Unzip it to wherever you want. 3. double click clj file to get a REPL and start typing clojure or you cant just use a text editor to create hello.clj file and run: clj hello.clj from within bin directory. How easy cat it get? I actually announced this in this list and suggested it to be put in the getting started page of assembla. I really think Clojure community need to make it easier for a noob to get started. Please vote for this to be put it in the assembla for the total noob like "ultranewb". Cheers, Kasim -- 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
Random "IllegalArgumentException: No distinct mapping found" after replacing defmultis with protocols
Hi all, in my graph querying library, I had several defmultis that simply dispatched on the class of the first argument. The guys on #clojure suggested using protocols instead to get a better performance. So I did, and basically it works fine and seems to be a bit faster than before. However, when running my tests (lein test) I get errors. Most of the time my coupling-by-objects test errors, but sometimes it's another test. And some other times, all tests pass without error. (The same applies for running the tests at the REPL, or simply executing the forms contained in my tests.) A complete backtrace is below. I have no clue what it should tell me. I checked all the shown line numbers in my own code (funql), but I cannot see how these places might produce an error. I switched off AOT, deleted all compiled class files, but that doesn't change anything. I run clojure 1.2.0. I've tried the current 1.3.0 master snapshot, but that fails exactly the same. If someone wants to try it out for himself, you can clone my mercurial repository: $ hg clone https://anonymous:sec...@hg.uni-koblenz.de/horn/funql $ lein deps $ lein test Any pointers are highly welcome. I owe a beer to whoever finds the bug or gives me a pointer that helps finding it! Bye, Tassilo, who stared the last 3 hours at the code without any luck... ERROR in (test-reachable-vertices) (LazySeq.java:47) expected: (= 6117 (count (p-apply (vertex (jg) 12) [p-* <->]))) actual: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException: No distinct mapping found at clojure.lang.LazySeq.sval (LazySeq.java:47) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59) clojure.core$chunk_next.invoke (core.clj:582) clojure.core$r.invoke (core.clj:798) clojure.core$into.invoke (core.clj:2615) funql.core$into_oset.doInvoke (core.clj:81) clojure.lang.RestFn.applyTo (RestFn.java:140) clojure.core$apply.invoke (core.clj:540) funql.core$___.invoke (core.clj:476) funql.core$_LT___GT_.invoke (core.clj:527) funql.core$_LT___GT_.invoke (core.clj:523) funql.core$p_apply.invoke (core.clj:453) funql.core$p__PLUS_.invoke (core.clj:601) funql.core$p__STAR_.invoke (core.clj:616) clojure.lang.AFn.applyToHelper (AFn.java:165) clojure.lang.AFn.applyTo (AFn.java:151) clojure.core$apply.invoke (core.clj:542) funql.core$p_apply.invoke (core.clj:455) funql.test.core$fn__792$fn__805.invoke (core.clj:263) funql.test.core/fn (core.clj:263) clojure.test$test_var$fn__6131.invoke (test.clj:688) clojure.test$test_var.invoke (test.clj:688) clojure.test$test_all_vars$fn__6135$fn__6142.invoke (test.clj:704) clojure.test$default_fixture.invoke (test.clj:658) clojure.test$test_all_vars$fn__6135.invoke (test.clj:704) clojure.test$default_fixture.invoke (test.clj:658) clojure.test$test_all_vars.invoke (test.clj:700) clojure.test$test_ns.invoke (test.clj:723) clojure.core$map$fn__3695.invoke (core.clj:2096) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.Cons.next (Cons.java:39) clojure.lang.RT.boundedLength (RT.java:1186) clojure.lang.RestFn.applyTo (RestFn.java:131) clojure.core$apply.invoke (core.clj:542) clojure.test$run_tests.doInvoke (test.clj:738) clojure.lang.RestFn.applyTo (RestFn.java:138) clojure.core$apply.invoke (core.clj:540) user$eval1350$fn__1351.invoke (NO_SOURCE_FILE:1) user$eval1350.invoke (NO_SOURCE_FILE:1) clojure.lang.Compiler.eval (Compiler.java:5424) clojure.lang.Compiler.eval (Compiler.java:5415) clojure.lang.Compiler.eval (Compiler.java:5415) clojure.lang.Compiler.eval (Compiler.java:5391) clojure.core$eval.invoke (core.clj:2382) clojure.main$eval_opt.invoke (main.clj:235) clojure.main$initialize.invoke (main.clj:254) clojure.main$null_opt.invoke (main.clj:279) clojure.main$main.doInvoke (main.clj:354) clojure.lang.RestFn.invoke (RestFn.java:422) clojure.lang.Var.invoke (Var.java:369) clojure.lang.AFn.applyToHelper (AFn.java:165) clojure.lang.Var.applyTo (Var.java:482) clojure.main.main (main.java:37) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException: No distinct mapping found at clojure.lang.LazySeq.sval (LazySeq.java:47) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.RT.seq (RT.java:450) clojure.core$seq.invoke (core.clj:122) clojure.core$map$fn__3695.invoke (core.clj:2088) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59) clojure.core$chunk_next.invoke (core.clj:582) clojure.core$r.invoke (core.clj:798) clojure.core$into.invoke (core.clj:2615) funql.core$into_oset.doInvoke (core
Re: Random "IllegalArgumentException: No distinct mapping found" after replacing defmultis with protocols
That error message is coming from some use of (case), usually in your code but conceivably from somewhere in Clojure. It tries to do some clever bit-fiddling to generate a constant-time-dispatch on the hashcodes of its clauses, and if that fails it throws a compiler error (arguably it could degrade into to a cond, but it doesn't). Given that you don't use case at all, and the backtrace suggests the case call is in dispatching for the protocol, it sounds to me like a bug in the protocol dispatcher. The "interesting" exception usually comes after the last "caused by" message, and the first few frames are the ones that actually caused the issue. So here's yours: Caused by: java.lang.IllegalArgumentException: No distinct mapping found at clojure.core$min_hash.invoke (core.clj:5270) clojure.core$expand_method_impl_cache.invoke (core_deftype.clj: 403) clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:472) funql.core$eval293$fn__294$G__284__309.invoke (core.clj:408) funql.core$eval324$fn__325$fn__328.invoke (core.clj:432) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:63) clojure.lang.RT.seq (RT.java:450) clojure.core$seq.invoke (core.clj:122) So line 432 calls iseq, and the macroexpansion of your code at line 408 calls into some kind of internal protocol-dispatch-cache, which tries to do a minhash in order to figure out how to switch through a case block, which barfs. On Mar 25, 5:15 pm, Tassilo Horn wrote: > Hi all, > > in my graph querying library, I had several defmultis that simply > dispatched on the class of the first argument. The guys on #clojure > suggested using protocols instead to get a better performance. So I > did, and basically it works fine and seems to be a bit faster than > before. > > However, when running my tests (lein test) I get errors. Most of the > time my coupling-by-objects test errors, but sometimes it's another > test. And some other times, all tests pass without error. (The same > applies for running the tests at the REPL, or simply executing the forms > contained in my tests.) > > A complete backtrace is below. I have no clue what it should tell me. > I checked all the shown line numbers in my own code (funql), but I > cannot see how these places might produce an error. > > I switched off AOT, deleted all compiled class files, but that doesn't > change anything. I run clojure 1.2.0. I've tried the current 1.3.0 > master snapshot, but that fails exactly the same. > > If someone wants to try it out for himself, you can clone my mercurial > repository: > > $ hg clonehttps://anonymous:sec...@hg.uni-koblenz.de/horn/funql > $ lein deps > $ lein test > > Any pointers are highly welcome. I owe a beer to whoever finds the bug > or gives me a pointer that helps finding it! > > Bye, > Tassilo, who stared the last 3 hours at the code without any luck... > > ERROR in (test-reachable-vertices) (LazySeq.java:47) > expected: (= 6117 (count (p-apply (vertex (jg) 12) [p-* <->]))) > actual: java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.RuntimeException: java.lang.IllegalArgumentException: No distinct > mapping found > at clojure.lang.LazySeq.sval (LazySeq.java:47) > clojure.lang.LazySeq.seq (LazySeq.java:56) > clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59) > clojure.core$chunk_next.invoke (core.clj:582) > clojure.core$r.invoke (core.clj:798) > clojure.core$into.invoke (core.clj:2615) > funql.core$into_oset.doInvoke (core.clj:81) > clojure.lang.RestFn.applyTo (RestFn.java:140) > clojure.core$apply.invoke (core.clj:540) > funql.core$___.invoke (core.clj:476) > funql.core$_LT___GT_.invoke (core.clj:527) > funql.core$_LT___GT_.invoke (core.clj:523) > funql.core$p_apply.invoke (core.clj:453) > funql.core$p__PLUS_.invoke (core.clj:601) > funql.core$p__STAR_.invoke (core.clj:616) > clojure.lang.AFn.applyToHelper (AFn.java:165) > clojure.lang.AFn.applyTo (AFn.java:151) > clojure.core$apply.invoke (core.clj:542) > funql.core$p_apply.invoke (core.clj:455) > funql.test.core$fn__792$fn__805.invoke (core.clj:263) > funql.test.core/fn (core.clj:263) > clojure.test$test_var$fn__6131.invoke (test.clj:688) > clojure.test$test_var.invoke (test.clj:688) > clojure.test$test_all_vars$fn__6135$fn__6142.invoke (test.clj:704) > clojure.test$default_fixture.invoke (test.clj:658) > clojure.test$test_all_vars$fn__6135.invoke (test.clj:704) > clojure.test$default_fixture.invoke (test.clj:658) > clojure.test$test_all_vars.invoke (test.clj:700) > clojure.test$test_ns.invoke (test.clj:723) > clojure.core$map$fn__3695.invoke (core.clj:2096) > clojure.lang.LazySeq.sval (LazySeq.java:42) > clojure.lang.LazySeq.seq (LazySeq.java:56) > clojure.lang.Cons.next (Cons.java:39) > clojure.lang.RT.boundedLength (RT.java:1186) > clojure.lang.RestFn.applyTo (RestFn.java:131) > clo
Re: Random "IllegalArgumentException: No distinct mapping found" after replacing defmultis with protocols
Alan writes: Hi Alan, > That error message is coming from some use of (case), usually in your > code but conceivably from somewhere in Clojure. It tries to do some > clever bit-fiddling to generate a constant-time-dispatch on the > hashcodes of its clauses, and if that fails it throws a compiler error > (arguably it could degrade into to a cond, but it doesn't). > > Given that you don't use case at all, and the backtrace suggests the > case call is in dispatching for the protocol, it sounds to me like a > bug in the protocol dispatcher. I would have preferred a bug in my code... > Caused by: java.lang.IllegalArgumentException: No distinct mapping > found > at clojure.core$min_hash.invoke (core.clj:5270) > clojure.core$expand_method_impl_cache.invoke (core_deftype.clj: > 403) > clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:472) > funql.core$eval293$fn__294$G__284__309.invoke (core.clj:408) > funql.core$eval324$fn__325$fn__328.invoke (core.clj:432) > clojure.lang.LazySeq.sval (LazySeq.java:42) > clojure.lang.LazySeq.seq (LazySeq.java:63) > clojure.lang.RT.seq (RT.java:450) > clojure.core$seq.invoke (core.clj:122) > > So line 432 calls iseq, and the macroexpansion of your code at line > 408 calls into some kind of internal protocol-dispatch-cache, which > tries to do a minhash in order to figure out how to switch through a > case block, which barfs. If it helps, I checked out the current clojure git sources and added the keys argument of `min-hash' to the exception message. keys is a seq of java.lang.Class objects (~300): (de.uni_koblenz.jgralab.grabaja.java5schema.impl.std.ReversedIsCalledByMethodImpl de.uni_koblenz.java.impl.std.arrays.ArraySelectorImpl [..] de.uni_koblenz.jgralabtest.schemas.greqltestschema.impl.std.junctions.CrossroadImpl de.uni_koblenz.java.impl.std.statements.ExpressionStatementImpl) This seq contains the implementation classes of all my loaded graph's metamodels. Beside these Impl-classes, those all have a defining interface, and those line up to a top-level inheritance hierarchy AttributedElement / \ GraphElement Graph / \ VertexEdge which are the types my protocols dispatch on. I'm happy to help with any debugging, patch-testing, whatsoever. Bye, Tassilo -- 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
int or long as map key
I have just started learning Clojure.
Thank you for developing a wonderful language.
Is this behavior by design?
If so, how can I loosely use numerical values as keys?
Clojure 1.2.0
user=> (def m {1 10 2 20})
#'user/m
user=> (m 2)
20
user=> (m (long 2))
nil
Regards,
Daigo
--
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: ClojureCLR in production ?
Hi Jules On Wed, Mar 23, 2011 at 12:34 AM, Jules wrote: > I was wondering whether anyone else had ClojureCLR in production and > how they felt about it ? Whether it will be mature enough in say 3 > months to support a production app ? I've been using it for a small project and haven't run into any negative issues with it at all - seems to work as advertised for my purposes. Many thanks to David Miller for maintaining such a solid port. Regards, Timothy -- 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: int or long as map key
On Fri, Mar 25, 2011 at 9:18 PM, daigo wrote:
> I have just started learning Clojure.
> Thank you for developing a wonderful language.
>
> Is this behavior by design?
> If so, how can I loosely use numerical values as keys?
>
> Clojure 1.2.0
> user=> (def m {1 10 2 20})
> #'user/m
> user=> (m 2)
> 20
> user=> (m (long 2))
> nil
>
> Regards,
> Daigo
>
This is resolved in the upcoming version of Clojure (1.3.0). The alphas are
stable enough to develop with in my experience.
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
