Need help with a macro with & rest parameter
Hi all,
for testing my FunQL clojure graph query language against another query
language (GReQL), I want to write tests like that:
(defcomparisontest class-count-restricted (gbjg)
;; GReQL version
"count(V{ClassDefinition})"
;; FunQL variant 1
(vcount (gbjg) :cls 'ClassDefinition)
;; FunQL variant 2
(count (vseq (gbjg) :cls 'ClassDefinition)))
So you provide the name of the test, the graph the query is evaluated
on, a GReQL reference query, and arbitrary many FunQL forms that have to
calculate the exact same result.
I had such a macro that expects exactly one funql form, but while trying
to extend that to arbitrary many funqls, I've reached the limit of my
macro foo.
That's what I have come up with:
(defmacro defcomparisontest
"Define a GReQL/FunQL comparison test with name n on graph g that asserts the
equality of the results evaluating greql and all funqls."
[n g greql & funqls]
`(deftest ~n
~g ;; ensure the graph is loaded, if it is given as memoized function.
(println "")
(println "Comparison test:" ~(name n))
(let [gr# (do
(print "GReQL evaluation time:")
(jvalue-unpack (time (greql-eval ~g ~greql]
(doseq [funql# '~funqls]
(print "FunQL evaluation time:")
(is (= gr#
(time (let [r# funql#]
(if (instance? clojure.lang.LazySeq r#)
(doall r#)
r#)
Here, the problem is that the comparison compares the evaluation result
of the greql query against gr# the unevaluated funql form.
So I replaced the "(let [r# funql#]" with "(let [r# (eval funql#)]", but then
I seem to have namespace issues. I get errors like
java.lang.Exception: Unable to resolve symbol: vcount in this context
java.lang.Exception: Unable to resolve symbol: vseq in this context
which both are functions defined in funql.core, which my funql.test.core
namespace uses; (:use [funql.core] :reload) in the ns definition.
Could anyone with some advanced macro foo enlighten me how to do it
right?
By the way: in general, I would prefer if the expansion would contain a
sequence of (do ...) blocks with one assertion, one for each funql in
funqls, instead of the doseq.
Thanks a bunch in advance!
Tassilo
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Need help with a macro with & rest parameter
Hi all, raek helped me on IRC, and that's what finally works: (defmacro defcomparisontest "Define a GReQL/FunQL comparison test with name n on graph g that asserts the equality of the results evaluating greql and all funqls." [n g greql & funqls] `(deftest ~n ~g ;; ensure the graph is loaded, if it is given as memoized function. (println "") (println "Comparison test:" ~(name n)) (let [gr# (do (print "GReQL evaluation time:") (jvalue-unpack (time (greql-eval ~g ~greql] (doseq [funql-fn# ~(vec (for [funql funqls] `(fn [] ~funql)))] (print "FunQL evaluation time:") (is (= gr# (time (let [r# (funql-fn#)] (if (instance? clojure.lang.LazySeq r#) (doall r#) r#) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
xml parsing
Dear friends
I am trying to parse xml file
following is code
(def xml-file "d:/clj/xmlfiles/orders.xml")
(def xmldata (clojure.xml/parse xml-file))
(println xmldata)
Output is :
{:tag :order, :attrs {:orderid 1/2011}, :content [{:tag :party, :attrs nil,
:con
tent [ XYZ Ltd ]} {:tag :address, :attrs nil, :content [{:tag :block, :attrs
nil
, :content [ Abcd.]} {:tag :street, :attrs nil, :content [ xyz ]} {:tag
:city, :
attrs nil, :content [ 123]} {:tag :state, :attrs nil, :content [ in ]}]}]
Now i change to output xml seq usng xml-seq
(def xml-file "d:/clj/xmlfiles/orders.xml")
(def xmlseq (xml-seq (clojure.xml/parse xml-file)))
(println xmlseq)
Ouput is :
({:tag :order, :attrs {:orderid 1/2011}, :content [{:tag :party, :attrs nil,
:co
ntent [ XYZ Ltd ]} {:tag :address, :attrs nil, :content [{:tag :block,
:attrs ni
l, :content [ Abcd.]} {:tag :street, :attrs nil, :content [ xyz ]} {:tag
:city,
:attrs nil, :content [ 123]} {:tag :state, :attrs nil, :content [ in ]}]}]}
{:ta
g :party, :attrs nil, :content [ XYZ Ltd ]} XYZ Ltd {:tag :address, :attrs
nil
, :content [{:tag :block, :attrs nil, :content [ Abcd.]} {:tag :street,
:attrs n
il, :content [ xyz ]} {:tag :city, :attrs nil, :content [ 123]} {:tag
:state, :a
ttrs nil, :content [ in ]}]} {:tag :block, :attrs nil, :content [ Abcd.]}
Abcd.
{:tag :street, :attrs nil, :content [ xyz ]} xyz {:tag :city, :attrs nil,
:co
ntent [ 123]} 123 {:tag :state, :attrs nil, :content [ in ]} in )
Here the output show double items for each tag... what's problem ?
Thanks in advance
Vincent
--
You 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 Editor
Check preferences from the toolbar or the Bluefish dropdown.There
are checks for Smart Auto Indenting and Highlighting block
delimiters.There's very little this editor doesn't do.You just
have to make sure all the checks you want are set.
Bill
On Mar 14, 10:06 pm, Lee Spector wrote:
> The Clojure mode activates for me, and I get a little bit syntax coloring,
> autocompletion, and () matching. But I don't get language aware indentation.
> Should I, or isn't this supported? (It's a really important feature IMHO.)
> Also, no matching of [] or {} (less important for me).
>
> Thanks,
>
> -Lee
>
> On Mar 14, 2011, at 8:06 AM, WoodHacker wrote:> The file you need should be
> there. First look under the Document/
> > Language Support menu item. You should see and entry for Clojure.
> > Try checking it. The syntax file is called clojure.bflang2 and it
> > should be in a Bluefish directory somewhere on your system. I am
> > using a MAC, so the file is under the /Applicatiions directory. If
> > you need to adjust the bflang2 file for some reason, the file that
> > explains how to do it is Sample.bflang2. If none of this makes
> > sense and you can't find clojure.bflang2, try contacting the Bluefish
> > people by sending and email to bluefish-us...@lists.ems.ru.
>
> > On Mar 13, 9:49 am, Shantanu Kumar wrote:
> >> Do I need a plugin? I downloaded the stock 2.0.3-1 version of the
> >> editor and it doesn't even seem to syntax-highlight the Clojure code.
>
> >> Regards,
> >> Shantanu
>
> >> On Mar 13, 5:09 pm, WoodHacker wrote:> If you are
> >> looking for a very good editor for Clojure try Bluefish.
> >>> It's been around for ever, is very stable, and does everything you
> >>> would want an editor to do. And it now works with Clojure.
>
> >>> http://bluefish.openoffice.nl
>
> >>> Bill
--
You 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: clj-ldap - Clojure LDAP client
On 15 March 2011 08:46, Saul Hazledine wrote: > On Mar 15, 1:30 am, Paul Dorman wrote: > One thought though is that it may be quicker simply do a lookup on the > directory server, obtain the password and then do a compare. In > OpenLDAP, posixUser uids are indexed by default. Java libraries are > available for most password encryption algorithms. This is the > approach I use - do you know of any problems with my method? Certainly when I was running LDAP servers we did not allow passwords to be retrieved from the server, as they are then susceptible to an offline dictionary attack. To authenticate users, you had to send a bind request to the server. Ray. -- You 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: Software Engineering Practices for Marking Algorithms?
could we push the visited nodes in a stack and finally pop all? although its a hellish act performance wise removing visted nodes and adding later On Wed, Mar 16, 2011 at 10:20 AM, Mark Engelberg wrote: > Using the traditional visited flag approach, your program will fail if two > threads try to print the same tree structure at the same time. > > I personally have found the hash table approach to be very effective. It > uses space, but the space can be garbage collected as soon as you're > finished with the task. > > Another good option is to store a unique numeric id from 0 to n-1 where n > is the number of nodes, in each node of the graph. Then, you can use a > fresh vector to do the marking (or a primitive boolean array if you need the > best possible space/time performance). > > > -- > You 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] fs - file system utilities for Clojure
I've been using this to get the extension: (defn extension [file] (when file (let [base (fs/basename file) dot (.lastIndexOf ^String base ".")] (when (pos? dot) (subs base (inc dot)) Steve Miner On Mar 15, 2011, at 5:56 PM, siyu798 wrote: > Hi Miki, > We are planning to use this file system utilities, and we need a function > to get file extension. Currently we're using apache common for that, but we > want to get rid of apache common altogether. Can you add this functionality > to the fs.clj? Thx > > Si Yu -- You 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 Editor
I have "Smart auto indenting" on in the preferences, and the language is set to
Clojure, but I don't see any smarts. If I type:
(defn foo
and hit return the cursor goes to the beginning of the next line, not indented.
If I hit the tab key it tabs in, but it'll tab anything in further each time I
hit tab; it's not sensitive to the syntax or at least it's not going to a
reasonable place for the syntax. Within a definition if I type:
(cons (first x)
and hit return the cursor goes beneath the first "(", not beneath the second
"(" (which is the behavior of emacs modes, which I prefer) or even under the
"o" (which is the current behavior of Counterclockwise). Again, I can move
things around with tab but it's not syntax aware.
I've tried doing this in parentheses-balanced expressions as well, but still no
smarts. I use this feature not only to keep my code neat but also to make
syntax errors visually obvious; it won't help for this if the indentation isn't
automatically aware of the language's syntax.
What am I missing?
Thanks,
-Lee
On Mar 16, 2011, at 8:38 AM, WoodHacker wrote:
> Check preferences from the toolbar or the Bluefish dropdown.There
> are checks for Smart Auto Indenting and Highlighting block
> delimiters.There's very little this editor doesn't do.You just
> have to make sure all the checks you want are set.
>
> Bill
>
> On Mar 14, 10:06 pm, Lee Spector wrote:
>> The Clojure mode activates for me, and I get a little bit syntax coloring,
>> autocompletion, and () matching. But I don't get language aware indentation.
>> Should I, or isn't this supported? (It's a really important feature IMHO.)
>> Also, no matching of [] or {} (less important for me).
--
You 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: Software Engineering Practices for Marking Algorithms?
> However, the visited field has nothing to do with the actual Node > class. It's simply for other functions to use as a marker. > > This solution is kludgy, but I cannot see any other *performant* way > of doing this. I don't think markers are a kludge. Besides modeling, data structures must support stuff like performance requirements. This is no different than, say, reference counting in GC's, COM, inodes, etc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: New Release of the Clojure Debugging Toolkit
try adding that jar to your classpath, and see if that fixes it. if not, run "jar -tf" on the tools.jar file to dump the table of contents on it and email it to me and i'll see if i can figure out what is going on. On Mar 15, 7:34 pm, Jeff Bordogna wrote: > George, > Thanks for the response. I'm using openjdk and it > lives: file:usr/lib/jvm/java-6-openjdk/jre/../lib/tools.jar (and the > format function worked to find that as well). Anything I need to change wrt > that? > > Thanks, > Jeff -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Entity component system
Finally I launched my little website: http://resatori.com You can see a short video of my game there ;) Fraps only allows 30 seconds so nothing more to see :( Entity Component Post will follow this week. On 6 Mrz., 16:24, Daniel Werner wrote: > Himsappler, > > On Jan 12, 12:27 pm,msappler wrote: > > > No i do not mind. > > A blog is being planned for promotion of my game and sharing. > > Only have to find a domain name which i like. > > Have you put anything in the meantime? I'd be very interested to read > about your game's progress and learn more about the component system > you built for it. > > Daniel -- You 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: xml parsing
sorry i forgot to show order.xml -- You 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: xml parsing
forgot ...Here is the order.xml XYZ Ltd Abcd xyz 123 in -- You 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: Software Engineering Practices for Marking Algorithms?
On Mar 16, 11:20 am, Mark Engelberg wrote: > On Tue, Mar 15, 2011 at 11:12 PM, Shantanu Kumar > wrote: > > > Use the node's metadata to annotate :visited as true and re-associate, > > and do it recursively (likely with loop recur)? > > > Regards, > > Shantanu > > Altering metadata is generally a non-destructive operation (with-meta), and > alter-meta! only works on refs/agents/etc. So I don't see how you could use > metadata in this manner. You'd effectively be creating new nodes as you > traverse the tree, and then the "pointers" between the nodes would get > totally screwed up. Can you elaborate on your idea? The idea goes like this: You re-associate the node to the collection after you modify the metadata of each node using (with-meta). The important part is every node after visit must be re-associated to the same collection it was originally part of, drilling-down recursively. This may potentially interfere with order/position of the node-in- collection but that is another problem. I was not thinking about "pointers" because I presumed persistent data structures. Regards, Shantanu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Entity component system
Hi Michael, Looks great! I love the video too. Very nice. I have put a link to your blog post on the clojure games wiki. I'll update the wiki properly when I get a chance. If you want to put details on your game on the wiki (or want to edit my post about your component entity system), please feel free to. I'll do it myself eventually if not, but it may take some time before I do. In any case, great work!! Dan. On 16 March 2011 15:09, msappler wrote: > Finally I launched my little website: http://resatori.com > > You can see a short video of my game there ;) > > Fraps only allows 30 seconds so nothing more to see :( > > Entity Component Post will follow this week. > > On 6 Mrz., 16:24, Daniel Werner > wrote: > > Himsappler, > > > > On Jan 12, 12:27 pm,msappler wrote: > > > > > No i do not mind. > > > A blog is being planned for promotion of my game and sharing. > > > Only have to find a domain name which i like. > > > > Have you put anything in the meantime? I'd be very interested to read > > about your game's progress and learn more about the component system > > you built for it. > > > > Daniel > > -- > You 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: Entity component system
Weird where did my post go? Anyway here is the link to the article: http://resatori.com/clojure-entity-component-system On 16 Mrz., 17:54, Daniel Kersten wrote: > Hi Michael, > > Looks great! I love the video too. Very nice. > I have put a link to your blog post on the clojure games wiki. I'll update > the wiki properly when I get a chance. If you want to put details on your > game on the wiki (or want to edit my post about your component entity > system), please feel free to. I'll do it myself eventually if not, but it > may take some time before I do. > > In any case, great work!! > > Dan. > > On 16 March 2011 15:09, msappler wrote: > > > Finally I launched my little website:http://resatori.com > > > You can see a short video of my game there ;) > > > Fraps only allows 30 seconds so nothing more to see :( > > > Entity Component Post will follow this week. > > > On 6 Mrz., 16:24, Daniel Werner > > wrote: > > > Himsappler, > > > > On Jan 12, 12:27 pm,msappler wrote: > > > > > No i do not mind. > > > > A blog is being planned for promotion of my game and sharing. > > > > Only have to find a domain name which i like. > > > > Have you put anything in the meantime? I'd be very interested to read > > > about your game's progress and learn more about the component system > > > you built for it. > > > > Daniel > > > -- > > You 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: Software Engineering Practices for Marking Algorithms?
It sounds like hashing is the only solution that can really compete with these markers. My particular problem cannot use hashing because the space waste and extra compute time is unacceptable. I'll just have to be particularly careful for multithreading my app. Thanks for the replies -Patrick On Mar 16, 10:31 am, Armando Blancas wrote: > > However, the visited field has nothing to do with the actual Node > > class. It's simply for other functions to use as a marker. > > > This solution is kludgy, but I cannot see any other *performant* way > > of doing this. > > I don't think markers are a kludge. Besides modeling, data structures > must support stuff like performance requirements. This is no different > than, say, reference counting in GC's, COM, inodes, etc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
Emacs slime repl now printing carriage returns after Clojure 1.3.0-alpha5
In my clojure repl, i'm now seeing CTRL-M characters at the end of each line printed to the repl (println commands, doc commands etc...). If I launch the swank-repl from Cygwin I still see these ^M's. Am I to assume this relates to this added feature: "Java's line.separator property for newline"? I'm just wondering which program in the chain I should fix: clojure, swank-clojure, or emacs? -Nathan -- You 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: Emacs slime repl now printing carriage returns after Clojure 1.3.0-alpha5
I'm using Windows 7, and again, I see this behaviour when using the regular windows shell or Cygwin to launch the swank-repl. On Mar 16, 12:10 pm, Nathan Sorenson wrote: > In my clojure repl, i'm now seeing CTRL-M characters at the end of > each line printed to the repl (println commands, doc commands etc...). > If I launch the swank-repl from Cygwin I still see these ^M's. Am I to > assume this relates to this added feature: "Java's line.separator > property for newline"? > > I'm just wondering which program in the chain I should fix: clojure, > swank-clojure, or emacs? > > -Nathan -- You 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] fs - file system utilities for Clojure
> We are planning to use this file system utilities, and we need a function > to get file extension. Currently we're using apache common for that, but we > want to get rid of apache common altogether. Can you add this functionality > to the fs.clj? Thx > > Added in 0.7.1 (thanks to Steve Miner for the implementation detail :) -- You 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: Software Engineering Practices for Marking Algorithms?
You are asking on the wrong list. Nobody in the Clojure list will ever tell you that monkey-patching and mutating your data structure is the right approach in order to traverse it. And that's totally fine: ask away, if you're willing to accept other solutions. But you've rejected all ideas aside from the one you had before you got here as non- performant, when you don't seem to have a clear understanding of the performance characteristics of either. Space waste? Really? You can't afford a pointer to each Node object during the traversal, but you can afford an extra boolean field in each Node, even when you're not traversing them? Hint: objects are typically allocated on pointer-sized boundaries, so an extra boolean at the end will take up as much "real" space as a whole pointer. And you have a *binary* tree, storing a Node[] instead of Node left, Node right? Instead of two pointers and two data objects, you're storing two data objects, two pointers, a pointer to Node[], and a length property. Throw away that extra crap and you have more than enough room for a temporary hashtable. On Mar 16, 11:17 am, CuppoJava wrote: > It sounds like hashing is the only solution that can really compete > with these markers. My particular problem cannot use hashing because > the space waste and extra compute time is unacceptable. I'll just have > to be particularly careful for multithreading my app. > > Thanks for the replies > -Patrick > > On Mar 16, 10:31 am, Armando Blancas > wrote: > > > > > > > > > > However, the visited field has nothing to do with the actual Node > > > class. It's simply for other functions to use as a marker. > > > > This solution is kludgy, but I cannot see any other *performant* way > > > of doing this. > > > I don't think markers are a kludge. Besides modeling, data structures > > must support stuff like performance requirements. This is no different > > than, say, reference counting in GC's, COM, inodes, etc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Emacs slime repl now printing carriage returns after Clojure 1.3.0-alpha5
Probably swank-clojure. Even better, write an Emacs client for nREPL: https://github.com/clojure/tools.nrepl -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: xml parsing
I think xml-seq is returning a sequence representing a depth-first traversal of the XML document. So the first item in the sequence is the entire document, followed by the first element under the root, and so on. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Software Engineering Practices for Marking Algorithms?
Thank you for your reply Alan. I am still eager to hear for more solutions. I would be even very happy with just a nice organizational way of thinking about the marker fields instead of a whole new algorithmic solution. As for why I thought that hashtables are not appropriate for my use case, the following is my understanding of its performance characteristics. Please let me know if I misunderstand anything. - For a Hashtable to be performant, there needs to be few collisions, otherwise you resort to iterating through a list, or tree every time there is one. - In order for there to be few collisions, there are 2 approaches. (1) Have a very very good hash function. or (2) If you don't have a great hash function, then allocate a larger table. - Mark's idea of storing the numeric id in each node can be thought of as an ideal hash function. Every distinct object maps to a distinct integer value within a very small numeric range. - An ideal hash function is not typically attainable, so we deal with non-ideal hash functions. The average loading ratio for a hashtable, that I use, is 60/40. That is, at maximum capacity, only 60% of the slots are used. - Therefore, using a hashtable to implement this marking algorithm will take up 40% more space than using the marker fields. There is also the performance aspects of having to compute the hash function for every access. This is typically very fast, but it still cannot compare to a pointer deference. That is why, I think for my problem, the marker fields are the best way to go. What I think is still possible, however, is a nice way to organize these fields, such that as Mark pointed out, multithreaded stuff don't become a nightmare. The *binary* tree as well, is just a toy example for illustrative purposes. I agree that storing the children in an array is not a practical implementation. -Patrick On Mar 16, 3:33 pm, Alan wrote: > You are asking on the wrong list. Nobody in the Clojure list will ever > tell you that monkey-patching and mutating your data structure is the > right approach in order to traverse it. And that's totally fine: ask > away, if you're willing to accept other solutions. But you've rejected > all ideas aside from the one you had before you got here as non- > performant, when you don't seem to have a clear understanding of the > performance characteristics of either. > > Space waste? Really? You can't afford a pointer to each Node object > during the traversal, but you can afford an extra boolean field in > each Node, even when you're not traversing them? Hint: objects are > typically allocated on pointer-sized boundaries, so an extra boolean > at the end will take up as much "real" space as a whole pointer. > > And you have a *binary* tree, storing a Node[] instead of Node left, > Node right? Instead of two pointers and two data objects, you're > storing two data objects, two pointers, a pointer to Node[], and a > length property. Throw away that extra crap and you have more than > enough room for a temporary hashtable. > > On Mar 16, 11:17 am, CuppoJava wrote: > > > > > It sounds like hashing is the only solution that can really compete > > with these markers. My particular problem cannot use hashing because > > the space waste and extra compute time is unacceptable. I'll just have > > to be particularly careful for multithreading my app. > > > Thanks for the replies > > -Patrick > > > On Mar 16, 10:31 am, Armando Blancas > > wrote: > > > > > However, the visited field has nothing to do with the actual Node > > > > class. It's simply for other functions to use as a marker. > > > > > This solution is kludgy, but I cannot see any other *performant* way > > > > of doing this. > > > > I don't think markers are a kludge. Besides modeling, data structures > > > must support stuff like performance requirements. This is no different > > > than, say, reference counting in GC's, COM, inodes, etc. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 read this sample code?
On Mar 15, 2011, at 5:28 PM, Christian wrote: > Secondly, what is happening inside the for structure? [idx elt] are > being bound to vector returned by indexed, but that assignment only > happens when pred == elt. Finally, we return the vector idx. Is this > correct? [idx elt] is destructuring-bound to each element in (indexed coll), one after another, except that those elements for which (pred elt) returns false or nil are skipped (pred is being called as a function on elt, not compared to it). The result of the for loop is the sequence of values given by the expression in its body (in this case the indexes whose values in coll satisfied pred). That for loop would be equivalent to this map + filter: (map first (filter (fn [[idx elt]] (pred elt)) (indexed coll))) -- You 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: Discount for 2-Day public course on Clojure in Chicago in April
We've still got some empty seats for this upcoming session (April 14-15), and we've extended the $50-off discount code (CLJ50) until this Friday, March 18. If you're already doing Clojure professionally, it's possible you wouldn't see enough benefit from this course to justify it, but maybe you have colleagues or friends you'd like to encourage to get into Clojure. If so (errr, actually, either way), it'd be awesome if you could tweet a mention of it or shoot them a link. Let me know if you have any questions. Thanks, and I hope to see you there! Colin On Mar 8, 11:59 am, Doug Bradbury wrote: > Save $50 this week on "Clojure: Functional Programming on the JVM" a 2- > day course in Chicago with Colin Jones with discount code CLJ50. > > In this 2-Day course, you'll grow your knowledge and skill to the > point where you're ready to embark on your first Clojure project. > With > numerous hands-on exercises and labs, this isn't just a collection of > lectures. Practice will ensure that concepts really sink in, and the > exercises are a lot of fun to boot! > > When: April 14-15, 2011 > Where: 8th Light Chicago (566 W Lake St., Chicago IL 60661) > > For More information and to sign up go > to:http://8thlight.com/courses/2-clojure-functional-programming-on-the-jvm > > Promotion ends Friday, 3/11/2011 -- You 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: Software Engineering Practices for Marking Algorithms?
One thing that many algorithm books overlook is the cost of setting the markers back to false/nil when done. One nice aspect of a hashset/vector approach is that you can just throw it away when done, and use a fresh one each time. If you want to learn a whole bunch of low-level tricks for handling graphs with optimal performance, check out Knuth's book about the Stanford GraphBase. It's been a while since I've read it, but I believe that each node in the graph has four general-purpose marker slots that different algorithms use for different purposes. At the beginning, he allocates a large chunk of consecutive memory for the markers, which he calls a "region". I do not remember whether it is one region for all the markers, or one region for each of the four markers. The key here is that the node marker is actually a pointer to a location in the marker region of memory. This added level of indirection (versus storing the marker directly within the node) means that he can clear the markers by bit-wiping the entire marker region of memory -- a fast operation. Of course, this means that a bit of extra work needs to be done when creating each node. A pointer is maintained into the marker region, and is given out to the next node that is created and then the region's pointer is incremented so that it points to a fresh location (for use by the next node added to the graph). Clever stuff, but doling out pointers into a region seems roughly equivalent to the work involved with assigning a unique, incrementing numeric id to each node upon creation (and numeric ids don't run out, whereas you run into problems if your region is insufficiently big for the number of nodes). And once you've assigned unique numeric ids, you can use the vector approach I described and have no threading conflict, and marker cleanup is handled automatically by garbage collection. So why not use that approach? --Mark -- You 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: xml parsing
2011/3/16 Stuart Sierra > I think xml-seq is returning a sequence representing a depth-first > traversal of the XML document. So the first item in the sequence is the > entire document, followed by the first element under the root, and so on. That's not the definition of depth-first, is it ? > > -Stuart Sierra > clojure.com > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You 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: xml parsing
It's one variety of depth-first. Pre-order, post-order, and in-order are all viable ways of doing depth-first searches (though in-order makes less sense for non-binary trees). Assume for the rest of this post the following tree: 1 --2 --3 4 --5 6 --7 - Breadth-first traversal: 1237465 - Depth-first, preorder traversal: 1234567 - Depth-first, postorder traversal: 2546371 I think it's possible to split breadth-first into pre- and post-order as well, but it's been a long time since I took that class and trying to do it is making my head hurt. I think the important point is that there's more than one way to do depth-first traversal, and preorder looks like what Stuart is talking about. On Mar 16, 2:50 pm, Laurent PETIT wrote: > 2011/3/16 Stuart Sierra > > > I think xml-seq is returning a sequence representing a depth-first > > traversal of the XML document. So the first item in the sequence is the > > entire document, followed by the first element under the root, and so on. > > That's not the definition of depth-first, is it ? > > > > > > > > > > > -Stuart Sierra > > clojure.com > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You 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: xml parsing
On 17/03/2011, at 8:20 AM, Laurent PETIT wrote: > 2011/3/16 Stuart Sierra > I think xml-seq is returning a sequence representing a depth-first traversal > of the XML document. So the first item in the sequence is the entire > document, followed by the first element under the root, and so on. > > That's not the definition of depth-first, is it ? It's a pre-order depth-first traversal. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper -- You 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: Software Engineering Practices for Marking Algorithms?
Thank you for the reply again Mark. Actually, now that I've had some time to think about your solution, I think it, is in fact, suitable for myself after all. There's just some trickiness involving handing out the numeric ids that I need to figure out. eg. Nodes are automatically assigned a unique numeric id. There is a counter somewhere that is incremented every time a new Node is allocated. Upon entry to the print function, I will allocate a vector whose size is the current value of the counter. This ensures that every Node has a slot in the vector. The problem arises after the program as been running for a long time and the value of the counter is very high. There might be only two Nodes in use, but one Node might have an id = 1 (because it was one of the first ones created), and the other Node could have an id = 100 (because it was only recently created). Now the cost of allocating the vector is too great. I think, if a good way of handing out the numeric ids is figured out, your solution would be perfect! I'll give it some more thought. -Patrick On Mar 16, 11:50 am, Shantanu Kumar wrote: > On Mar 16, 11:20 am, Mark Engelberg wrote: > > > On Tue, Mar 15, 2011 at 11:12 PM, Shantanu Kumar > > wrote: > > > > Use the node's metadata to annotate :visited as true and re-associate, > > > and do it recursively (likely with loop recur)? > > > > Regards, > > > Shantanu > > > Altering metadata is generally a non-destructive operation (with-meta), and > > alter-meta! only works on refs/agents/etc. So I don't see how you could use > > metadata in this manner. You'd effectively be creating new nodes as you > > traverse the tree, and then the "pointers" between the nodes would get > > totally screwed up. Can you elaborate on your idea? > > The idea goes like this: You re-associate the node to the collection > after you modify the metadata of each node using (with-meta). The > important part is every node after visit must be re-associated to the > same collection it was originally part of, drilling-down recursively. > This may potentially interfere with order/position of the node-in- > collection but that is another problem. I was not thinking about > "pointers" because I presumed persistent data structures. > > Regards, > Shantanu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Software Engineering Practices for Marking Algorithms?
On Wed, Mar 16, 2011 at 7:35 PM, CuppoJava wrote: > Thank you for the reply again Mark. > Actually, now that I've had some time to think about your solution, I > think it, is in fact, suitable for myself after all. There's just some > trickiness involving handing out the numeric ids that I need to figure > out. > > eg. Nodes are automatically assigned a unique numeric id. There is a > counter somewhere that is incremented every time a new Node is > allocated. > > Upon entry to the print function, I will allocate a vector whose size > is the current value of the counter. This ensures that every Node has > a slot in the vector. > > The problem arises after the program as been running for a long time > and the value of the counter is very high. There might be only two > Nodes in use, but one Node might have an id = 1 (because it was one of > the first ones created), and the other Node could have an id = 100 > (because it was only recently created). Now the cost of allocating the > vector is too great. > > I think, if a good way of handing out the numeric ids is figured out, > your solution would be perfect! I'll give it some more thought. I can't see this being fixed without maintaining some kind of a "freelist" to allow recycling numeric IDs. But nodes already have numeric IDs: their addresses in your process's address space. You can get a hash of it by calling (System/identityHashCode the-node). I think ultimately your best bet is just to use a set. It will probably use less memory than most of the approaches being considered, including numeric IDs with freelist, overall. If the hash "load factor" is really, truly unacceptable for some reason you may have to accept a time/space tradeoff and use a linear list of visited nodes with a linear search. Other than that, you can use nonrecycled node IDs and binary search for visited node IDs in a tree, and that about exhausts your options. -- You 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: Software Engineering Practices for Marking Algorithms?
On Wed, Mar 16, 2011 at 4:35 PM, CuppoJava wrote: > The problem arises after the program as been running for a long time > and the value of the counter is very high. There might be only two > Nodes in use, but one Node might have an id = 1 (because it was one of > the first ones created), and the other Node could have an id = 100 > (because it was only recently created). Now the cost of allocating the > vector is too great. > > For many graph applications, node deletion is an uncommon operation. If you have heavy node deletion, it's certainly possible that your node numbers have a lot of gaps. If you think of the id numbering as being analogous to assigning marker addresses in a dedicated region of memory, then it's basically a defrag issue. The freelist method is one option, but it's not the only one. You could track how many nodes are in the graph and you track the next available id. When the number of nodes falls below a certain fraction of the max id in the graph, you could "defrag" and go through and renumber all the nodes. It's hard to figure out the "best" way without knowing the exact application, but hopefully this gives you some ideas to play with. -- You 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: Software Engineering Practices for Marking Algorithms?
Thank you Mark and Ken. Your suggestions have been very helpful. There are certainly many options for me to pursue now. I will do some careful profiling and see which approach is most suitable. -Patrick On Mar 16, 8:14 pm, Mark Engelberg wrote: > On Wed, Mar 16, 2011 at 4:35 PM, CuppoJava wrote: > > > The problem arises after the program as been running for a long time > > and the value of the counter is very high. There might be only two > > Nodes in use, but one Node might have an id = 1 (because it was one of > > the first ones created), and the other Node could have an id = 100 > > (because it was only recently created). Now the cost of allocating the > > vector is too great. > > For many graph applications, node deletion is an uncommon operation. If you > have heavy node deletion, it's certainly possible that your node numbers > have a lot of gaps. If you think of the id numbering as being analogous to > assigning marker addresses in a dedicated region of memory, then it's > basically a defrag issue. The freelist method is one option, but it's not > the only one. You could track how many nodes are in the graph and you track > the next available id. When the number of nodes falls below a certain > fraction of the max id in the graph, you could "defrag" and go through and > renumber all the nodes. > > It's hard to figure out the "best" way without knowing the exact > application, but hopefully this gives you some ideas to play with. -- You 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: Strange Loop 2011 - St. Louis - Sept 18-20
I'm on the wrong side of the world, will these be recorded? Looks exciting On Wed, Mar 16, 2011 at 4:49 AM, Nick Zbinden wrote: > Man that look awesome not a single thing I would wanne miss. > > On Mar 15, 9:16 pm, Alex Miller wrote: > > I just put up a blog entry with some updated info on Strange Loop > > 2011:http://thestrangeloop.com/blog/11/03/15/strange-loop-2011-update > > > > Lots more to come, but perhaps of interest to this group, *Rich > > Hickey* is the first confirmed keynote speaker (more in the works)... > > > > Workshops: > > - Hilary Mason - machine learning > > - Matthew McCullough - Git > > - Jeff Brown - Grails > > - Nathan Marz - Cascalog > > - members of Clojure/core - Clojure > > > > Sessions: > > - Jeremy Ashkenas - Coffeescript > > - Daniel Spiewak - functional data structures (Scala) > > - Peter Veentjer - Multiverse STM > > - John Hugg - VoltDB, OLTP > > - Zach Tellman - Lamina, Aleph (Clojure) > > - Nate Young - functional parser combinators (Haskell, Clojure) > > - Jim Duey - monads (Clojure) > > - Rúnar Bjarnason - Scalaz > > - Slava Pestov - Factor > > - Eric Brigham - Bitcoin (cryptocurrency) > > - Nathan Marz - building scalable realtime big data systems > > - Benjamin Manes, Charles Fry - concurrent caching with MapMaker > > -- > You 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
