Re: Error with eval syntax-quote & PersistentArrayMap
You are using macroexpand wrong. Don't eval anything when you are
macroexpanding - the point is to see what code will be executed.
The issue Kevin is bringing to your attention is evident in the first
code snippet you gave:
... :content ({:tag :profileDetail, :name
"first.name", :value "stub", :content nil}
{:tag :profileDetail, :name "
last.name", :value "stub", :content nil} ...)
You intend :content to be a key whose value is a list of maps; but the
reader evals the forms it sees, and lists are function calls. So, it
calls the first map as a function, with the next three as arguments.
Maps don't like that many arguments, and you get the error you saw.
On Apr 25, 9:46 pm, Timothy Washington wrote:
> Oh sorry, were the colors off? Let's try this.
>
> The map was actually unquoted. 'etal' (which was null) was unquote-spliced.
> I excluded it for clarity:
> * user=> `(commands/add ~processed) *
> * result=> ( ) ;; ** first in this list is a function
> *
>
> Now, if I try to eval that, I get the said error.
> * user=> (eval `(commands/add ~processed))*
> * result=> java.lang.IllegalArgumentException: ...*
>
> And I had tried macroexpand (here and in the containing function), and got
> the same error:
> * user=> (macroexpand (eval `(commands/add ~processed)))*
> * result=> java.lang.IllegalArgumentException: ...*
>
> You're right that the repl is using the map as a function. But I don't
> understand why when 'commands/add' function was the first thing in the
> return list. And macroexpand is yielding the same error . This is what had
> me so perplexed. Hopefully this reads a bit better.
>
> Thanks
> Tim
>
>
>
>
>
>
>
> On Tue, Apr 26, 2011 at 12:00 AM, Kevin Downey wrote:
> > sorry I cannot read your email
>
> > On Mon, Apr 25, 2011 at 8:24 PM, Timothy Washington
> > wrote:
> > > Hey Kevin, thanks for getting back to me.
>
> > > The splice is 'etal' (which is null). I should have excluded it for
> > > clarity. What you're actually seeing is the map being unquoted:
> > > user=> `(commands/add ~processed ~@etal)
> > > (commands/add {:tag :user, :username "stub" ... }) ;; 'etal' does not
> > show
> > > up in what gets evaluated - ** first in this list is a function
>
> > > Now, if I try to eval that, I get the said error.
> > > user=> (eval `(commands/add ~processed))
> > > java.lang.IllegalArgumentException: Wrong number of args (3) passed to:
> > > PersistentArrayMap (NO_SOURCE_FILE:324)
>
> > > And I had tried macroexpand (here and in the containing function), and
> > got
> > > the same error:
> > > user=> (macroexpand (eval `(commands/add ~processed)))
> > > java.lang.IllegalArgumentException: Wrong number of args (3) passed to:
> > > PersistentArrayMap (NO_SOURCE_FILE:324)
>
> > > You're right that the repl is using the map as a function. But I don't
> > > understand why when 'commands/add' function was the first thing in the
> > > return list. And macroexpand is yielding the same error . This is what
> > had
> > > me so perplexed. Thanks again for the feedback. It's something small that
> > > I'm missing.
> > > Tim
>
> > > On Mon, Apr 25, 2011 at 10:40 PM, Kevin Downey
> > wrote:
>
> > >> your map is being spliced in to the output, but your output contains
> > >> lists (...) which are interpreted as functions, and the first thing in
> > >> the list is a map, makes take 1-2 args, your list forms with maps as
> > >> the operator have more that 2 args. please use macroexpand.
>
> > >> On Mon, Apr 25, 2011 at 7:29 PM, Timothy Washington
> > >> wrote:
> > >> > Hey all,
>
> > > --
> > > 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
>
> > --
> > And what is good, Phaedrus,
> > And what is not good—
> > Need we ask anyone to tell us these things?
>
> > --
> > 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/clojur
Aw: Merging two maps based on ids
Hi, you can construct the output sequence from your input sequences. (defn merge-data [data-orig data-override] (let [override-ids (set (map :id data-override))] (concat data-override (remove (comp override-ids :id) data-orig If you need your output sorted you can also add a "(sord-by :id ...)" around the concat. 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
defnk pre- and post-conditions
G'day folks, I've recently started using defnk more widely, and just run into the fact that pre and post conditions won't work. I understand that this is because they are a clojure special form and therefore cannot be supported by the macro - is that right? Is there any way to work around that? Has there been any discussion on adding keyword arguments to the core language? I'd be interested to hear if people think there is a better alternative to kwargs in clojure. Cheers, 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
Aw: defnk pre- and post-conditions
Hi,
clojure supports keyword arguments for a quote some time now.
(defn foo
[positional1 ... positionalN & {:keys [kw1 ... kwn]}]
...)
The syntax is the usual destructuring syntax for maps. So you can specify
defaults via :or etc. And even have none keyword keys.
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: Understanding the Clojure source-code and functionality
This looks conceptually very interesting. This is the first time I have ever heard of "literate programming". However, the project is far from complete. And while I could even consider contributing to it later, for now, it doesn't give me much. And also, while converting clojure to a literate programming (LP) project is a great idea, it is only useful if the main team is part of that process. For isn't the idea behind LP that one develop the concepts, code, and explanations at the same time? So if Hickey et al do all there work separately (outside of the of LP), then someone else has to constantly follow behind and update and alter the LP-version, constantly struggling to keep the two version syncronized. On Apr 18, 4:37 pm, Armando Blancas wrote: > You may want to follow this thread and look for the latest version of > Clojure in Small Pieces: > > http://groups.google.com/group/clojure/browse_thread/thread/460417fe4... > > On Apr 17, 12:27 pm,TerjeDahl wrote: > > > > > I would very much like to study and understand how Clojure works > > "under the hood". > > > Yes, I have downloaded the source and looked at it. > > Yes, I have all the books about programming in Clojure. > > > But what I am looking for is learning and understanding how the > > Clojure JVM-code actually works. > > And how it interacts with with the CLJ-files. > > About underlying principals and functionality in general, > > considerations in relation to Java and the JVM, and where the > > development path goes from here. > > > Is anything written on the subject? > > Is there a book under way? > > > Perhaps this is an interesting project on its own - and important for > > developing understanding for Clojure, and helping aspiring developers > > (such as myself) to participate in the development of Clojure. -- 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.contrib.sql => clojure.java.jdbc - looking for feedback!
>> Also see related problems reported by others: >> http://osdir.com/ml/clojure/2010-10/msg00290.html (sorry, can't find >> it on the group.) > > Yes, resultset-seq does lowercase the column names and it doesn't > translate between - / _ either. But that's not part of c.j.j so, > whilst I may agree with the criticisms of it, I can't actually fix > that :) > > Perhaps someone from Clojure/core could speak to resultset-seq's behavior? I don't want to make a breaking change to the existing API, but in a world there there is an actively-maintained clojure.java.jdbc I don't think a resultset function in core makes a lot of sense anyway. How about we mark core's resultset-seq as deprecated, with a link to the new project? Then c.j.j. can do a better resultset-seq, and we will leave the old fn in core for at least on major release cycle. Sound ok? Stu Stuart Halloway Clojure/core http://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: Aw: defnk pre- and post-conditions
On Tue, 26 Apr 2011 07:27:52 -0400, Meikel Brandmeyer wrote:
clojure supports keyword arguments for a quote some time now.
(defn foo
[positional1 ... positionalN & {:keys [kw1 ... kwn]}]
...)
This is used extensively in Pallet but has a couple of drawbacks.
- Repetition of keywords to specify defaults
- Repetition of keywords and defaults in doc strings
- The defaulted argument values are not available as a map
- No flag for presence of specified keyword (à la CL)
Inspired by a discussion [1] on supporting shFlags in stevedore, I drafted
a defnkw [2] that allows for the following syntax:
(defnkw foo
"My foo"
[positional1 … positionalN
& [[kw1 description1 default1]
[kw2 description2]]]
…)
and automatically generates a suffix to the doc string.
(doc foo) =>
My foo
- kw1 description1. Default default1.
- kw2 description2.
The formatting of the generated doc string can obviously be improved, and
it is not obvious to me what syntax to use for naming the keyword option
map (:as). This approach would allow defaulted values to be merged back
into the option map. Support for presence flags would require an extra
element in the specification vector (e.g. [description default flag?])
An alternative would be to use a more defnk like syntax:
(defnkw foo
"My foo"
[positional1 … positionalN
& :kw1 [description1 default1]
:kw2 description2]
…)
I would be interested in any comments.
[1] https://github.com/pallet/stevedore/pull/1
[2]
https://github.com/pallet/common/blob/feature%2Fdefn-for-kw-args/src/pallet/common/core.clj
--
Hugo Duncan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Aw: defnk pre- and post-conditions
On Tue, Apr 26, 2011 at 8:26 PM, Hugo Duncan wrote:
>
> Inspired by a discussion [1] on supporting shFlags in stevedore, I drafted
> a defnkw [2] that allows for the following syntax:
>
> (defnkw foo
> "My foo"
> [positional1 … positionalN
>& [[kw1 description1 default1]
> [kw2 description2]]]
> …)
>
> The formatting of the generated doc string can obviously be improved, and
> it is not obvious to me what syntax to use for naming the keyword option map
> (:as). This approach would allow defaulted values to be merged back into the
> option map. Support for presence flags would require an extra element in
> the specification vector (e.g. [description default flag?])
> An alternative would be to use a more defnk like syntax:
>
> (defnkw foo
> "My foo"
> [positional1 … positionalN
>& :kw1 [description1 default1]
> :kw2 description2]
> …)
>
>
Here's an interesting alternative:
(defnkw foo
"My foo"
[positional1 ... positionalN
& {:kw1 {:doc "The kw1 argument"
:default default1}
:kw2 {:doc "Another"
:default blah
:as wheee}
:kw2 {}} :as options]
We can specify an :as key on the entire option map.
Maps are more flexible than vectors for attributes. :doc, :default, :as are
fairly descriptive
and other attributes can easily be added. There would be defaults for each
key.
I've put a spin on the CL defun shortcut for renaming keyword args (:kw2
will be bound to wheee).
See "Keyword Parameters": http://www.gigamonkeys.com/book/functions.html
This is an alternative which is much closer to CL's method:
& {[:kw2 wheee] {... atrs.. ]}
On the whole it seems pretty readable, but may be misleading with the { }
syntax.
It's also markedly more verbose.
> I would be interested in any comments.
>
>
> [1] https://github.com/pallet/stevedore/pull/1
> [2]
> https://github.com/pallet/common/blob/feature%2Fdefn-for-kw-args/src/pallet/common/core.clj
> --
> Hugo Duncan
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
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.contrib.sql => clojure.java.jdbc - looking for feedback!
> > > Yes, resultset-seq does lowercase the column names and it doesn't > translate between - / _ either. But that's not part of c.j.j so, > whilst I may agree with the criticisms of it, I can't actually fix > that :) > > There is justification for resultset-seq's current behaviour, even if it isn't to everyone's preference. Down-casing the column names ensures that comparisons done in clojure are done without regard to case, just as they would be in SQL. For example, queries of two views can be joined in clojure, even if the author of the view hasn't deliberately matched the case of all the column names. Typically I find queries and views are not consistent in case because in SQL there is no requirement for them to be. I don't want to have to convince database people to change their code because I'm using a 'weird' tool to process the results. > I don't want to make a breaking change to the existing API, but in a world > there there is an actively-maintained clojure.java.jdbc I don't think a > resultset function in core makes a lot of sense anyway. > > How about we mark core's resultset-seq as deprecated, with a link to the > new project? Then c.j.j. can do a better resultset-seq, and we will leave > the old fn in core for at least on major release cycle. > I use resultset-seq everywhere. I don't mind us deprecating it, if a better version is available elsewhere (but please allow the option of down-casing); but is there really any need to remove a working function from core? I'm not keen on introducing gratuitous back-compat issues. Can we arrange for the deprecated core version to call the c.j.j version, passing any options to preserve current behaviour as much as possible, and to fail at runtime if that library is not present? -- 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: pallet.thread-expr, a macro lib for use with -> argument threading
Agreed; these do look real interesting. I keep meaning to try them. I've just been a little busy lately;) On Apr 22, 1:47 pm, Nicolas Buduroi wrote: > This is a very interesting set of macros, I'll certainly use some of them. > In fact I think this library should at least make it to clojure.contrib! > > BTW, there's a small error in the when-not-> docstring, the result should be > 1. -- 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: Slamhound (for reconstructing ns forms)
this looks awesome, tried it out on a project i have but sadly got the exception below. i'll try and figure it out later when i have more time to see if its something specific to my project, but thought i would let you know in case it is something obvious (it failed from both slime and lein) Exception in thread "main" java.lang.Exception: prefix cannot be nil (NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5440) at clojure.lang.Compiler.eval(Compiler.java:5415) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at slam.hound.regrow$check_for_failure.invoke(regrow.clj:31) at slam.hound.regrow$regrow.invoke(regrow.clj:72) at slam.hound.regrow$regrow.invoke(regrow.clj:70) at slam.hound$reconstruct.invoke(hound.clj:10) at user$eval368.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5424) at clojure.lang.Compiler.eval(Compiler.java:5415) at clojure.lang.Compiler.eval(Compiler.java:5415) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$eval_opt.invoke(main.clj:235) at clojure.main$initialize.invoke(main.clj:254) at clojure.main$null_opt.invoke(main.clj:279) at clojure.main$main.doInvoke(main.clj:354) at clojure.lang.RestFn.invoke(RestFn.java:422) at clojure.lang.Var.invoke(Var.java:369) at clojure.lang.AFn.applyToHelper(AFn.java:165) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: java.lang.Exception: prefix cannot be nil at clojure.core$load_libs.doInvoke(core.clj:4802) at clojure.lang.RestFn.applyTo(RestFn.java:138) at clojure.core$apply.invoke(core.clj:544) at clojure.core$use.doInvoke(core.clj:4880) at clojure.lang.RestFn.invoke(RestFn.java:409) at clj_lbm.core$eval386$loading__4410__auto387.invoke(NO_SOURCE_FILE:1) at clj_lbm.core$eval386.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5424) ... 22 more On Mon, Apr 25, 2011 at 8:05 PM, Phil Hagelberg wrote: > So I just threw together a little tool to help with ns forms. I find > often they accumulate a bunch of cruft over time where you no longer > need a given :use or :require form. And sometimes you don't feel like > finding exactly where on the classpath a given class is. Or maybe > you're too lazy to type it; whatever. Slamhound helps with that. > > (ns my.namespace > "some doc string") > > (defn -main [& args] > (pprint args) > (io/copy (ByteArrayInputStream. (.getBytes "hello")) > (first args))) > > Look at that; all bare, missing all kinds of necessary stuff. > Disgraceful. Release the hound! > > $ lein slamhound src/my/namespace.clj > > (ns my.namespace > "I have a doc string." > (:use [clojure.pprint :only [pprint]]) > (:require [clojure.java.io :as io]) > (:import (java.io ByteArrayInputStream))) > > Tada! (also featuring Emacs integration: M-x slamhound) > > Enjoy: https://github.com/technomancy/slamhound > > -Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Error with eval syntax-quote & PersistentArrayMap
Ah, I see I see. Well it's all starting to click. I didn't realise eval
tries to execute all the nested forms inside that map. I just turned those
into vectors and I'm back on my way :)
Thanks guys
Tim
On Tue, Apr 26, 2011 at 3:32 AM, Alan wrote:
> You are using macroexpand wrong. Don't eval anything when you are
> macroexpanding - the point is to see what code will be executed.
>
> The issue Kevin is bringing to your attention is evident in the first
> code snippet you gave:
>
> ... :content ({:tag :profileDetail, :name
> "first.name", :value "stub", :content nil}
> {:tag :profileDetail, :name "
> last.name", :value "stub", :content nil} ...)
>
> You intend :content to be a key whose value is a list of maps; but the
> reader evals the forms it sees, and lists are function calls. So, it
> calls the first map as a function, with the next three as arguments.
> Maps don't like that many arguments, and you get the error you saw.
>
> On Apr 25, 9:46 pm, Timothy Washington wrote:
> > Oh sorry, were the colors off? Let's try this.
> >
> > The map was actually unquoted. 'etal' (which was null) was
> unquote-spliced.
> > I excluded it for clarity:
> > * user=> `(commands/add ~processed) *
> > * result=> ( ) ;; ** first in this list is a
> function
> > *
> >
> > Now, if I try to eval that, I get the said error.
> > * user=> (eval `(commands/add ~processed))*
> > * result=> java.lang.IllegalArgumentException: ...*
> >
> > And I had tried macroexpand (here and in the containing function), and
> got
> > the same error:
> > * user=> (macroexpand (eval `(commands/add ~processed)))*
> > * result=> java.lang.IllegalArgumentException: ...*
> >
> > You're right that the repl is using the map as a function. But I don't
> > understand why when 'commands/add' function was the first thing in the
> > return list. And macroexpand is yielding the same error . This is what
> had
> > me so perplexed. Hopefully this reads a bit better.
> >
> > Thanks
> > Tim
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 26, 2011 at 12:00 AM, Kevin Downey
> wrote:
> > > sorry I cannot read your email
> >
> > > On Mon, Apr 25, 2011 at 8:24 PM, Timothy Washington <
> twash...@gmail.com>
> > > wrote:
> > > > Hey Kevin, thanks for getting back to me.
> >
> > > > The splice is 'etal' (which is null). I should have excluded it for
> > > > clarity. What you're actually seeing is the map being unquoted:
> > > > user=> `(commands/add ~processed ~@etal)
> > > > (commands/add {:tag :user, :username "stub" ... }) ;; 'etal' does not
> > > show
> > > > up in what gets evaluated - ** first in this list is a function
> >
> > > > Now, if I try to eval that, I get the said error.
> > > > user=> (eval `(commands/add ~processed))
> > > > java.lang.IllegalArgumentException: Wrong number of args (3) passed
> to:
> > > > PersistentArrayMap (NO_SOURCE_FILE:324)
> >
> > > > And I had tried macroexpand (here and in the containing function),
> and
> > > got
> > > > the same error:
> > > > user=> (macroexpand (eval `(commands/add ~processed)))
> > > > java.lang.IllegalArgumentException: Wrong number of args (3) passed
> to:
> > > > PersistentArrayMap (NO_SOURCE_FILE:324)
> >
> > > > You're right that the repl is using the map as a function. But I
> don't
> > > > understand why when 'commands/add' function was the first thing in
> the
> > > > return list. And macroexpand is yielding the same error . This is
> what
> > > had
> > > > me so perplexed. Thanks again for the feedback. It's something small
> that
> > > > I'm missing.
> > > > Tim
> >
> > > > On Mon, Apr 25, 2011 at 10:40 PM, Kevin Downey
> > > wrote:
> >
> > > >> your map is being spliced in to the output, but your output contains
> > > >> lists (...) which are interpreted as functions, and the first thing
> in
> > > >> the list is a map, makes take 1-2 args, your list forms with maps as
> > > >> the operator have more that 2 args. please use macroexpand.
> >
> > > >> On Mon, Apr 25, 2011 at 7:29 PM, Timothy Washington <
> twash...@gmail.com
> >
> > > >> wrote:
> > > >> > Hey all,
> >
> > > > --
> > > > 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
> >
> > > --
> > > And what is good, Phaedrus,
> > > And what is not good—
> > > Need we ask anyone to tell us these things?
> >
> > > --
> > > 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 th
Re: clojure.contrib.sql => clojure.java.jdbc - looking for feedback!
> I don't want to make a breaking change to the existing API, but in a world > there there is an actively-maintained clojure.java.jdbc I don't think a > resultset function in core makes a lot of sense anyway. > > How about we mark core's resultset-seq as deprecated, with a link to the new > project? Then c.j.j. can do a better resultset-seq, and we will leave the old > fn in core for at least on major release cycle. > > I use resultset-seq everywhere. I don't mind us deprecating it, if a better > version is available elsewhere (but please allow the option of down-casing); > but is there really any need to remove a working function from core? I'm not > keen on introducing gratuitous back-compat issues. That's why we ask before doing it. :-) The counter-pressures are overall footprint of core, and the potential for library compatibility issues on semi-Java platforms such as android. That said, these issues are hypothetical at this point. > Can we arrange for the deprecated core version to call the c.j.j version, > passing any options to preserve current behaviour as much as possible, and to > fail at runtime if that library is not present? That seems complicated. If removal is going to cause heartburn, we could deprecate without ever removing. Stu Stuart Halloway Clojure/core http://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: defnk pre- and post-conditions
On 26 April 2011 13:27, Meikel Brandmeyer wrote:
> Hi,
>
> clojure supports keyword arguments for a quote some time now.
>
> (defn foo
> [positional1 ... positionalN & {:keys [kw1 ... kwn]}]
> ...)
>
> The syntax is the usual destructuring syntax for maps. So you can specify
> defaults via :or etc. And even have none keyword keys.
Aha! I didn't know about :or to supply default options. Otherwise the
only drawback I see is as Hugo says: repetition of keys.
Thanks 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: Merging two maps based on ids
Another option is using clojure.set, as is shown here: https://github.com/pepijndevos/Begame/blob/master/src/begame/util.clj#L99 On Apr 26, 10:10 am, Meikel Brandmeyer wrote: > Hi, > > you can construct the output sequence from your input sequences. > > (defn merge-data > [data-orig data-override] > (let [override-ids (set (map :id data-override))] > (concat data-override (remove (comp override-ids :id) data-orig > > If you need your output sorted you can also add a "(sord-by :id ...)" around > the concat. > > 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: rewriting seque
Hah! Can anyone confirm I'm not daydreaming, and that this actually works? https://gist.github.com/934781 I ended up using an ad hoc, informally-specified, bug-ridden, slow implementation of half of BlockingQueue, but it seems to work /all the time!/ On Apr 22, 9:08 pm, Pepijn de Vos wrote: > Hey, > > I was using seque with a BlockingQueue instead of an integer, when I noticed > it does not work for PriorityBlockingQueue and SynchronousQueue. > > I submitted a bug[1] and started a new implementation[2] to work around the > problems, but there is a whole concurrency jungle out there as soon as you > leave persistent data structures behind. > > So the thing is, poll, peek and locking do not work for SynchronousQueue and > poisoning the queue does not work for PriorityBlockingQueue because the > sorting going on. > > I'm currently interrupting the consumer when we're done, like here[3]. It > works most of the time, but sometimes it still hangs. I checked that > interrupting works when it happens before as well as during the .take, so I > can't see how it would hang. > > I could really use some help making this work, because I'm stuck and out of > ideas. > > I devised this form to test it repeatedly and manually (.interrupt cur) later. > > (future (def cur (Thread/currentThread)) (reduce (partial merge-with +) (map > #(dissoc % :type) (repeatedly 100 #(run-tests 'test) > > [1]http://dev.clojure.org/jira/browse/CLJ-776 > [2]https://gist.github.com/934781 > [3]http://stackoverflow.com/questions/5378391/closing-a-blocking-queue > > Groeten, > Pepijn de Vos > -- > Sent from my iPod Shufflehttp://pepijndevos.nl -- 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: swank-cdt: Using Slime with the Clojure Debugging Toolkit
integration of cdt with swank is really nice. Thanks for the great work. I tried to set break points at multimethods. but I am unable to do so. Can some body help ? Thanks, Sunil. On Tue, Apr 26, 2011 at 12:21 PM, Sam Aaron wrote: > Hi Phil, > > On 26 Apr 2011, at 06:22, Phil Hagelberg wrote: > > > On Apr 25, 12:12 pm, Sam Aaron wrote: > > > > I'm curious, what are your requirements for native dependencies? > > > > I have never needed them, so I've relied on contributors and external > > plugins because I don't know what's needed. But if it's a blocker for > > some it could get merged into Leiningen itself. I've looked at the > > plugin and it seems pretty simple. What's missing? > > I was originally using lein and the native-deps plugin for my projects, but > it's much more cumbersome than cake's approach. > > On the periphery it doesn't seem too bad, in your project.clj you need to > include native-deps in your :dev-dependencies, and then specify the actual > native deps in :native-dependencies as follows: > > (defproject org.clojars.samaaron/monome-serial "0.1.3" > :description "An interface to the monome (http://monome.org)" > :dependencies [[org.clojure/clojure "1.2.0"] > [org.clojure/clojure-contrib "1.2.0"]] > :dev-dependencies [[native-deps "1.0.5"]] > :native-dependencies [[org.clojars.samaaron/rxtx "2.2.0"]]) > > Pulling all the deps is a two step process: > > * lein deps > * lein native-deps > > However, things get more tricky when some of your standard deps have native > deps themselves. I had to resort to some hackery to get round this issue: > https://github.com/improcess/beatbox/blob/c6e082019e5dad8c7cf37917461339670a38d65f/merge-checkout-deps.rb > > With cake things are far, far simpler. There's no need for an extra plugin > step, or for you to manually download the native deps of other deps. It is > able to determine if a dep contains native deps and does the right thing. So > now, the same project's project.clj looks as follows: > > (defproject monome-serial "0.2.0" > :description "An interface to the monome (http://monome.org)" > :dependencies [[org.clojure/clojure "1.2.0"] > [org.clojure/clojure-contrib "1.2.0"] > [serial-port "1.0.7"]]) > > > serial-port depends on the rxtx native libs: > > (defproject serial-port "1.0.7" > :description "Simple serial port comms library. Wraps RxTx." > :dependencies [[org.clojure/clojure "1.2.0"] > [rxtx22 "1.0.5"]]) > > and cake deals with it all gracefully. All I need to do is: > > cake deps > > And cake pulls the correct native libs from all the dependencies and places > them in lib/native. It's also smart and only pulls out the correct libs for > my architecture. > > I hope that this makes sense. It would be awesome if lein followed cake's > lead here and did the same thing. > > Sam > > --- > http://sam.aaron.name > > -- > 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
setting break points at multimethods in cdt
Hello everybody, I am unable to set break points at multimethods using set-bp ..( I am able to set break points for other functions.. though) .. can somebody tell me how to do this? I am using swank-cdt integration. It works very nicely otherwise. Thanks, Sunil. -- 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: Slamhound (for reconstructing ns forms)
On Apr 26, 6:25 am, gaz jones wrote: > this looks awesome, tried it out on a project i have but sadly got the > exception below. i'll try and figure it out later when i have more > time to see if its something specific to my project, but thought i > would let you know in case it is something obvious (it failed from > both slime and lein) It hasn't seen a lot of use yet, so there are going to be things it doesn't handle. There are a some cases it doesn't work with by design, and I've clarified that in the readme: https://github.com/technomancy/slamhound/commit/c9dd2403393c086175be58c0bafc459eeff3e20b If you run into other issues, please open a Github issue with a repro case. thanks, Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: swank-cdt: Using Slime with the Clojure Debugging Toolkit
On Apr 25, 11:51 pm, Sam Aaron wrote: > I was originally using lein and the native-deps plugin for my projects, but > it's much more cumbersome than cake's approach. > > On the periphery it doesn't seem too bad, in your project.clj you need to > include native-deps in your :dev-dependencies, and then specify the actual > native deps in :native-dependencies as follows: > > (defproject org.clojars.samaaron/monome-serial "0.1.3" > :description "An interface to the monome (http://monome.org)" > :dependencies [[org.clojure/clojure "1.2.0"] > [org.clojure/clojure-contrib "1.2.0"]] > :dev-dependencies [[native-deps "1.0.5"]] > :native-dependencies [[org.clojars.samaaron/rxtx "2.2.0"]]) > > Pulling all the deps is a two step process: > > * lein deps > * lein native-deps Hmm; that's silly. I wonder why the plugin works that way. Maybe it was developed before hooks were added to Leiningen. I think I'll try to make Leiningen 1.6 work with this stuff built-in. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Merging two maps based on ids
(defn merge-data [data1 data2] (map first (partition-by :id (sort-by :id (concat data1 data2) Since the sorting is stable (relative order is kept), we know that the first occurrence of each id is either the existing map from data1, or the new map from data2. On Tue, Apr 26, 2011 at 5:34 PM, pepijn (aka fliebel) wrote: > Another option is using clojure.set, as is shown here: > https://github.com/pepijndevos/Begame/blob/master/src/begame/util.clj#L99 > > On Apr 26, 10:10 am, Meikel Brandmeyer wrote: > > Hi, > > > > you can construct the output sequence from your input sequences. > > > > (defn merge-data > > [data-orig data-override] > > (let [override-ids (set (map :id data-override))] > > (concat data-override (remove (comp override-ids :id) data-orig > > > > If you need your output sorted you can also add a "(sord-by :id ...)" > around > > the concat. > > > > 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 > -- 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: Merging two maps based on ids
Correction: (concat data1 data2) should be (concat data2 data1) On Tue, Apr 26, 2011 at 6:37 PM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote: > (defn merge-data [data1 data2] > (map first (partition-by :id (sort-by :id (concat data1 data2) > > Since the sorting is stable (relative order is kept), we know that the > first occurrence of each id is either the existing map from data1, or the > new map from data2. > > > On Tue, Apr 26, 2011 at 5:34 PM, pepijn (aka fliebel) < > pepijnde...@gmail.com> wrote: > >> Another option is using clojure.set, as is shown here: >> https://github.com/pepijndevos/Begame/blob/master/src/begame/util.clj#L99 >> >> On Apr 26, 10:10 am, Meikel Brandmeyer wrote: >> > Hi, >> > >> > you can construct the output sequence from your input sequences. >> > >> > (defn merge-data >> > [data-orig data-override] >> > (let [override-ids (set (map :id data-override))] >> > (concat data-override (remove (comp override-ids :id) data-orig >> > >> > If you need your output sorted you can also add a "(sord-by :id ...)" >> around >> > the concat. >> > >> > 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 >> > > -- 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: Slamhound (for reconstructing ns forms)
I love you Phil. On 04/25/2011 09:05 PM, Phil Hagelberg wrote: So I just threw together a little tool to help with ns forms. I find often they accumulate a bunch of cruft over time where you no longer need a given :use or :require form. And sometimes you don't feel like finding exactly where on the classpath a given class is. Or maybe you're too lazy to type it; whatever. Slamhound helps with that. (ns my.namespace "some doc string") (defn -main [& args] (pprint args) (io/copy (ByteArrayInputStream. (.getBytes "hello")) (first args))) Look at that; all bare, missing all kinds of necessary stuff. Disgraceful. Release the hound! $ lein slamhound src/my/namespace.clj (ns my.namespace "I have a doc string." (:use [clojure.pprint :only [pprint]]) (:require [clojure.java.io :as io]) (:import (java.io ByteArrayInputStream))) Tada! (also featuring Emacs integration: M-x slamhound) Enjoy: https://github.com/technomancy/slamhound -Phil -- Cheers, Aaron Bedra -- Clojure/core http://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: "closed" maps / reducing runtime errors due to mistyped keywords
Creating your own "Closed Map" type would be the object-oriented approach. One
downside is that a closed-map feels like a normal map, but can't be safely
substituted for most maps because of the booby-trap when using assoc (etc.)
with a new key. It doesn't really fulfill the map contract anymore. You'll
have to do some defensive copying if you need a normal map.
I would like to suggest a functional approach as an alternative. It seems to
me that the concept of "closedness" is a matter of interpretation. It could be
determined by the functions manipulating the data. Sometimes you might want to
treat the data (map) as closed and other times you might not care, so you just
need to use the appropriate functions.
If you create your closed maps with all the allowed keys (nil values as
appropriate), you just need to call contains? on any new key to make sure it's
allowed. You could do that in a pre-condition. For example:
(defn assert-key [m k] {:pre [(contains? m k)]} k)
(defn assoc-closed [m k v]
(assoc m (assert-key m k) v))
(defn get-closed [m k]
(get m (assert-key m k)))
Steve Miner
stevemi...@gmail.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: swank-cdt: Using Slime with the Clojure Debugging Toolkit
On 26 Apr 2011, at 17:15, Phil Hagelberg wrote: > On Apr 25, 11:51 pm, Sam Aaron wrote: >> I was originally using lein and the native-deps plugin for my projects, but >> it's much more cumbersome than cake's approach. >> >> On the periphery it doesn't seem too bad, in your project.clj you need to >> include native-deps in your :dev-dependencies, and then specify the actual >> native deps in :native-dependencies as follows: >> >> (defproject org.clojars.samaaron/monome-serial "0.1.3" >> :description "An interface to the monome (http://monome.org)" >> :dependencies [[org.clojure/clojure "1.2.0"] >> [org.clojure/clojure-contrib "1.2.0"]] >> :dev-dependencies [[native-deps "1.0.5"]] >> :native-dependencies [[org.clojars.samaaron/rxtx "2.2.0"]]) >> >> Pulling all the deps is a two step process: >> >> * lein deps >> * lein native-deps > > Hmm; that's silly. I wonder why the plugin works that way. Maybe it > was developed before hooks were added to Leiningen. I think I'll try > to make Leiningen 1.6 work with this stuff built-in. That would be outstanding :-) Sam --- http://sam.aaron.name -- 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.contrib.sql => clojure.java.jdbc - looking for feedback!
On Tue, Apr 26, 2011 at 6:19 AM, David Powell wrote: > There is justification for resultset-seq's current behaviour, even if it > isn't to everyone's preference. Agreed. And I would actually want the lowercasing behavior to remain the default, for my own use anyway. What irks me more is the lack of translation between foo_bar and :foo-bar or, for folks who camelCase column names, between fooBar and :foo-bar perhaps. This all goes back to the idea of a "naming strategy" for translating between Clojure keywords and SQL entity names. I think at this point it makes sense to add a function to c.j.j that mimics the current resultset-seq functionality but allows for the application of naming strategies - with the default being the current behavior, and some other standard strategies available. The question then is whether the c.j.j function should also be called resultset-seq or whether a new name should be picked? However, c.j.j functions yield the _result_ of resultset-seq so perhaps it doesn't even need to expose the function itself? On the other hand, if c.j.j supports naming strategies to provide different keyword/entity translations, users may want to be able to apply the same translations to any raw resultSet objects they have... Thoughts? > Can we arrange for the deprecated core version to call the c.j.j version, > passing any options to preserve current behaviour as much as possible, and > to fail at runtime if that library is not present? It's a relatively small function so it should stay as-is in core - it should not depend on c.j.j. As Stuart notes, deprecation doesn't necessarily mean it will go away, just that users are discouraged from using it. One of the other languages I work with deprecated some functions about a decade ago but those functions are still present nearly half a dozen releases later :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: setting break points at multimethods in cdt
so cdt supports two kinds of breakpoints, method breakpoints, (with the set-bp function) and line breakpoints, (with the ^c^x^b,) keystroke in emacs. You are corrrect that the set-bp function doesn't work properly with multi-methods, but line breakpoints should be working. Are they? On Apr 26, 8:51 am, Sunil S Nandihalli wrote: > Hello everybody, > I am unable to set break points at multimethods using set-bp ..( I am able > to set break points for other functions.. though) .. can somebody tell me > how to do this? I am using swank-cdt integration. It works very nicely > otherwise. > Thanks, > Sunil. -- 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
Odd Java interop behavior
Anyone know what is going on here? I'm trying to use my Clojure REPL to rename a file that's gotten "stuck" on my Windows box (somehow, both Explorer and the command prompt claim the file isn't found if I try to move, delete, or rename it) but I get this: com.example.isii=> (FileInputStream. (nth (.listFiles (java.io.File. "C:\\Users\\Owner\\Documents\\Downloads")) 44)) # Either Java has the same bug as Windows Explorer and Windows cmd.exe, which seems very unlikely (why would Sun/Oracle and Microsoft make identical mistakes?), the NTFS volume itself is corrupt in some way (practically unheard-of), or something's going wrong with interop. I first tried pasting the file name into (.renameTo (File. "C:\\Users\\blah blah blah")) and it didn't work so I had the idea that maybe the file had a funny character in its name that was causing problems. But the above uses .listFiles on the directory to pull the File object right out of the system (it happens to be the 45th file in the order produced by .listFiles). So it *should* work. But it doesn't! The .listFiles method is listing a file that .renameTo cannot rename and the FileInputStream constructor cannot open; both claim the file doesn't exist. Crazily, .isFile says false for this File object, so does .isDirectory, and so does .exists. I'm pretty sure that File objects returned by .listFiles are supposed to .exists, at the very least. Unless the Java API has a bug here, and this is an old but non-deprecated part of a heavily-used stock JavaSE API so that seems highly unlikely, then I have to suspect some wires are getting crossed during Clojure's Java interop. Clojure is newer and much less well-tested than the JavaSE API in question. Perhaps one object is being replaced with another, or the wrong methods are being called? At this point, the only other alternatives are increasingly outlandish and unlikely: 1. A bug in an old, heavily-used, non-deprecated, standard JavaSE API that's gone undetected for ages. 2. A bug in a low-level kernel file-handling routine that causes a file to exist for listing purposes but not for opening/rename/delete, in an NT kernel operating system on its second service pack rather than a Windows 7 beta or Windows 3.1 or some such crap. (Microsoft is of course notorious for bugs, but generally of the dodgy-C-pointer-arithmetic variety and the security-hole variety; getting basic file handling wrong is not really their style, and besides, something like that would be an utter showstopper in high performance server environments, a market Microsoft has been trying to gain significant share in for eons. Servers needing to be rebooted every few days? Annoying. Servers that get hacked every few months and need to be reloaded from the last backup? Annoying. Servers that can't find, read, or handle files correctly, resulting in spurious 404 errors and the like consistently afflicting particular web pages? Unusable.) 3. Some kind of damage to the underlying NTFS volume. Case 3, if true, would be especially worrying since that's my C drive. If it goes, the computer goes. Oh, most of my data is backed up and recoverable but having to replace the drive, the operating system, and reinstall all applications is likely to be very time consuming and expensive. So I hope you'll pardon me if I hope it's a bug in Clojure instead. :) -- 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: Understanding the Clojure source-code and functionality
FWIW, I'm hoping that Clojure Atlas[1] may be helpful to someone with your objectives. I've often found Chris Houser's class diagram[2] helpful, especially in my "earlier days"; hopefully the Atlas will make it even easier to see the correspondence between key concepts, abstractions, and functions in Clojure and the JVM interfaces and classes that implement them. - Chas [1] http://clojureatlas.com [2] http://github.com/Chouser/clojure-classes/tree/master/graph-w-legend.png On Apr 17, 3:27 pm, Terje Dahl wrote: > I would very much like to study and understand how Clojure works > "under the hood". > > Yes, I have downloaded the source and looked at it. > Yes, I have all the books about programming in Clojure. > > But what I am looking for is learning and understanding how the > Clojure JVM-code actually works. > And how it interacts with with the CLJ-files. > About underlying principals and functionality in general, > considerations in relation to Java and the JVM, and where the > development path goes from here. > > Is anything written on the subject? > Is there a book under way? > > Perhaps this is an interesting project on its own - and important for > developing understanding for Clojure, and helping aspiring developers > (such as myself) to participate in the development of Clojure. -- 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: Odd Java interop behavior
Since you are essentially using java, I think that a clojure bug can be ruled out. Have you checked the drive for errors? On Tue, Apr 26, 2011 at 8:12 PM, Ken Wesson wrote: > Anyone know what is going on here? I'm trying to use my Clojure REPL > to rename a file that's gotten "stuck" on my Windows box (somehow, > both Explorer and the command prompt claim the file isn't found if I > try to move, delete, or rename it) but I get this: > > com.example.isii=> (FileInputStream. (nth (.listFiles (java.io.File. > "C:\\Users\\Owner\\Documents\\Downloads")) 44)) > # C:\Users\Owner\Documents\Downloads\blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah.mpeg (The system cannot > find the file specified) (NO_SOURCE_FILE:97)> > > Either Java has the same bug as Windows Explorer and Windows cmd.exe, > which seems very unlikely (why would Sun/Oracle and Microsoft make > identical mistakes?), the NTFS volume itself is corrupt in some way > (practically unheard-of), or something's going wrong with interop. > > I first tried pasting the file name into (.renameTo (File. > "C:\\Users\\blah blah blah")) and it didn't work so I had the idea > that maybe the file had a funny character in its name that was causing > problems. But the above uses .listFiles on the directory to pull the > File object right out of the system (it happens to be the 45th file in > the order produced by .listFiles). So it *should* work. But it > doesn't! The .listFiles method is listing a file that .renameTo cannot > rename and the FileInputStream constructor cannot open; both claim the > file doesn't exist. > > Crazily, .isFile says false for this File object, so does > .isDirectory, and so does .exists. I'm pretty sure that File objects > returned by .listFiles are supposed to .exists, at the very least. > Unless the Java API has a bug here, and this is an old but > non-deprecated part of a heavily-used stock JavaSE API so that seems > highly unlikely, then I have to suspect some wires are getting crossed > during Clojure's Java interop. Clojure is newer and much less > well-tested than the JavaSE API in question. > > Perhaps one object is being replaced with another, or the wrong > methods are being called? > > At this point, the only other alternatives are increasingly outlandish > and unlikely: > > 1. A bug in an old, heavily-used, non-deprecated, standard JavaSE API > that's gone undetected for ages. > > 2. A bug in a low-level kernel file-handling routine that causes a > file to exist for listing purposes but not for opening/rename/delete, > in an NT kernel operating system on its second service pack rather > than a Windows 7 beta or Windows 3.1 or some such crap. (Microsoft is > of course notorious for bugs, but generally of the > dodgy-C-pointer-arithmetic variety and the security-hole variety; > getting basic file handling wrong is not really their style, and > besides, something like that would be an utter showstopper in high > performance server environments, a market Microsoft has been trying to > gain significant share in for eons. Servers needing to be rebooted > every few days? Annoying. Servers that get hacked every few months and > need to be reloaded from the last backup? Annoying. Servers that can't > find, read, or handle files correctly, resulting in spurious 404 > errors and the like consistently afflicting particular web pages? > Unusable.) > > 3. Some kind of damage to the underlying NTFS volume. > > Case 3, if true, would be especially worrying since that's my C drive. > If it goes, the computer goes. Oh, most of my data is backed up and > recoverable but having to replace the drive, the operating system, and > reinstall all applications is likely to be very time consuming and > expensive. So I hope you'll pardon me if I hope it's a bug in Clojure > instead. :) > > -- > 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: Odd Java interop behavior
If the "blah blah blah..." is meant to represent a very long file name or path, my guess would be that you've bumped up against the Windows path limit (260 chars) which can manifest itself in weird ways. See cause 4 here: http://support.microsoft.com/kb/320081 Since you're also having issues in Windows/DOS it seems unlikely that this is a Java or Clojure bug since they probably use the same underlying file system APIs as Explorer. Good luck, Dave On Tue, Apr 26, 2011 at 2:12 PM, Ken Wesson wrote: > Anyone know what is going on here? I'm trying to use my Clojure REPL > to rename a file that's gotten "stuck" on my Windows box (somehow, > both Explorer and the command prompt claim the file isn't found if I > try to move, delete, or rename it) but I get this: > > com.example.isii=> (FileInputStream. (nth (.listFiles (java.io.File. > "C:\\Users\\Owner\\Documents\\Downloads")) 44)) > # C:\Users\Owner\Documents\Downloads\blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah.mpeg (The system cannot > find the file specified) (NO_SOURCE_FILE:97)> > > Either Java has the same bug as Windows Explorer and Windows cmd.exe, > which seems very unlikely (why would Sun/Oracle and Microsoft make > identical mistakes?), the NTFS volume itself is corrupt in some way > (practically unheard-of), or something's going wrong with interop. > > I first tried pasting the file name into (.renameTo (File. > "C:\\Users\\blah blah blah")) and it didn't work so I had the idea > that maybe the file had a funny character in its name that was causing > problems. But the above uses .listFiles on the directory to pull the > File object right out of the system (it happens to be the 45th file in > the order produced by .listFiles). So it *should* work. But it > doesn't! The .listFiles method is listing a file that .renameTo cannot > rename and the FileInputStream constructor cannot open; both claim the > file doesn't exist. > > Crazily, .isFile says false for this File object, so does > .isDirectory, and so does .exists. I'm pretty sure that File objects > returned by .listFiles are supposed to .exists, at the very least. > Unless the Java API has a bug here, and this is an old but > non-deprecated part of a heavily-used stock JavaSE API so that seems > highly unlikely, then I have to suspect some wires are getting crossed > during Clojure's Java interop. Clojure is newer and much less > well-tested than the JavaSE API in question. > > Perhaps one object is being replaced with another, or the wrong > methods are being called? > > At this point, the only other alternatives are increasingly outlandish > and unlikely: > > 1. A bug in an old, heavily-used, non-deprecated, standard JavaSE API > that's gone undetected for ages. > > 2. A bug in a low-level kernel file-handling routine that causes a > file to exist for listing purposes but not for opening/rename/delete, > in an NT kernel operating system on its second service pack rather > than a Windows 7 beta or Windows 3.1 or some such crap. (Microsoft is > of course notorious for bugs, but generally of the > dodgy-C-pointer-arithmetic variety and the security-hole variety; > getting basic file handling wrong is not really their style, and > besides, something like that would be an utter showstopper in high > performance server environments, a market Microsoft has been trying to > gain significant share in for eons. Servers needing to be rebooted > every few days? Annoying. Servers that get hacked every few months and > need to be reloaded from the last backup? Annoying. Servers that can't > find, read, or handle files correctly, resulting in spurious 404 > errors and the like consistently afflicting particular web pages? > Unusable.) > > 3. Some kind of damage to the underlying NTFS volume. > > Case 3, if true, would be especially worrying since that's my C drive. > If it goes, the computer goes. Oh, most of my data is backed up and > recoverable but having to replace the drive, the operating system, and > reinstall all applications is likely to be very time consuming and > expensive. So I hope you'll pardon me if I hope it's a bug in Clojure > instead. :) > > -- > 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...@g
Re: "closed" maps / reducing runtime errors due to mistyped keywords
On Tue, Apr 26, 2011 at 1:06 PM, Steve Miner wrote:
> Creating your own "Closed Map" type would be the object-oriented approach.
> One downside is that a closed-map feels like a normal map, but can't be
> safely substituted for most maps because of the booby-trap when using assoc
> (etc.) with a new key. It doesn't really fulfill the map contract anymore.
> You'll have to do some defensive copying if you need a normal map.
>
> I would like to suggest a functional approach as an alternative. It seems to
> me that the concept of "closedness" is a matter of interpretation. It could
> be determined by the functions manipulating the data. Sometimes you might
> want to treat the data (map) as closed and other times you might not care, so
> you just need to use the appropriate functions.
>
> If you create your closed maps with all the allowed keys (nil values as
> appropriate), you just need to call contains? on any new key to make sure
> it's allowed. You could do that in a pre-condition. For example:
>
> (defn assert-key [m k] {:pre [(contains? m k)]} k)
>
> (defn assoc-closed [m k v]
> (assoc m (assert-key m k) v))
>
> (defn get-closed [m k]
> (get m (assert-key m k)))
+1
--
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: Slamhound (for reconstructing ns forms)
On Apr 26, 6:25 am, gaz jones wrote: > this looks awesome, tried it out on a project i have but sadly got the > exception below. i'll try and figure it out later when i have more > time to see if its something specific to my project, but thought i > would let you know in case it is something obvious (it failed from > both slime and lein) I just pushed 1.1.0 which should solve most issues causing this; if not please let me know. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Odd Java interop behavior
On Tue, Apr 26, 2011 at 2:26 PM, Dave Ray wrote: > If the "blah blah blah..." is meant to represent a very long file name > or path, my guess would be that you've bumped up against the Windows > path limit (260 chars) which can manifest itself in weird ways. I assume that the file name cannot exceed any system limit, or else it could not exist as such in the first place. Obviously the browser was able to write the file to that directory with that name, after all; the current state of the filesystem resulted from the same operating system low level APIs rather than springing fully-formed from the brow of Zeus. It would not make sense for those APIs to have one limit for writing files and another, lower limit for reading them. Not even by the sometimes-peculiar notion of what "makes sense" that they use in Redmond. No, the problem is surely either at a lower level (drive damage?) or a higher one (issues in Explorer, cmd.exe, and either java.io or Clojure), or else it's an outright bug and not just an intentional "limit". -- 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: Odd Java interop behavior
On Tue, Apr 26, 2011 at 2:36 PM, Ken Wesson wrote: > On Tue, Apr 26, 2011 at 2:26 PM, Dave Ray wrote: >> If the "blah blah blah..." is meant to represent a very long file name >> or path, my guess would be that you've bumped up against the Windows >> path limit (260 chars) which can manifest itself in weird ways. > > I assume that the file name cannot exceed any system limit, or else it > could not exist as such in the first place. Obviously the browser was > able to write the file to that directory with that name, after all; > the current state of the filesystem resulted from the same operating > system low level APIs rather than springing fully-formed from the brow > of Zeus. It would not make sense for those APIs to have one limit for > writing files and another, lower limit for reading them. Not even by > the sometimes-peculiar notion of what "makes sense" that they use in > Redmond. It's possible to build files a piece at a time using relative paths that are un-manipulable using standard APIs on Windows, and the key really is that 260 character limit. For instance, create a directory with 248 characters at the root of a drive, and then move that directory to a subdirectory, Windows won't be able to deal with it anymore. There is a horribly ugly alternate API to access those files, but not many applications use it to my knowledge. Try doing: (.renameTo (File. "?\\C:\\Users\\blah blah blah") "shorterName") The magical "\\?\" prefix allows Windows to use files longer than 260 characters. -- 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: Odd Java interop behavior
Ok. But whether it's reasonable or not, it can happen. For example, the project I work on can't be located in a Windows folder deeper than 37 chars long because Swig generates a particularly long Java file. It has no problems writing it, but further down the the build pipeline, javac dies when it tries to read it. 37 is the point at which the path length spills over from 260 to 261 which is the documented limit for *some* Windows file system APIs. Dave On Tue, Apr 26, 2011 at 2:36 PM, Ken Wesson wrote: > On Tue, Apr 26, 2011 at 2:26 PM, Dave Ray wrote: >> If the "blah blah blah..." is meant to represent a very long file name >> or path, my guess would be that you've bumped up against the Windows >> path limit (260 chars) which can manifest itself in weird ways. > > I assume that the file name cannot exceed any system limit, or else it > could not exist as such in the first place. Obviously the browser was > able to write the file to that directory with that name, after all; > the current state of the filesystem resulted from the same operating > system low level APIs rather than springing fully-formed from the brow > of Zeus. It would not make sense for those APIs to have one limit for > writing files and another, lower limit for reading them. Not even by > the sometimes-peculiar notion of what "makes sense" that they use in > Redmond. > > No, the problem is surely either at a lower level (drive damage?) or a > higher one (issues in Explorer, cmd.exe, and either java.io or > Clojure), or else it's an outright bug and not just an intentional > "limit". > > -- > 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: Odd Java interop behavior
On Tue, Apr 26, 2011 at 2:36 PM, Ken Wesson wrote: > On Tue, Apr 26, 2011 at 2:26 PM, Dave Ray wrote: >> If the "blah blah blah..." is meant to represent a very long file name >> or path, my guess would be that you've bumped up against the Windows >> path limit (260 chars) which can manifest itself in weird ways. > > I assume that the file name cannot exceed any system limit, or else it > could not exist as such in the first place. Obviously the browser was > able to write the file to that directory with that name, after all; > the current state of the filesystem resulted from the same operating > system low level APIs rather than springing fully-formed from the brow > of Zeus. It would not make sense for those APIs to have one limit for > writing files and another, lower limit for reading them. Not even by > the sometimes-peculiar notion of what "makes sense" that they use in > Redmond. > > No, the problem is surely either at a lower level (drive damage?) or a > higher one (issues in Explorer, cmd.exe, and either java.io or > Clojure), or else it's an outright bug and not just an intentional > "limit". However, one of the suggestions at that Microsoft page *kinda* worked. Specifically: "To resolve this issue, you may want to use the auto-generated 8.3 name to access the file." Doing that at cmd.exe produced the same nonsensical "File not found" error messages. On the other hand, user=> (.renameTo (java.io.File. "C:\\Users\\Owner\\Documents\\Downloads\\BLAHBL~1") (java.io.File. "C:\\Users\\Owner\\Documents\\Downloads\\blah blah.jpg")) true Since Microsoft's proposed fix didn't work using Microsoft's own tools, presumably the actual cause of the problem wasn't the limit in question (which presumably only gets exceeded when other operating systems than Windows have written to the NTFS volume anyway). On the other hand, it did suggest another way of getting a handle on the file, and that way apparently bypasses the Java IO/interop problem. And the file once renamed is usable and even what it should be, which appears to rule out disk drive failure or FS corruption as the cause (sigh of relief). Surprisingly, it looks like we are indeed dealing with either two bugs or three. The three case: 1. Explorer fails to access the file, though it should work. 2. cmd.exe fails to access the file, though it should work. 3. Either java.io ditto, or something wrong with interop. The two case: 1. Some bug allows the OS APIs to write a file that exceeds the limit you discussed. 2. Some other bug prevents Microsoft's remedy for that limit being exceeded from working in cmd.exe, without preventing it from working when implemented via java.io. Of course, the second case seems less likely despite having fewer apparent separate failures, because bug 1 in particular seems less likely, and because in the first case bugs 1 and 2 might not really be separate, if Explorer and cmd.exe share code. -- 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: Grabbing Rotten Tomatoes movie ratings in clojure
An update on this little side project to grab movie ratings from popular a movie website: I've add it to github and included the project file and updated the README https://github.com/justinhj/movieratings Also fixed it so it works with a recent change their page format. Justin -- 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: Grabbing Rotten Tomatoes movie ratings in clojure
On Tue, Apr 26, 2011 at 3:19 PM, justinhj wrote: > An update on this little side project to grab movie ratings from popular a > movie website: > I've add it to github and included the project file and updated the README > https://github.com/justinhj/movieratings > > Also fixed it so it works with a recent change their page format. > Justin > Neat project, have you looked into using their web service API (http://developer.rottentomatoes.com/) rather than scraping? -- 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
cond in dosync problem
Hi, I use cond in dosync but it doesn't work. Here is a function code: (defn process-request [offer args] (logger/log "process called") (let [offer-value (Double/parseDouble (:offer offer)) out-queue (:out-queue args) unique-offers (:unique-offers args) all-offers (:all-offers args) streams (:streams offer)] (dosync (cond (empty? @unique-offers) ((logger/log "map" @unique-offers) (alter unique-offers assoc offer-value streams)) :else (logger/log "error") unique-offer is ref for map which is empty so condition (empty? @unique-offers) is true. Statement (alter unique-offers assoc offer-value streams) never changes unique-offers map. If I remove cond from function it works fine (The function has only dosyn and alter). What am I doing wrong? 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: cond in dosync problem
I don't know. However, given the situation I think (cond (empty? @unique-offers) (dosync ... alter ...) :else (logger/log "error")) is better, since the change is more isolated. On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic wrote: > Hi, > > I use cond in dosync but it doesn't work. Here is a function code: > > > (defn process-request > [offer args] > (logger/log "process called") > (let [offer-value (Double/parseDouble (:offer offer)) > out-queue (:out-queue args) > unique-offers (:unique-offers args) > all-offers (:all-offers args) > streams (:streams offer)] > (dosync > (cond > (empty? @unique-offers) > ((logger/log "map" @unique-offers) > (alter unique-offers assoc offer-value streams)) > :else (logger/log "error") > > unique-offer is ref for map which is empty so condition (empty? > @unique-offers) is true. > Statement (alter unique-offers assoc offer-value streams) never changes > unique-offers map. > If I remove cond from function it works fine (The function has only dosyn > and alter). > > What am I doing wrong? > > 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 -- 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: Slamhound (for reconstructing ns forms)
1.1.0 seems to have regressed. I've added slamhound as a dependency: (defproject foobar "1.0.0-SNAPSHOT" :description "FIXME: write description" :dependencies [[org.clojure/clojure "1.2.1"]] :dev-dependencies [[slamhound "1.1.0"]]) Then added a function to "src/foobar/core.clj": (ns foobar.core) (str/trim " hello ") When I start a REPL and try to slamhound it, it instead throws an exception: user=> (require 'slam.hound) nil user=> (slam.hound/reconstruct "src/foobar/core.clj") java.lang.Exception: No such namespace: str (core.clj:2) And the same occurs with the Leiningen plugin: $ lein slamhound src/foobar/core.clj Exception in thread "main" java.lang.Exception: No such namespace: str (core.clj:2) ... - James On 26 April 2011 19:32, Phil Hagelberg wrote: > On Apr 26, 6:25 am, gaz jones wrote: > > this looks awesome, tried it out on a project i have but sadly got the > > exception below. i'll try and figure it out later when i have more > > time to see if its something specific to my project, but thought i > > would let you know in case it is something obvious (it failed from > > both slime and lein) > > I just pushed 1.1.0 which should solve most issues causing this; if > not please let me know. > > -Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: cond in dosync problem
On a closer look: ((logger/log "map" @unique-offers) (alter unique-offers assoc offer-value streams)) should probably be (do (logger/log "map" @unique-offers) (alter unique-offers assoc offer-value streams)) On Tue, Apr 26, 2011 at 9:55 PM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote: > I don't know. > However, given the situation I think > > (cond > (empty? @unique-offers) (dosync ... alter ...) > :else (logger/log "error")) > > is better, since the change is more isolated. > > > On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic wrote: > >> Hi, >> >> I use cond in dosync but it doesn't work. Here is a function code: >> >> >> (defn process-request >> [offer args] >> (logger/log "process called") >> (let [offer-value (Double/parseDouble (:offer offer)) >> out-queue (:out-queue args) >> unique-offers (:unique-offers args) >> all-offers (:all-offers args) >>streams (:streams offer)] >> (dosync >> (cond >> (empty? @unique-offers) >> ((logger/log "map" @unique-offers) >> (alter unique-offers assoc offer-value streams)) >> :else (logger/log "error") >> >> unique-offer is ref for map which is empty so condition (empty? >> @unique-offers) is true. >> Statement (alter unique-offers assoc offer-value streams) never changes >> unique-offers map. >> If I remove cond from function it works fine (The function has only dosyn >> and alter). >> >> What am I doing wrong? >> >> 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 > > > -- 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: cond in dosync problem
I have given only part of function. I have condition like this : (cond (and (empty? @unique-offers) (empty? @all-offers)) I change in dosync both unique-offers and all-offers. If I use your suggestion (empty? @unique-offers) (dosync ... alter ...) Can I get in situation where unique-offers is old value but all-offers is new value? Thanks On Tue, Apr 26, 2011 at 9:55 PM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote: > I don't know. > However, given the situation I think > > (cond > (empty? @unique-offers) (dosync ... alter ...) > :else (logger/log "error")) > > is better, since the change is more isolated. > > On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic wrote: > >> Hi, >> >> I use cond in dosync but it doesn't work. Here is a function code: >> >> >> (defn process-request >> [offer args] >> (logger/log "process called") >> (let [offer-value (Double/parseDouble (:offer offer)) >> out-queue (:out-queue args) >> unique-offers (:unique-offers args) >> all-offers (:all-offers args) >>streams (:streams offer)] >> (dosync >> (cond >> (empty? @unique-offers) >> ((logger/log "map" @unique-offers) >> (alter unique-offers assoc offer-value streams)) >> :else (logger/log "error") >> >> unique-offer is ref for map which is empty so condition (empty? >> @unique-offers) is true. >> Statement (alter unique-offers assoc offer-value streams) never changes >> unique-offers map. >> If I remove cond from function it works fine (The function has only dosyn >> and alter). >> >> What am I doing wrong? >> >> 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 > > > -- > 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: ANN: Slamhound (for reconstructing ns forms)
That's a great idea, Phil. Thanks for contributing! -- 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: cond in dosync problem
The important part were that the "dosync" call is isolated. The condition doesn't really matter. By the way: wouldn't it be simpler to create a new map instead of altering unique-offers/all-offers? (this is also more idiomatic) On Tue, Apr 26, 2011 at 10:02 PM, Zlatko Josic wrote: > I have given only part of function. I have condition like this : > > (cond > (and (empty? @unique-offers) (empty? @all-offers)) > > I change in dosync both unique-offers and all-offers. If I use your > suggestion > (empty? @unique-offers) (dosync ... alter ...) > > Can I get in situation where unique-offers is old value but all-offers is > new value? > > Thanks > > > > On Tue, Apr 26, 2011 at 9:55 PM, Jonathan Fischer Friberg < > odysso...@gmail.com> wrote: > >> I don't know. >> However, given the situation I think >> >> (cond >> (empty? @unique-offers) (dosync ... alter ...) >> :else (logger/log "error")) >> >> is better, since the change is more isolated. >> >> On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic wrote: >> >>> Hi, >>> >>> I use cond in dosync but it doesn't work. Here is a function code: >>> >>> >>> (defn process-request >>> [offer args] >>> (logger/log "process called") >>> (let [offer-value (Double/parseDouble (:offer offer)) >>> out-queue (:out-queue args) >>> unique-offers (:unique-offers args) >>> all-offers (:all-offers args) >>>streams (:streams offer)] >>> (dosync >>> (cond >>> (empty? @unique-offers) >>> ((logger/log "map" @unique-offers) >>> (alter unique-offers assoc offer-value streams)) >>> :else (logger/log "error") >>> >>> unique-offer is ref for map which is empty so condition (empty? >>> @unique-offers) is true. >>> Statement (alter unique-offers assoc offer-value streams) never changes >>> unique-offers map. >>> If I remove cond from function it works fine (The function has only dosyn >>> and alter). >>> >>> What am I doing wrong? >>> >>> 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 >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: cond in dosync problem
Is this scenario posible :
(def test-map (ref {}))
(def test-map2 (ref {}))
(defn process
[map1 map2]
(cond
(and (empty? @map1) (empty? @map2))
(dosync
((alter map1 assoc key1 value1)
(alter map2 assoc key2 value2)
.
Suppose the process method is called from many threads. Is it posible that
one thread tests first condition (empty? @map1) and gets true
than another thread comits its transaction wich puts values in both maps.
Now first thread check second
condition (empty? @map2) which is false.
On Tue, Apr 26, 2011 at 10:17 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:
> The important part were that the "dosync" call is isolated. The condition
> doesn't really matter.
>
> By the way: wouldn't it be simpler to create a new map instead of altering
> unique-offers/all-offers?
> (this is also more idiomatic)
>
>
> On Tue, Apr 26, 2011 at 10:02 PM, Zlatko Josic wrote:
>
>> I have given only part of function. I have condition like this :
>>
>> (cond
>> (and (empty? @unique-offers) (empty? @all-offers))
>>
>> I change in dosync both unique-offers and all-offers. If I use your
>> suggestion
>>(empty? @unique-offers) (dosync ... alter ...)
>>
>> Can I get in situation where unique-offers is old value but all-offers is
>> new value?
>>
>> Thanks
>>
>>
>>
>> On Tue, Apr 26, 2011 at 9:55 PM, Jonathan Fischer Friberg <
>> odysso...@gmail.com> wrote:
>>
>>> I don't know.
>>> However, given the situation I think
>>>
>>> (cond
>>> (empty? @unique-offers) (dosync ... alter ...)
>>> :else (logger/log "error"))
>>>
>>> is better, since the change is more isolated.
>>>
>>> On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic wrote:
>>>
Hi,
I use cond in dosync but it doesn't work. Here is a function code:
(defn process-request
[offer args]
(logger/log "process called")
(let [offer-value (Double/parseDouble (:offer offer))
out-queue (:out-queue args)
unique-offers (:unique-offers args)
all-offers (:all-offers args)
streams (:streams offer)]
(dosync
(cond
(empty? @unique-offers)
((logger/log "map" @unique-offers)
(alter unique-offers assoc offer-value streams))
:else (logger/log "error")
unique-offer is ref for map which is empty so condition (empty?
@unique-offers) is true.
Statement (alter unique-offers assoc offer-value streams) never changes
unique-offers map.
If I remove cond from function it works fine (The function has only
dosyn and alter).
What am I doing wrong?
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
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
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: cond in dosync problem
No, that isn't possible.
http://clojure.org/refs
Inside a transaction (a dosync call), values updated in another transaction
wont be seen. This means that the first transaction wont see the change
until it commits, at that moment it realizes that the ref that were altered
was changed outside of that particular transaction, and retries. All of this
happens automatically, so you wont have to worry.
On Tue, Apr 26, 2011 at 10:33 PM, Zlatko Josic wrote:
> Is this scenario posible :
>
> (def test-map (ref {}))
>
> (def test-map2 (ref {}))
>
> (defn process
> [map1 map2]
> (cond
> (and (empty? @map1) (empty? @map2))
> (dosync
>((alter map1 assoc key1 value1)
> (alter map2 assoc key2 value2)
> .
>
>
> Suppose the process method is called from many threads. Is it posible that
> one thread tests first condition (empty? @map1) and gets true
> than another thread comits its transaction wich puts values in both maps.
> Now first thread check second
> condition (empty? @map2) which is false.
>
>
>
> On Tue, Apr 26, 2011 at 10:17 PM, Jonathan Fischer Friberg <
> odysso...@gmail.com> wrote:
>
>> The important part were that the "dosync" call is isolated. The condition
>> doesn't really matter.
>>
>> By the way: wouldn't it be simpler to create a new map instead of altering
>> unique-offers/all-offers?
>> (this is also more idiomatic)
>>
>>
>> On Tue, Apr 26, 2011 at 10:02 PM, Zlatko Josic wrote:
>>
>>> I have given only part of function. I have condition like this :
>>>
>>> (cond
>>> (and (empty? @unique-offers) (empty? @all-offers))
>>>
>>> I change in dosync both unique-offers and all-offers. If I use your
>>> suggestion
>>>(empty? @unique-offers) (dosync ... alter ...)
>>>
>>> Can I get in situation where unique-offers is old value but all-offers is
>>> new value?
>>>
>>> Thanks
>>>
>>>
>>>
>>> On Tue, Apr 26, 2011 at 9:55 PM, Jonathan Fischer Friberg <
>>> odysso...@gmail.com> wrote:
>>>
I don't know.
However, given the situation I think
(cond
(empty? @unique-offers) (dosync ... alter ...)
:else (logger/log "error"))
is better, since the change is more isolated.
On Tue, Apr 26, 2011 at 9:45 PM, Zlatko Josic
wrote:
> Hi,
>
> I use cond in dosync but it doesn't work. Here is a function code:
>
>
> (defn process-request
> [offer args]
> (logger/log "process called")
> (let [offer-value (Double/parseDouble (:offer offer))
> out-queue (:out-queue args)
> unique-offers (:unique-offers args)
> all-offers (:all-offers args)
>streams (:streams offer)]
> (dosync
> (cond
> (empty? @unique-offers)
> ((logger/log "map" @unique-offers)
> (alter unique-offers assoc offer-value streams))
> :else (logger/log "error")
>
> unique-offer is ref for map which is empty so condition (empty?
> @unique-offers) is true.
> Statement (alter unique-offers assoc offer-value streams) never changes
> unique-offers map.
> If I remove cond from function it works fine (The function has only
> dosyn and alter).
>
> What am I doing wrong?
>
> 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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send e
Re: ANN: Slamhound (for reconstructing ns forms)
On Apr 26, 12:58 pm, James Reeves wrote: > When I start a REPL and try to slamhound it, it instead throws an exception: > > user=> (require 'slam.hound) > nil > user=> (slam.hound/reconstruct "src/foobar/core.clj") > java.lang.Exception: No such namespace: str (core.clj:2) That's by design; it only works when the :as alias is the same as the last segment of the namespace name. However, there was an unrelated bug causing issues when uncompilable namespaces were on the classpath. I'll have a 1.1.1 fix pushed in a few minutes. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Serialising functions...
Hi, This sounds very interesting and useful. Is the source code available somewhere? Or a more detailed description? Thanks On Fri, Mar 4, 2011 at 1:48 AM, Jules wrote: > > So, > > Just a quick update. > > I gave the client-side ClassLoader encapsulation idea some more > thought and rejeted it (sorry) for the reasons that : > > - I've lived through J2EE ClassLoader hell and don't want to repeat > the experience > > - I'm looking towards an architecture where I can define new types on > any node of my Clojure data-grid and have them accessible in any other > node. This might be done by keeping my class-name:bytecode table in a > clustered cache and inserting a single ClusteredClassLoader (NYI) into > the client's ClassLoader hierarchy. Each client would be able to mix > classes from multiple server JVMs without having to be concerned about > keeping them all segregated. > > So, I introduced the concept of a per-jvm id and hacked it into RT, > Compiler and LispReader. There were not too many places that needed to > be changed. > > The result is, I can now create a type in one jvm, create an instance > of the type, serialise it, ship the bytes to another jvm and > deserialise it, at which point the instance's class is pulled from the > original jvm. No more nasty exceptions because of name collisions etc. > > I have plumbed this infrastructure in underneath my app and, with the > exception of some unrelated bugs that I am chasing down, everything > seems to work beautifully :-) > > There are some limitations with this technique that I haven't looked > into too deeply yet - the most obvious one is that whilst remote types > can be made available within a local jvm, this is only at the java > level, so extra things that defrecord might do for you like intern the > classname as a symbol in your current namespace are not being done - > which, I can currently live with, but I can see this being a tripping > point to a completely transparent solution. > > For me, this is a great leap forward as I have found each Clojure JVM > an island until I got this working, but now I should be able to build > a distributed app in Clojure without having to sacrifice Clojure's > dynamicity in the process - I can have my cake and eat it :-) > > I'm going to play with it for a few days, iron out all my other issues > and investigate exactly what I have achieved, then I will post back a > proper description in case anyone else is trying to build distributed > Clojure apps in a similar manner. > > cheers > > > Jules > > On Mar 3, 2:30 pm, Jules wrote: >> On Mar 3, 1:22 pm, Alessio Stalla wrote: >> >> >> >> >> >> > On Thursday, March 3, 2011 11:46:03 AM UTC+1, Jules wrote: >> >> > > Thanks, Alessio, >> >> > > I did know this, but it is a welcome addition to the thread. >> >> > Ok. Classloaders are a tricky matter and many people don't have clear ideas >> > about them - sorry for assuming you were one of those people :) >> >> np :-) >> >> > > I reread my last posting and it was a bit confused - I've done a >> > > little research in the Compiler class and can now clarify what I think >> > > is happening. >> >> > > Clojure 1.3.0-alpha4 >> > > user=> (type (fn [])) >> > > user$eval1$fn__2 >> > > user=> >> >> > > Here I have created a new function and asked it for its class. Clojure >> > > has emitted bytecode on the fly to implement this and packed this into >> > > a Java Class. A Class has a name unique - as you pointed out - within >> > > its ClassLoader, so to avoid name collisions, Clojure attempts to >> > > create a unique name for the class. This is composed, amongst other >> > > things from its namespace and RT.nextID() (I'm assuming RT = RunTime). >> >> > > RT.nextID seems to start at 0 and allocate ids sequentially - lets >> > > create another fn : >> >> > > user=> (type (fn [])) >> > > user$eval5$fn__6 >> > > user=> >> >> > > I suspect that the gap between 2 and 6 is due to other processes going >> > > on behind the scenes which require ids, rather than some intentional >> > > design - but haven't checked. >> >> > > This all works fine in a single JVM - no two functions will end up >> > > creating types with the same name - however if I take the class for a >> > > function from [a ClassLoader in] one clojure runtime and copy it >> > > across to another clojure runtime that has already allocated this >> > > classes id to another [in the receiving ClassLoader] then I would see >> > > a collision. >> >> > > I think that this is what is happening above. I am serialising an >> > > object in one jvm, putting it into a message and sending the message >> > > to another jvm. Upon receipt I attempt to deserialise the object >> > > contained in the message. This involves looking up its class by name >> > > [within the scope of a ClassLoader] - but the name has already been >> > > allocated to a local class [within the same ClassLoader] which is >> > > mistakenly then used to try to deserialise the object. The object's >> > > data is
Re: cond in dosync problem
Hi,
Am 26.04.2011 um 22:33 schrieb Zlatko Josic:
> Is this scenario posible :
>
> (def test-map (ref {}))
>
> (def test-map2 (ref {}))
>
> (defn process
> [map1 map2]
> (cond
> (and (empty? @map1) (empty? @map2))
> (dosync
>((alter map1 assoc key1 value1)
> (alter map2 assoc key2 value2)
> .
>
>
> Suppose the process method is called from many threads. Is it posible that
> one thread tests first condition (empty? @map1) and gets true
> than another thread comits its transaction wich puts values in both maps. Now
> first thread check second
> condition (empty? @map2) which is false.
Yes. This is perfectly possible. You have to wrap the whole cond in a dosync.
Otherwise it is not guaranteed that you see consistent values of map1 and map2.
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: cond in dosync problem
On Apr 26, 10:52 pm, Jonathan Fischer Friberg wrote: > No, that isn't possible.http://clojure.org/refs I disagree: In the example given, dereferencing happens outside the dosync block, thus outside of any transaction, so a race where map1 and map2 change midway through the #'and expression is theoretically possible. For this reason, #'deref/@ and #'alter are best kept in the same transaction in this situation. > Inside a transaction (a dosync call), values updated in another transaction > wont be seen. This means that the first transaction wont see the change > until it commits, at that moment it realizes that the ref that were altered > was changed outside of that particular transaction, and retries. All of this > happens automatically, so you wont have to worry. -- 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: cond in dosync problem
Yes, you're right, I'm wrong. :) The derefs must be in the dosync block. (which I somehow assumed, oh well) On Tue, Apr 26, 2011 at 11:17 PM, Daniel Werner < daniel.d.wer...@googlemail.com> wrote: > On Apr 26, 10:52 pm, Jonathan Fischer Friberg > wrote: > > No, that isn't possible.http://clojure.org/refs > > I disagree: In the example given, dereferencing happens outside the > dosync block, thus outside of any transaction, so a race where map1 > and map2 change midway through the #'and expression is theoretically > possible. For this reason, #'deref/@ and #'alter are best kept in the > same transaction in this situation. > > > Inside a transaction (a dosync call), values updated in another > transaction > > wont be seen. This means that the first transaction wont see the change > > until it commits, at that moment it realizes that the ref that were > altered > > was changed outside of that particular transaction, and retries. All of > this > > happens automatically, so you wont have to worry. > > -- > 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: ANN: Slamhound (for reconstructing ns forms)
On 26 April 2011 22:16, Phil Hagelberg wrote: > > On Apr 26, 12:58 pm, James Reeves wrote: > > When I start a REPL and try to slamhound it, it instead throws an exception: > > > > user=> (require 'slam.hound) > > nil > > user=> (slam.hound/reconstruct "src/foobar/core.clj") > > java.lang.Exception: No such namespace: str (core.clj:2) > > That's by design; it only works when the :as alias is the same as the > last segment of the namespace name. Ah, well even if I use "string/trim" it throws the same error: user=> (require 'slam.hound) nil user=> (slam.hound/reconstruct "src/foobar/core.clj") java.lang.Exception: No such namespace: string (core.clj:2) > However, there was an unrelated bug causing issues when uncompilable > namespaces were on the classpath. I'll have a 1.1.1 fix pushed in a > few minutes. Is clojure.string an uncompilable namespace, then? - 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: cond in dosync problem
Any idea why changes in the function below does'nt work (see first post on this topic)? (defn process-request [offer args] (logger/log "process called") (let [offer-value (Double/parseDouble (:offer offer)) out-queue (:out-queue args) unique-offers (:unique-offers args) all-offers (:all-offers args) streams (:streams offer)] (dosync (cond (empty? @unique-offers) ((logger/log "map" @unique-offers) (alter unique-offers assoc offer-value streams)) :else (logger/log "error") On Tue, Apr 26, 2011 at 11:38 PM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote: > Yes, you're right, I'm wrong. :) > The derefs must be in the dosync block. (which I somehow assumed, oh well) > > > On Tue, Apr 26, 2011 at 11:17 PM, Daniel Werner < > daniel.d.wer...@googlemail.com> wrote: > >> On Apr 26, 10:52 pm, Jonathan Fischer Friberg >> wrote: >> > No, that isn't possible.http://clojure.org/refs >> >> I disagree: In the example given, dereferencing happens outside the >> dosync block, thus outside of any transaction, so a race where map1 >> and map2 change midway through the #'and expression is theoretically >> possible. For this reason, #'deref/@ and #'alter are best kept in the >> same transaction in this situation. >> >> > Inside a transaction (a dosync call), values updated in another >> transaction >> > wont be seen. This means that the first transaction wont see the change >> > until it commits, at that moment it realizes that the ref that were >> altered >> > was changed outside of that particular transaction, and retries. All of >> this >> > happens automatically, so you wont have to worry. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
RE: Merging two maps based on ids
Thanks Baishampayan, Meikel, pepijn, and Jonathan.
The use of partition-by function does solve this very elegantly.
Below is the list of solutions I have received:
(defn merge-data [data1 data2]
(map first (partition-by :id (sort-by :id (concat data2 data1)
(defn merge-data2
[data1 data2]
(let [override-ids (set (map :id data2))]
(concat data2 (remove (comp override-ids :id) data1
(defn merge-override [merge-key data2 data1]
(let [keyset (into #{} (map #(% merge-key) data2))]
(apply merge data2 (remove #(keyset (% merge-key)) data1
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On
Behalf Of Jonathan Fischer Friberg
Sent: Tuesday, April 26, 2011 12:58 PM
To: clojure@googlegroups.com
Subject: Re: Merging two maps based on ids
Correction:
(concat data1 data2) should be (concat data2 data1)
On Tue, Apr 26, 2011 at 6:37 PM, Jonathan Fischer Friberg
wrote:
(defn merge-data [data1 data2]
(map first (partition-by :id (sort-by :id (concat data1 data2)
Since the sorting is stable (relative order is kept), we know that the
first occurrence of each id is either the existing map from data1, or
the new map from data2.
On Tue, Apr 26, 2011 at 5:34 PM, pepijn (aka fliebel)
wrote:
Another option is using clojure.set, as is shown here:
https://github.com/pepijndevos/Begame/blob/master/src/begame/util.clj#L9
9
On Apr 26, 10:10 am, Meikel Brandmeyer wrote:
> Hi,
>
> you can construct the output sequence from your input sequences.
>
> (defn merge-data
> [data-orig data-override]
> (let [override-ids (set (map :id data-override))]
> (concat data-override (remove (comp override-ids :id)
data-orig
>
> If you need your output sorted you can also add a "(sord-by :id ...)"
around
> the concat.
>
> 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
--
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: ANN: Slamhound (for reconstructing ns forms)
On Apr 26, 2:56 pm, James Reeves wrote: > On 26 April 2011 22:16, Phil Hagelberg wrote: > > That's by design; it only works when the :as alias is the same as the > > last segment of the namespace name. > > Ah, well even if I use "string/trim" it throws the same error: Right; this should be fixed in 1.1.1. > user=> (require 'slam.hound) > nil > user=> (slam.hound/reconstruct "src/foobar/core.clj") > java.lang.Exception: No such namespace: string (core.clj:2) > > > However, there was an unrelated bug causing issues when uncompilable > > namespaces were on the classpath. I'll have a 1.1.1 fix pushed in a > > few minutes. > > Is clojure.string an uncompilable namespace, then? No, it was that foo.bar was uncompilable, and it was looking there for candidates. But no longer! There are still a issues with running it in a few places in our codebase, but they mostly revolve around needing a smarter disambiguator. I don't have any clear plan for this; it needs hammock time. Part of it is to allow composable disambiguators and look for them in project.clj, but that's probably not the whole solution. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Error with eval syntax-quote & PersistentArrayMap
Timothy Washington wrote: > user=> (eval `(commands/add ~processed ~@etal)) Is there a reason for using eval here, such as you're debugging a macro, or could you just use user=> (apply commands/add processed etal) ? -- 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: cond in dosync problem
Hi, Am 27.04.2011 um 00:33 schrieb Zlatko Josic: > Any idea why changes in the function below does'nt work (see first post on > this topic)? > > > (defn process-request > [offer args] > (logger/log "process called") > (let [offer-value (Double/parseDouble (:offer offer)) > out-queue (:out-queue args) > unique-offers (:unique-offers args) > all-offers (:all-offers args) > streams (:streams offer)] > (dosync > (cond > (empty? @unique-offers) > ((logger/log "map" @unique-offers) ; <— Add do here after first ( > (alter unique-offers assoc offer-value streams)) > :else (logger/log "error") Are you sure, that there is not exception thrown, which is eaten somehow? I suspect that the logger/log returns nil, which causes a NPE without updating the ref. Try adding a do after the first ( in the marked line above. 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
How to determine a function name at runtime
I have a function: (defn abc [] (println "blah")) (defn blah2 [f] (println f)) (blah2 abc) I need to print out the name of the function passed to blah2. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to determine a function name at runtime
On 27 April 2011 00:05, clj123123 wrote: > I have a function: > > (defn abc [] (println "blah")) > > (defn blah2 [f] (println f)) > > (blah2 abc) > > I need to print out the name of the function passed to blah2. Then you want something like: (defn blah2 [f] (println (:name (meta f - 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: How to determine a function name at runtime
Thank you James, this worked for me. On Apr 26, 4:11 pm, James Reeves wrote: > On 27 April 2011 00:05, clj123123 wrote: > > > I have a function: > > > (defn abc [] (println "blah")) > > > (defn blah2 [f] (println f)) > > > (blah2 abc) > > > I need to print out the name of the function passed to blah2. > > Then you want something like: > > (defn blah2 [f] (println (:name (meta f > > - 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: cond in dosync problem
You where right. return of logger/log was nil. Thank you very much. On Wed, Apr 27, 2011 at 1:04 AM, Meikel Brandmeyer wrote: > Hi, > > Am 27.04.2011 um 00:33 schrieb Zlatko Josic: > > > Any idea why changes in the function below does'nt work (see first post > on this topic)? > > > > > > (defn process-request > > [offer args] > > (logger/log "process called") > > (let [offer-value (Double/parseDouble (:offer offer)) > > out-queue (:out-queue args) > > unique-offers (:unique-offers args) > > all-offers (:all-offers args) > > streams (:streams offer)] > > (dosync > > (cond > > (empty? @unique-offers) > > ((logger/log "map" @unique-offers) ; <— Add do here after first > ( > > (alter unique-offers assoc offer-value streams)) > > :else (logger/log "error") > > Are you sure, that there is not exception thrown, which is eaten somehow? I > suspect that the logger/log returns nil, which causes a NPE without updating > the ref. Try adding a do after the first ( in the marked line above. > > 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 > -- 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: setting break points at multimethods in cdt
thanks George for your reply. for some reason C-c C-x C-b key stroke does not seem to be bound .. however, I don't mind typing the command at the repl. But, I don't seem to get the path right? .. should the path be absolute or should it be relative to the directory where the project.clj resides..? can you elaborate on that. Sunil. p.s. what should I be doing to get the keystrokes working? On Tue, Apr 26, 2011 at 11:30 PM, George Jahad wrote: > so cdt supports two kinds of breakpoints, method breakpoints, (with > the set-bp function) and line breakpoints, (with the ^c^x^b,) > keystroke in emacs. > > You are corrrect that the set-bp function doesn't work properly with > multi-methods, but line breakpoints should be working. Are they? > > > On Apr 26, 8:51 am, Sunil S Nandihalli > wrote: > > Hello everybody, > > I am unable to set break points at multimethods using set-bp ..( I am > able > > to set break points for other functions.. though) .. can somebody tell me > > how to do this? I am using swank-cdt integration. It works very nicely > > otherwise. > > Thanks, > > Sunil. > > -- > 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: ANN: Slamhound (for reconstructing ns forms)
On 26 April 2011 23:49, Phil Hagelberg wrote: > On Apr 26, 2:56 pm, James Reeves wrote: >> On 26 April 2011 22:16, Phil Hagelberg wrote: >> > However, there was an unrelated bug causing issues when uncompilable >> > namespaces were on the classpath. I'll have a 1.1.1 fix pushed in a >> > few minutes. >> >> Is clojure.string an uncompilable namespace, then? > > No, it was that foo.bar was uncompilable, and it was looking there for > candidates. But no longer! Ohh! I see what you were saying now. Thanks for the fix! - 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: How to determine a function name at runtime
On Tue, Apr 26, 2011 at 7:18 PM, clj123123 wrote: > Thank you James, this worked for me. > > On Apr 26, 4:11 pm, James Reeves wrote: >> On 27 April 2011 00:05, clj123123 wrote: >> >> > I have a function: >> >> > (defn abc [] (println "blah")) >> >> > (defn blah2 [f] (println f)) >> >> > (blah2 abc) >> >> > I need to print out the name of the function passed to blah2. >> >> Then you want something like: >> >> (defn blah2 [f] (println (:name (meta f It has some limitations, though. Specifically, it won't work with local functions, even named ones: user=> (:name (meta (fn foo [] 42))) nil user=> (letfn [(foo [] 42)] (:name (meta foo))) nil Only defn seems to attach name metadata to a function. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to determine a function name at runtime
On 27 April 2011 01:09, Ken Wesson wrote: > It has some limitations, though. Specifically, it won't work with > local functions, even named ones: Yes, good point! A more foolproof way might be to use a macro, but then macros have their own disadvantages. It depends on what clj123123 wants to use it for I guess. - 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: setting break points at multimethods in cdt
see if the elisp exists, like so: M-x describe-function sldb-line-bp see if the keymap exists like so: M-x describe-value cdt-map if they do, go to a java file higher up in the stack trace, and see if ^c^x^b works there. if not, try running this from the slime-repl: (swank.core.cdt-utils/init-emacs-helper-functions) and checking the above tests again. Let me know how it goes. On Apr 26, 4:41 pm, Sunil S Nandihalli wrote: > thanks George for your reply. > for some reason C-c C-x C-b key stroke does not seem to be bound .. however, > I don't mind typing the command at the repl. But, I don't seem to get the > path right? .. should the path be absolute or should it be relative to the > directory where the project.clj resides..? can you elaborate on that. > > Sunil. > > p.s. what should I be doing to get the keystrokes working? > > On Tue, Apr 26, 2011 at 11:30 PM, George Jahad > > wrote: > > so cdt supports two kinds of breakpoints, method breakpoints, (with > > the set-bp function) and line breakpoints, (with the ^c^x^b,) > > keystroke in emacs. > > > You are corrrect that the set-bp function doesn't work properly with > > multi-methods, but line breakpoints should be working. Are they? > > > On Apr 26, 8:51 am, Sunil S Nandihalli > > wrote: > > > Hello everybody, > > > I am unable to set break points at multimethods using set-bp ..( I am > > able > > > to set break points for other functions.. though) .. can somebody tell me > > > how to do this? I am using swank-cdt integration. It works very nicely > > > otherwise. > > > Thanks, > > > Sunil. > > > -- > > 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
