Job opening at Teradata
Hi, Our team at Teradata is looking for new Clojure devs. Ideally we are hoping to find people in/around Boston, but we are prepared to consider remote candidates for the right people. The role involves a lot of interaction with Hadoop, with all the metadata for managing datasets stored in Datomic. The job description mentions "a functional language such as Clojure" but this is just to advertise for a wider field of candidates. Any candidates who are unfamiliar with Clojure would be expected to learn. Details can be found at: https://teradata.taleo.net/careersection/prof/jobdetail.ftl?job=160789 For people unfamiliar with Teradata Loom, our team used to be with Revelytix until the company was acquired by Teradata last year. Regards, Paul Gearon -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: destructuring let and for
Hi Francesco,
I apologize for using "for" earlier, as I did not explain how you should be
using it. The comment of "do something with rel" should have indicated that
it resolved to an expression, and those expressions would be returned in a
seq (the "for" expression resolves to have a value of a seq).
Given your last example, I could read it a couple of ways. My first
interpretation is that you just need a way to convert names to nodes, and
then to connect all the nodes. My preference would be to separate these
steps, so the conversion would be done with:
(map convert-to-node list-of-names)
The result of this is then looped through to create the relations (as in my
previous example, the relations are both ways, and not reflexive):
(let [nodes (map convert-to-node list-of-names)]
(for [node1 nodes, node2 nodes :when (not= node1 node2)]
(nrl/create conn page1 page2 :links)))
This creates a seq of all the relations, in both directions. So one
relationship will be [Jupiter->Pluto] and another will be [Pluto->Jupiter].
To create one-way relationships, I suggest the use of indexes, as in my
previous post.
However, when I followed your link to the example data, I see that there
are connections between some nodes and not others. In that case it would be
preferable to create a mapping of names to nodes, and then as the
relationships are required those nodes can be found easily:
(def create-nodemap [names]
(zipmap names (map convert-to-node names)))
Now you can grab the nodes as needed to work with them:
(defn connect [nodemap name1 name2]
(nrl/create conn (nodemap name1) (nodemap name2 :link)))
(let [nodemap (create-nodemap ["jupiter" "hercules" "neptune" "pluto"])]
(connect nodemap "jupiter" "hercules" :link)
(connect nodemap "jupiter" "neptune" :link)
(connect nodemap "jupiter" "pluto" :link)
(connect nodemap "neptune" "pluto" :link))
I am avoiding many tricks here that I'd use in reality, to avoid making it
too obscure.
Note that the above has links between Juptier, Neptune and Pluto, but
Hercules is only linked to Jupiter. So we don't have everything connected
to everything else. However, this approach is only useful in simple
examples like this, since any real data set would be too large to write
code for every connection. Instead, the actual data (coming from a csv
file, or something) would be read and used to create the connections.
What does your original data look like? Are you just trying to re-create
the graph you linked to, or is the data available in some structured format?
Paul
On Tue, Jun 10, 2014 at 4:08 PM, Francesco Lunelli <
francesco.lune...@gmail.com> wrote:
> Thanks for the answer.
> If I understand well your code it's a partial answer to my question
> because if I'm not wrong it creates a link between to elements at a time.
> What I need is to create all the elements then create on them every kind of
> relation.
> I take as example a graph db used in another engine
> https://raw.githubusercontent.com/wiki/thinkaurelius/titan/images/graph-of-the-gods-2.png
> Here you have a graph of Roman gods, with the name of the gods and the
> links among them. So if I have for example a list of the names of Roman
> gods I need to create all the nodes, then connect them in various mode.
> I want to take the list '("jupiter" "saturn" "hercules" "neptune" "pluto"
> ...) and cycling on it I want to creare the nodes. When I finished to
> create them I need to be able to call every node to crete the various links
> among them. For example I need to link jupiter with pluto, jupiter with
> neptun, neptun with pluto and so on.
>
> Thanks
>
> Francesco
>
>
> On Tuesday, June 10, 2014 7:43:21 PM UTC+2, Paul G wrote:
>
>> Hi Francesco,
>>
>> You want to decouple your code from the data that it is operating on, so
>> your code can operate regardless of the contents of the list. Otherwise,
>> you'll need code that matches the list, in which case it could all be code
>> anyway. Operating on arbitrary lists makes it easy to test simple examples
>> too.
>>
>> A simple way to create links between pages might be like this (assuming
>> that conn is in scope and initialized):
>>
>> (for [list-elt1 the-list, list-elt2 the-list :when (not= list-elt1
>> list-elt2)]
>> (let [page1 (page-fn list-elt1)
>> page2 (page-fn list-elt2)
>> rel (nrl/create conn page1 page2 :links)]
>> ;; do something with rel
>> ))
>>
>> This creates links both ways.
>>
>> If you only want one-way links then the first approach that comes to mind
>> (there are others, and they're probably better) is to index through the seq:
>>
>> (for [n (range (count the-list)), m (range (inc n) (count the-list))]
>> (let [page1 (page-fn (nth the-list n))
>> page2 (page-fn (nth the-list m))
>> rel (nrl/create conn page1 page2 :links)]
>> ;; do something with rel
>> ))
>>
>> The general idea here is to use an arbitrary var to represent your list
>> elements and pages.
>>
>> Does this address y
Re: destructuring let and for
Hi Francesco,
You want to decouple your code from the data that it is operating on, so
your code can operate regardless of the contents of the list. Otherwise,
you'll need code that matches the list, in which case it could all be code
anyway. Operating on arbitrary lists makes it easy to test simple examples
too.
A simple way to create links between pages might be like this (assuming
that conn is in scope and initialized):
(for [list-elt1 the-list, list-elt2 the-list :when (not= list-elt1
list-elt2)]
(let [page1 (page-fn list-elt1)
page2 (page-fn list-elt2)
rel (nrl/create conn page1 page2 :links)]
;; do something with rel
))
This creates links both ways.
If you only want one-way links then the first approach that comes to mind
(there are others, and they're probably better) is to index through the seq:
(for [n (range (count the-list)), m (range (inc n) (count the-list))]
(let [page1 (page-fn (nth the-list n))
page2 (page-fn (nth the-list m))
rel (nrl/create conn page1 page2 :links)]
;; do something with rel
))
The general idea here is to use an arbitrary var to represent your list
elements and pages.
Does this address your issue?
Regards,
Paul
On Tue, Jun 10, 2014 at 1:04 PM, Francesco Lunelli <
francesco.lune...@gmail.com> wrote:
> Thanks for the answer, I try to explain better what I have to do.
>
> I need to create some nodes in Neo4j then I need to create relationships
> between those nodes.
>
> This is an example taken from necons doc.
>
> (let [conn (nr/connect "http://localhost:7474/db/data/";)
> page1 (nn/create conn {:url "http://clojurewerkz.org"})
> page2 (nn/create conn {:url "http://clojureneo4j.info"})
> ;; a relationship that indicates that page1 links to page2
> rel (nrl/create conn page1 page2 :links)]
> (println rel)))
>
> They create two nodes called page1 and pag2 then connect them.
>
> In my case I have a list of names, I want to create one node for each of
> them with the possibility to work on nodes after they are created.
> So if I have for example a list like this one (def mylist '(j"john"
> "paul" "mary")) I want to create three nodes calling them john paul and
> mary storing the value "John" "Paul" "Mary" and after having created them I
> want to be albe to connect nodes creating a relationship among them, with a
> funciont like rel (nrl/create conn john paul :friend)]
>
> I hope this example explain better my needs.
>
> Thanks in advance
>
> Francesco
>
>
> On Tuesday, June 10, 2014 6:11:16 PM UTC+2, James Reeves wrote:
>
>> Could you explain a little more what your end goal is?
>>
>> It sounds like you want a map, but without knowing more about the
>> purpose, it's difficult to say.
>>
>> - James
>>
>>
>> On 10 June 2014 16:43, Francesco Lunelli wrote:
>>
>>> Hello everybody, I have a newbie question about destructuring and
>>> assigning and didn't find an answer in documentation or books.
>>>
>>> I have a list that contains an arbitrary number of elements for example
>>> '("one" "two" "three" ...) I now only that elements are strings.
>>>
>>> I need to to take every element and use it as the name of a variable
>>> inside a let and assign the result of a funcion on that element to that
>>> variable.
>>> Somthing like this for example:
>>>
>>> (let [one (clojure.string/capitalize "one")
>>> two (clojure.string/capitalize "two")
>>> three (clojure.string/capitalize "three")]
>>> ;; here I have access to vars one two three etc.
>>> )
>>>
>>> where the names of the vars are taken from the list and values are
>>> obtained applying a function on the corresponding element of the list (the
>>> capitalize function il only an example, it could be everything else).
>>>
>>> If I do in this way
>>> (for [word ["the" "quick" "brown" "fox"]] (let [word
>>> (clojure.string/capitalize word)] (prn word)))
>>> it works, but I need to access the variables outside of the cycle for,
>>> after having defined and assigned everyone because I need to put in
>>> relation some of them.
>>>
>>> Thanks to everybody
>>>
>>> Francesco
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" gro
Re: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig, First, I have to start with an apology, and it's to do with this section: If I compare the a:bar element form both documents with func-deep-equal >> then they should compare equal, despite the fact that the a:bar qname >> resolves differently in each context. > > > Are you saying that deep-equals compares the actual serialization (with > prefixes), or that the default equality should do that? > If so, please read the infoset specification: > http://www.w3.org/TR/xml-infoset/#infoitem.element > The relevant quote for this case: I really don't know how I sent that. I confess to writing it (mea culpa), but it felt wrong as I did so. I went back to the docs, and realized that I had been thinking of how attribute values are not affected by namespace. Stupid error, and I don't know what I was thinking. The weird thing is that I *thought* that I edited the email to remove this error. Maybe I mentioned it twice and only removed it once? Anyway, it was wrong. I apologise for confusing the conversion with this furfy. Subsequent parts of the email were written with the correct understanding. Incidentally, looking this over did make me think again about storing the fully resolved QNames in the parsed document. I still came down on not doing so, but some of my reasoning is more due to non-XML arguments. Back to the main thread (I'll remove the part about deep-equals not comparing resolved qnames)... On Sun, May 25, 2014 at 8:19 AM, Herwig Hochleitner wrote: > 2014-05-23 19:01 GMT+02:00 Paul Gearon : > > >> I still argue for using keywords here. The existing API uses them, and >> they're a natural fit. >> > > The fact that they have established meaning (for denoting literal xml > names + their prefix in a given serialization) in the API is exactly one of > my reasons for not wanting to change those semantics. Having a separate > tier for representing raw, serialized xml is fine. It's what the library > currently does. Adding new behavior, like proper xml namespacing, warrants > adding a new tier. > > >> The one real problem is elements would need a special hash/equality check >> to deal with namespace contexts (presuming that fn:deep-equal maps to >> Object.equals). >> > > I had been thinking along those lines before. Check out the dev thread, I > try to argue that at first there, but at some point I realized that it > makes no sense to strictly stick to the raw representation and compute > other info just on the fly. The key observation is, that a tree of raw, > prefixed xml doesn't make any sense without xmlns declarations, whereas > they are redundant, as soon as the tree has been resolved. > My point of view is that processing real-world XML rarely needs the fully resolved URIs. Instead, most applications only care about the element names as they appear in the document. Also, keywords have the nice property of being interned, which matters when parsing 20GB XML files. It's possible to intern a QName implementation, but they will still use more memory per element. The counter argument is that the standard requires support for handling fully resolved QNames, so these need to be dealt with. However, I don't believe that the use-cases for dealing with fully resolved data comes up as often. Also, when it does come up, my experience has been that it is usually in smaller documents (<1MB), where efficiency of comparison is not as paramount. The issue here may be more of dealing with the representation tier vs. the model tier. I will address that question more at the bottom of this email. > To your point from below: > > >> I didn't follow the discussion for putting URIs into keywords, as I could >> not see why we would want this (am I missing something obvious?) >> > > We need the URIs for xml processing and the XmlNamespace metadata can get > lost or not be there in the first place. Also the URI counts for equality, > see below. > I totally agree that it makes no sense putting them in keywords. > OK, I agree. My difference has been that I don't think that the entire URI need exist in the element tag, but rather allow it to be built from the element tag + the namespace context. (That would be the representation-to-model tier mapping. I mention this, along with namespace contexts at the end) The keywords would need to be translated according to the current context. >> However, that approach still works for fragments that can be evaluated in >> different contexts, >> > > The problem are fragments that are taken out from their (xmlns - > declaring) root-element and/or that have no XmlNamespace metadata. Apart > from actual prefix assignment (which can be done in the emitter), QNames > are completely context free in that regard
Re: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig,
I spent some time going through the design, and a email thread
(particularly Chouser and Christophe's responses), plus I spent a bit more
time on my own implementation where it was clear that I'd missed some
things.
I've yet to go through your code in fine detail, so I'll still have some
gaps in my knowledge.
On Thu, May 22, 2014 at 2:44 PM, Herwig Hochleitner
wrote:
> 2014-05-21 21:06 GMT+02:00 Paul Gearon :
>
>
>> Are QNames strictly necessary? Keywords seem to do the trick, and they
>> work in nicely with what already exists.
>>
>> I know that there are some QName forms that are not readable as a
>> keyword, but the XML parsing code will always call (keyword ...) and that
>> holds any kind of QName,
>>
>
> I've argued this at some length on the dev thread. IMO QNames are not
> nessecary, but we want another datatype than keywords.
> I think the main argument for using keywords would be xml literals in code
> and there readability (i.e. not having to use (keyword ..)) counts. A
> reader tag is far better suited for this.
> In the course of that argument, I also came up with a way to represent
> resolved names as keywords in literals. Please check out the design page
> for this.
>
I still argue for using keywords here. The existing API uses them, and
they're a natural fit.
The one real problem is elements would need a special hash/equality check
to deal with namespace contexts (presuming that fn:deep-equal maps to
Object.equals). The keywords would need to be translated according to the
current context. However, that approach still works for fragments that can
be evaluated in different contexts, while storing URIs directly needs
everything to be rebuilt for another context.
Most possible QNames can be directly expressed as a keyword (for instance,
the QName 㑦:㒪 can be represented as the read-able keyword :㑦/㒪). The
keyword function is just a workaround for exotic values. While I know they
can exist (e.g. containing \u000A), I've yet to see any QNames in the wild
that cannot be represented as a read-able keyword.
In case I'm not clear, say I have these two docs:
http://ex.com/"; xmlns:a="http://a.com/";>
http://b.org"; b:baz="blah"/>
http://something.else.com/";>
http://b.org"; b:baz="blah"/>
If I compare the a:bar element form both documents with func-deep-equal
then they should compare equal, despite the fact that the a:bar qname
resolves differently in each context.
The representation I've used was only a small extension to the existing one:
#clojure.data.xml.Element{:tag :a/bar, :attrs {:b/baz "blah"}, :namespaces
{:b "http://b.org"}, :content ()}
I agree with the use of meta to handle the namespaces, since it's not
included in equality testing. Namespaces are declared on, and scoped to the
element, so it makes sense to add them as a map there (this is what I've
done). In the first case, the meta-data for the a:bar element is:
{:b "http://b.org";, :a "http://a.com/";, :xmlns "http://ex.com/"}
I didn't follow the discussion for putting URIs into keywords, as I could
not see why we would want this (am I missing something obvious?)
Are the reverse mappings (uri->prefix) definitely necessary? My first look
>> at this made me think that they were (particularly so I could call
>> XMLStreamWriter.getPrefix), but it seemed that the XmlWriter keeps enough
>> state that it isn't necessary. My final code didn't need them at all.
>>
>
> The XmlWriter does keep enough state, but I also want to support tree
> transformers that have the full information without needing to pipe through
> Xml{Reader,Parser}.
> uri->prefix could be reconstructed from prefix->uri in linear time, so
> again, the reason for the reverse mapping is performance.
>
I still don't see why the reverse mapping is needed. Is it because I'm
storing the QName in a keyword and can look up the current namespace for
the URI, while you are storing the fully qualified name?
> I was mostly considering round-tripping the data, and the parser is good
>> at not repeating namespaces for child elements, so the emitter didn't need
>> to either. As a result I didn't need to filter out prefix->uri bindings
>> from parent elements when emitting namespaces, though that should be easy.
>>
>
> What I meant are redundant prefixes, e.g. binding xmlns:D="DAV:" at the
> root element, xmlns:E="DAV:" in a child element.
>
Sorry, I'm not following what you were getting at with this. In this
example D and E both get mapped to the same namespace, meaning that
and can be made to resolve the same way. But in a
different context they could b
Re: [RFC] Roundtripping namespaced xml documents for data.xml
My understanding is that this is the central library for XML, so theoretically it's preferred. This is why I'm trying to use it. Also, it's one of the few implementations using StAX, which is the best way to do lazy streaming (though core.async makes SAX a viable option again). However, without namespaces there are numerous applications where data.xml won't work, so it's still immature. Paul On Wed, May 21, 2014 at 3:47 PM, Thomas wrote: > Hi, > > Speaking of Clojure and XML, what is the preferred way of dealing with XML > in Clojure these days? In the past I have used clojure.xml and clojure.zip. > Is clojure.data.xml the best way to do this now? > > TIA, > > Thomas > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig, Thanks for the response. I'll remove some of the less relevant bits as I reply inline... On Wed, May 21, 2014 at 2:26 PM, Herwig Hochleitner wrote: > 2014-05-21 19:31 GMT+02:00 Paul Gearon : > >> I like the way that you have split the implementation of functionality >> into different namespaces. The current release is a little monolithic. >> > > The patch I attached to DXML-4 [1] are just minimal changes to make > roundtripping work. No refactoring. > > I've started to implement a much more advanced approach to namespaced xml > in my repo [2], the design of which came from feedback on clojure-dev > thread [3] and is documented in a new design page [4]. > I wasn't really paying attention to the patch, since I saw your link to your fork. Someone mentioned the thread to me, but I hadn't found it yet. Thanks for the link. I'll read up on it, along with the design page. I'll continue to comment while I'm here, though I may get some of my answers as I read more. This approach will add another data tier (and make it the default), where > tags and attribute names will be represented as QNames and xmlns attributes > won't be present in :attrs > Are QNames strictly necessary? Keywords seem to do the trick, and they work in nicely with what already exists. I know that there are some QName forms that are not readable as a keyword, but the XML parsing code will always call (keyword ...) and that holds any kind of QName, > One thing that bothers me is what's going on in clojure.data.xml.impl. I >> haven't tried to go through all of it yet, but I didn't think that the code >> needed to be that complex. >> > > Good thing that you didn't bother consuming it all, impl currently has a > lot of code, that will get deleted again. Basically all the stuff for > automagically mixing raw and resolved data. > The relevant parts for now are mostly XmlNamespace and the reader tag > implementations. > > The way I handled prefix-uri mappings was to use a stack of maps, which I >> thought was adequate. Your implementation of XmlNamespaceImpl has me >> thinking that I've been missing something important. Could you explain why >> XmlNamespaceImpl is structured the way it is? >> > > Apart from basic bidirectional mapping functionality, XmlNamespaceImpl is > built in such a way that: > - Adding mappings is semantically equivalent to a child element declaring > xmlns attributes > - A new prefix for an already established mapping won't displace the > current reverse mapping (uri->prefix), but get recorded as an alternative > - Remapping a prefix to a new uri or deleting it, will establish an > alternative prefix for that uri, in FIFO manner > Are the reverse mappings (uri->prefix) definitely necessary? My first look at this made me think that they were (particularly so I could call XMLStreamWriter.getPrefix), but it seemed that the XmlWriter keeps enough state that it isn't necessary. My final code didn't need them at all. I thought I covered the various cases, but I could well believe that I missed one, since there are so many ways to represent the data. Do you have some good examples? The aim is to strip out redundant xmlns attributes in the emitter, while > retaining xml semantics. There is indeed something missing: Two > XmlNamespaces must be diffable, to discover which xmlns attributes actually > have to be emitted. > I was mostly considering round-tripping the data, and the parser is good at not repeating namespaces for child elements, so the emitter didn't need to either. As a result I didn't need to filter out prefix->uri bindings from parent elements when emitting namespaces, though that should be easy. > I'm sure it could be built a lot simpler. It's currently basically a > product of making its tests work [5]. It could probably be made to work > with stacks of maps, but then each lookup would involve a linear search, no? > If uri->prefix is needed, then a simple map would need that, yes. However, if I needed the reverse mapping then I'd use a pair of stacks of maps - one for each direction. (BTW, a "stack of maps" sounds complex, but the top of the stack is just the new bindings merged onto the previous top of the stack). > What do you think of the proposed design? > I will take the time to go through them, thanks. Even if it ends up different to how I'd do it, it'll be the core library, and I need to work with it no matter what. Thanks for being on top of this. I'm looking to reimplement a parser in Clojure when 99% of the world is using a single Java library for this job. That's no good for diversity (as OpenSSL showed recently) and also because I can hardly say I
Re: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig, I needed this myself and took a stab at it before it occurred to me to look for other implementations and found yours. I like the way that you have split the implementation of functionality into different namespaces. The current release is a little monolithic. One thing that bothers me is what's going on in clojure.data.xml.impl. I haven't tried to go through all of it yet, but I didn't think that the code needed to be that complex. The way I handled prefix-uri mappings was to use a stack of maps, which I thought was adequate. Your implementation of XmlNamespaceImpl has me thinking that I've been missing something important. Could you explain why XmlNamespaceImpl is structured the way it is? Thanks in advance, Paul On Wed, Mar 26, 2014 at 10:34 AM, Herwig Hochleitner wrote: > Hi, > > I'm taking a stab at namespaced xml support: > http://dev.clojure.org/jira/browse/DXML-4 > > I've uploaded a patch, that should implement 1:1 roundtripping, fully > preserving prefixes and xmlns declarations: > http://dev.clojure.org/jira/secure/attachment/12899/roundtrip-documents.patch > > This doesn't implement any advanced serialization or deserialization > strategies described in the design page: > http://dev.clojure.org/display/DXML/Fuller+XML+support > However, it allows such strategies to be implemented by transforming > clojure data structures, hence it should be a suitable common > representation for any namespaced xml needs. > > I'd like to work on some namespace-related treewalking next, most > importantly normalizing prefixes and default namespaces, so that one can > actually parse namespaced xml. > > Meanwhile, I'd be delighted if you could try out the patch on any > (well-formed) namespaced xml you have at hand and see, if it roundtrips > correctly. > > kind regards > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] tawny-owl 0.11
On Wed, May 22, 2013 at 9:24 AM, Phillip Lord wrote: > > > It's a good question; the library is more intended for people who know > ontologies and don't care, or have never heard about, clojure. So the > documentation is biased in that way. > This message originally confused me. For some reason I found that my email filters had put a message for public-owl-dev into my folder for Clojure emails. It was a pleasant surprise to see that there was no mistake. :-) I'm wondering about the file formats. I see that RDF/XML (:rdf) and Manchester (:omn) are supported, as well as OWL/XML (:owl - which I don't really know). I don't see Turtle though, which is the main interchange format I try to use. Am I missing it? Thanks! Regards, Paul Gearon -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: datomic question
On Monday, 4 March 2013 01:50:56 UTC-5, edw...@kenworthy.info wrote: > Okay, I think I understand that. > > Does that mean this code could never work as intended in a Clojure > program, only at the repl (which seems a bit of a limitation) or is there a > way to make it work as intended, generating a different id each time? Or is > the whole approach taken in this code flawed? > The tagged literal approach is best used if you need to store the entity and read it back using edn. So it's perfect for using in a data file. However, if you're generating data in code you've already seen how this can cause problems. In that case, you do what Jonas suggests and use tempid (with the appropriate partition keyword. e.g. :db.part/user). The two approaches offer different tradeoffs. tempid is a function, and can only appear in code (not a data file, or anything else read by edn). Conversely, if the the tagged literal appears in code, then it's possible for it to be referred to more than once in the same transaction, which is almost guaranteed to be counter to what you want. Paul -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojurescript question
Since HelloWorld worked for me, I tried to output the command line
arguments as a string. Consequently, the program now looks like:
(ns cljshello.core
(:require [cljs.nodejs :as nj]))
(defn -main [& argv]
(println (str "Hello, World!" (.-argv nj/process) "\n")))
(set! *main-cli-fn* -main)
Again, I am able to compile with either leiningen or the command line with
the same result. This time, I'm getting:
/Users/pag/src/test/clj/cljshello/pp.js:350
cljs.core.apply=function(){var a=null,b=function(a,b){var
c=a.cljs$lang$maxFix
^
TypeError: Cannot read property 'cljs$lang$maxFixedArity' of null
at cljs.core.apply.b (/Users/pag/src/test/clj/cljshello/pp.js:350:62)
at cljs.core.apply.a (/Users/pag/src/test/clj/cljshello/pp.js:354:118)
at Object. (/Users/pag/src/test/clj/cljshello/pp.js:926:421)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
Since I should already have argv being passed in, I changed the expression
to use it directly, instead of using (.-argv nj/process), however, this
changed nothing.
Happy to try any suggestions you may have for me.
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Clojurescript question
On Saturday, 17 November 2012 19:52:39 UTC-5, David Nolen wrote:
>
> What is the error under simple optimizations? Errors under advanced
> optimizations are not particularly informative :)
Good point, sorry.
Every minor change, is leading to significant differences, so I'm trying to
strip it right back at the moment. Ideally I want to compile using
Leiningen, but that's not consistent with the command line (I learned
tonight that there is a difference in versions there, but that Leiningen
should work).
Looking in some of the Clojurescript code I saw the comment that the call
to cljs.core/*main-cli-fn* always happens for node.js, so I've gone back to
using it. Now my file looks like:
(ns cljshello.core)
(defn -main [& argv]
(println "Hello, World!\n"))
(set! *main-cli-fn* -main)
I'm using a project of:
(defproject cljshello "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME";
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.5.0-alpha7"]
[org.clojure/clojurescript "0.0-1535"]]
:plugins [[lein-cljsbuild "0.2.9"]]
:hooks [leiningen.cljsbuild]
:cljsbuild {
:builds [{
:source-path "src"
:compiler { :output-to "pp.js"
:target :nodejs
:pretty-print true }}]})
Using "lein compile" on this I get a stack trace starting with:
Reloading Clojure file "/cljshello/core.clj" failed.
clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable
to resolve symbol: *main-cli-fn* in this context,
compiling:(cljshello/core.clj:7:1)
. though, in the process of writing this email I tried changing the
:source-path to the specific file I am compiling and the compile finished
without warning. Am I correct in guessing that I'm supposed to describe a
build for each file?
All the same, whether I get a warning or not I still get a pp.js file.
Running this file under either conditions (error in compilation or not)
gives me:
/Users/pag/src/test/clj/cljshello/pp.js:493
goog.string.Unicode = {NBSP:"\u00a0"};
^
TypeError: Cannot set property 'Unicode' of undefined
at Object. (/Users/pag/src/test/clj/cljshello/pp.js:493:21)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
However, the same file is now compiling with the cli compiler, so I'll try
to work with it for the moment.
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Clojurescript question
Looking at the Clojurescript page on Github I can't find the appropriate
place to ask about potential bugs unless it's here. Can anyone help
please? (David?)
Meanwhile, in case it's the correct place, I've tried the following as a
simple test to run on Node.js:
---
(ns jpp.core)
(defn -main [& args]
(.log js/console "Hello, World!\n"))
(set! *main-cli-fn* -main)
---
This works OK.
However, the following will not work (though variations on this have been
seen to work):
---
(ns jpp.core)
(defn -main []
(.log js/console "Hello, World!\n"))
(-main)
---
The output in this case is as follows:
Hello, World!
/Users/pag/src/test/clj/jpp/pp.js:72
ments supported on functions"))}var Vd,Wd=j;function Xd(a,b){var
c=a.q;if(a.m)
^
TypeError: Cannot read property 'q' of null
at Function.Xd [as b] (/Users/pag/src/test/clj/jpp/pp.js:72:280)
at Object. (/Users/pag/src/test/clj/jpp/pp.js:157:244)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
Interestingly, it's printed the correct output, but fails after. Also, do I
mention in the same place that I get a different set of errors when I try
to use the lein-cljsbuild plugin?
Regards,
Paul Gearon
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Wildcards on multimethod matching
On Sat, Oct 23, 2010 at 5:16 PM, Paul Richards wrote: > Hi, > I have a multimethod which is dispatched on two arguments: > > (defmulti bar (fn [x y] [x y])) > (defmethod bar [1 2] ..) > (defmethod bar [3 4] ..) > > Is there a way I can define methods on this which use "wildcards"? What about something like: (defmulti bar (fn [x y] [(if (= y 16) :any x) (if (= x 42) :any y)]) (defmethod bar [42 :any] [x y] ...) (defmethod bar [:any 16] [x y] ...) (defmethod bar [:any :any] [x y] ...) (defmethod bar :default [x y] ...) The function is a little less pretty, but it does the job. The only trick is that (bar 42 16) comes back as the [:any :any] case, but you could always let that fall through to the default. Regards, Paul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
