Facebook Graph API via CLS

[Sam Ritchie]

Hey all,

I'm working on a Clojurescript wrapper of Facebook's JS SDK, using 
Prismatic's schema for documentation / types. Here's the code:


https://gist.github.com/sritchie/b517d67f9507aca36399

If anyone here's interested I'd be happy to put a little library up on 
github with this and the rest of the API.


Cheers,
Sam
--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
You 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: Graph API

[A]

Thought I'd mention a really nice Graph visualization library that I like. 
It would be great to include this into any new Graph library project.

https://github.com/pallix/lacij

>From the readme:

"Lacij is a graph visualization library written in Clojure. It allows the 
*display 
and the dynamic modification of graphs as SVG documents* that can be viewed 
with a *Web browser* or with a *Swing component*. Undo/redo is supported 
for the dynamic modification. Automatic layout is provided for the 
visualization."

I like graphviz too, but this might be a better fit.

Cheers,
Avram


On Wednesday, June 19, 2013 5:57:02 AM UTC-7, Aysylu Biktimirova wrote:
>
> If you'd like to take a stab at integrating your proposed protocol into 
> Loom, I'd be happy to merge the changes. Thanks!
>
> On Tuesday, June 18, 2013 1:12:04 PM UTC-4, Stephen Kockentiedt wrote:
>>
>> That sounds great! I'll mail you my complete code in case you want to 
>> take a look at it or want to use parts of it. And in case I can help in any 
>> other way, feel free to ask.
>>
>> Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:
>>>
>>> Stephen, thanks for reaching out to me! I really like your ideas and 
>>> agree with the issues you pointed out in Loom's API. I'd like to 
>>> incorporate your ideas into Loom to improve its API and have 1 graph 
>>> library in Clojure. I'm actively working on it and would be happy to 
>>> combine our efforts.
>>>
>>> There's one implementation of the API, as far as I know, 
>>> https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
>>> integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
>>> release as a separate project. Since I'm the author and the only maintainer 
>>> of Titanium+Loom, I'd be happy to handle the transition.
>>>
>>> On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>>>>
>>>> My bad. I did only find the original repository of loom and thought it 
>>>> was abandoned. I should have taken more care while looking at it. My 
>>>> approach was apparently the same in abstracting multiple graph 
>>>> implementations under one API. However, I see some problems with Loom's 
>>>> API, namely:
>>>>
>>>> 1. The specifications of the protocol functions are very sparse. E.g., 
>>>> which nodes shall a directed graph return from neighbors? Successors, 
>>>> predecessors or both?
>>>> 2. How do I know if the graph implementation works by mutating the 
>>>> given object or returning a new one?
>>>> 3. Loom assumes that every graph is editable. That is definitely not 
>>>> the case.
>>>> 4. I think a protocol should be as easy to implement as possible. The 
>>>> additional functionality can be given by functions relying on the protocol 
>>>> functions. E.g., in the user API of my code, there is a function 
>>>> direct-predecessors which provides this functionality (albeit slow) 
>>>> for graph implementations which did not implement the corresponding 
>>>> protocol function:
>>>>
>>>> (defn direct-predecessors
>>>>   "Returns a set or sequence of all nodes n2 for which
>>>>(has-edge? g n2 n) returns true. May not contain
>>>>duplicates."
>>>>   [g n]
>>>>   (if (satisfies? p/PPredecessorGraph g)
>>>> (p/direct-predecessors g n)
>>>> (filter #(p/has-edge? g % n) (p/nodes g
>>>>
>>>> E.g., implementations of Loom's API need to provide two implementations 
>>>> of neighbors and need to implement add-nodes* instead of only add-node*. 
>>>> This may not be much more work to do. However, the easier the API, the 
>>>> more 
>>>> implementations there will be.
>>>>
>>>> Please, don't get me wrong. I think that Loom is a great project, has 
>>>> the same goals and, in terms of functionality, is way ahead of my efforts.
>>>>
>>>> Said all that, I definitely don't want there to be two competing graph 
>>>> APIs. That would be counterproductive. I see the following possible 
>>>> solutions:
>>>>
>>>> 1. I keep the code to myself and let loom be the sole graph API.
>>>> 2. We transfer the advantages of my proposal to Loom and change its 
>>>> API. Do you know of any implementations of the API outside Loom 

Re: Graph API

[Aysylu Biktimirova]

If you'd like to take a stab at integrating your proposed protocol into 
Loom, I'd be happy to merge the changes. Thanks!

On Tuesday, June 18, 2013 1:12:04 PM UTC-4, Stephen Kockentiedt wrote:
>
> That sounds great! I'll mail you my complete code in case you want to take 
> a look at it or want to use parts of it. And in case I can help in any 
> other way, feel free to ask.
>
> Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:
>>
>> Stephen, thanks for reaching out to me! I really like your ideas and 
>> agree with the issues you pointed out in Loom's API. I'd like to 
>> incorporate your ideas into Loom to improve its API and have 1 graph 
>> library in Clojure. I'm actively working on it and would be happy to 
>> combine our efforts.
>>
>> There's one implementation of the API, as far as I know, 
>> https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
>> integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
>> release as a separate project. Since I'm the author and the only maintainer 
>> of Titanium+Loom, I'd be happy to handle the transition.
>>
>> On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>>>
>>> My bad. I did only find the original repository of loom and thought it 
>>> was abandoned. I should have taken more care while looking at it. My 
>>> approach was apparently the same in abstracting multiple graph 
>>> implementations under one API. However, I see some problems with Loom's 
>>> API, namely:
>>>
>>> 1. The specifications of the protocol functions are very sparse. E.g., 
>>> which nodes shall a directed graph return from neighbors? Successors, 
>>> predecessors or both?
>>> 2. How do I know if the graph implementation works by mutating the given 
>>> object or returning a new one?
>>> 3. Loom assumes that every graph is editable. That is definitely not the 
>>> case.
>>> 4. I think a protocol should be as easy to implement as possible. The 
>>> additional functionality can be given by functions relying on the protocol 
>>> functions. E.g., in the user API of my code, there is a function 
>>> direct-predecessors which provides this functionality (albeit slow) for 
>>> graph implementations which did not implement the corresponding protocol 
>>> function:
>>>
>>> (defn direct-predecessors
>>>   "Returns a set or sequence of all nodes n2 for which
>>>(has-edge? g n2 n) returns true. May not contain
>>>duplicates."
>>>   [g n]
>>>   (if (satisfies? p/PPredecessorGraph g)
>>> (p/direct-predecessors g n)
>>> (filter #(p/has-edge? g % n) (p/nodes g
>>>
>>> E.g., implementations of Loom's API need to provide two implementations 
>>> of neighbors and need to implement add-nodes* instead of only add-node*. 
>>> This may not be much more work to do. However, the easier the API, the more 
>>> implementations there will be.
>>>
>>> Please, don't get me wrong. I think that Loom is a great project, has 
>>> the same goals and, in terms of functionality, is way ahead of my efforts.
>>>
>>> Said all that, I definitely don't want there to be two competing graph 
>>> APIs. That would be counterproductive. I see the following possible 
>>> solutions:
>>>
>>> 1. I keep the code to myself and let loom be the sole graph API.
>>> 2. We transfer the advantages of my proposal to Loom and change its API. 
>>> Do you know of any implementations of the API outside Loom itself? If there 
>>> are none, this should be possible without much trouble. Also, the README 
>>> states that the API is alpha-stage.
>>> 3. I publish my code and each API can be implemented in terms of the 
>>> other one. I'm not sure that this is possible in a simple way. Maybe each 
>>> protocol could be extended to java.lang.Object, which calls the 
>>> protocols of the other API, but I don't know if that is feasible.
>>>
>>> Please tell me what you think. I will also send Aysylu an email so that 
>>> she can chime in on the conversation.
>>>
>>>
>>> Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>>>>
>>>> Loom was indeed working on this, and it's a very nice library.  One 
>>>> thing that I particularly liked about Justin's design, was the ability to 
>>>> run a graph algori

Re: Graph API

[Stephen Kockentiedt]

That sounds great! I'll mail you my complete code in case you want to take 
a look at it or want to use parts of it. And in case I can help in any 
other way, feel free to ask.

Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:
>
> Stephen, thanks for reaching out to me! I really like your ideas and agree 
> with the issues you pointed out in Loom's API. I'd like to incorporate your 
> ideas into Loom to improve its API and have 1 graph library in Clojure. I'm 
> actively working on it and would be happy to combine our efforts.
>
> There's one implementation of the API, as far as I know, 
> https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
> integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
> release as a separate project. Since I'm the author and the only maintainer 
> of Titanium+Loom, I'd be happy to handle the transition.
>
> On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>>
>> My bad. I did only find the original repository of loom and thought it 
>> was abandoned. I should have taken more care while looking at it. My 
>> approach was apparently the same in abstracting multiple graph 
>> implementations under one API. However, I see some problems with Loom's 
>> API, namely:
>>
>> 1. The specifications of the protocol functions are very sparse. E.g., 
>> which nodes shall a directed graph return from neighbors? Successors, 
>> predecessors or both?
>> 2. How do I know if the graph implementation works by mutating the given 
>> object or returning a new one?
>> 3. Loom assumes that every graph is editable. That is definitely not the 
>> case.
>> 4. I think a protocol should be as easy to implement as possible. The 
>> additional functionality can be given by functions relying on the protocol 
>> functions. E.g., in the user API of my code, there is a function 
>> direct-predecessors which provides this functionality (albeit slow) for 
>> graph implementations which did not implement the corresponding protocol 
>> function:
>>
>> (defn direct-predecessors
>>   "Returns a set or sequence of all nodes n2 for which
>>(has-edge? g n2 n) returns true. May not contain
>>duplicates."
>>   [g n]
>>   (if (satisfies? p/PPredecessorGraph g)
>> (p/direct-predecessors g n)
>> (filter #(p/has-edge? g % n) (p/nodes g
>>
>> E.g., implementations of Loom's API need to provide two implementations 
>> of neighbors and need to implement add-nodes* instead of only add-node*. 
>> This may not be much more work to do. However, the easier the API, the more 
>> implementations there will be.
>>
>> Please, don't get me wrong. I think that Loom is a great project, has the 
>> same goals and, in terms of functionality, is way ahead of my efforts.
>>
>> Said all that, I definitely don't want there to be two competing graph 
>> APIs. That would be counterproductive. I see the following possible 
>> solutions:
>>
>> 1. I keep the code to myself and let loom be the sole graph API.
>> 2. We transfer the advantages of my proposal to Loom and change its API. 
>> Do you know of any implementations of the API outside Loom itself? If there 
>> are none, this should be possible without much trouble. Also, the README 
>> states that the API is alpha-stage.
>> 3. I publish my code and each API can be implemented in terms of the 
>> other one. I'm not sure that this is possible in a simple way. Maybe each 
>> protocol could be extended to java.lang.Object, which calls the 
>> protocols of the other API, but I don't know if that is feasible.
>>
>> Please tell me what you think. I will also send Aysylu an email so that 
>> she can chime in on the conversation.
>>
>>
>> Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>>>
>>> Loom was indeed working on this, and it's a very nice library.  One 
>>> thing that I particularly liked about Justin's design, was the ability to 
>>> run a graph algorithm without worrying about conforming to a particular 
>>> graph representation.  See for example the bread first search function, 
>>> here:
>>>
>>> https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110
>>>
>>> All the bfs function requires is a neighbors function and and a start 
>>> vertex.  Simple and easy to use.
>>>
>>> Justin had said that he won't be actively developing loom for the 
>>> forseeable future; I was 

Re: Graph API

[Aysylu Biktimirova]

Stephen, thanks for reaching out to me! I really like your ideas and agree 
with the issues you pointed out in Loom's API. I'd like to incorporate your 
ideas into Loom to improve its API and have 1 graph library in Clojure. I'm 
actively working on it and would be happy to combine our efforts.

There's one implementation of the API, as far as I know, 
https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
release as a separate project. Since I'm the author and the only maintainer 
of Titanium+Loom, I'd be happy to handle the transition.

On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>
> My bad. I did only find the original repository of loom and thought it was 
> abandoned. I should have taken more care while looking at it. My approach 
> was apparently the same in abstracting multiple graph implementations under 
> one API. However, I see some problems with Loom's API, namely:
>
> 1. The specifications of the protocol functions are very sparse. E.g., 
> which nodes shall a directed graph return from neighbors? Successors, 
> predecessors or both?
> 2. How do I know if the graph implementation works by mutating the given 
> object or returning a new one?
> 3. Loom assumes that every graph is editable. That is definitely not the 
> case.
> 4. I think a protocol should be as easy to implement as possible. The 
> additional functionality can be given by functions relying on the protocol 
> functions. E.g., in the user API of my code, there is a function 
> direct-predecessors which provides this functionality (albeit slow) for 
> graph implementations which did not implement the corresponding protocol 
> function:
>
> (defn direct-predecessors
>   "Returns a set or sequence of all nodes n2 for which
>(has-edge? g n2 n) returns true. May not contain
>duplicates."
>   [g n]
>   (if (satisfies? p/PPredecessorGraph g)
> (p/direct-predecessors g n)
> (filter #(p/has-edge? g % n) (p/nodes g
>
> E.g., implementations of Loom's API need to provide two implementations of 
> neighbors and need to implement add-nodes* instead of only add-node*. 
> This may not be much more work to do. However, the easier the API, the more 
> implementations there will be.
>
> Please, don't get me wrong. I think that Loom is a great project, has the 
> same goals and, in terms of functionality, is way ahead of my efforts.
>
> Said all that, I definitely don't want there to be two competing graph 
> APIs. That would be counterproductive. I see the following possible 
> solutions:
>
> 1. I keep the code to myself and let loom be the sole graph API.
> 2. We transfer the advantages of my proposal to Loom and change its API. 
> Do you know of any implementations of the API outside Loom itself? If there 
> are none, this should be possible without much trouble. Also, the README 
> states that the API is alpha-stage.
> 3. I publish my code and each API can be implemented in terms of the other 
> one. I'm not sure that this is possible in a simple way. Maybe each 
> protocol could be extended to java.lang.Object, which calls the protocols 
> of the other API, but I don't know if that is feasible.
>
> Please tell me what you think. I will also send Aysylu an email so that 
> she can chime in on the conversation.
>
>
> Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>>
>> Loom was indeed working on this, and it's a very nice library.  One thing 
>> that I particularly liked about Justin's design, was the ability to run a 
>> graph algorithm without worrying about conforming to a particular graph 
>> representation.  See for example the bread first search function, here:
>>
>> https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110
>>
>> All the bfs function requires is a neighbors function and and a start 
>> vertex.  Simple and easy to use.
>>
>> Justin had said that he won't be actively developing loom for the 
>> forseeable future; I was hoping to develop it further, but I only got as 
>> far as implementing a max flow algorithm before the rest of my life got 
>> in the way of my plans.  I know that Aysylu was doing a fair amount of work 
>> on loom, so I'd guess that her repo is the most advanced one.
>>
>> Stephen:
>> I think the set of protocols above is good, better than Loom's in fact; 
>> notably, the decision to make direct-predecessors optional is the correct 
>> one, and a lot of graph libraries get that wrong.  
>>
>> If you want to compare how loom did it:
>&g

Re: Graph API

[Justin Kramer]

As Rob mentioned, I won't be doing further development Loom anytime in the 
near future. However, if critical mass forms around a fork or alterate 
project, I'd be happy to add a prominent link in the readme.

Justin

On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>
> My bad. I did only find the original repository of loom and thought it was 
> abandoned. I should have taken more care while looking at it. My approach 
> was apparently the same in abstracting multiple graph implementations under 
> one API. However, I see some problems with Loom's API, namely:
>
> 1. The specifications of the protocol functions are very sparse. E.g., 
> which nodes shall a directed graph return from neighbors? Successors, 
> predecessors or both?
> 2. How do I know if the graph implementation works by mutating the given 
> object or returning a new one?
> 3. Loom assumes that every graph is editable. That is definitely not the 
> case.
> 4. I think a protocol should be as easy to implement as possible. The 
> additional functionality can be given by functions relying on the protocol 
> functions. E.g., in the user API of my code, there is a function 
> direct-predecessors which provides this functionality (albeit slow) for 
> graph implementations which did not implement the corresponding protocol 
> function:
>
> (defn direct-predecessors
>   "Returns a set or sequence of all nodes n2 for which
>(has-edge? g n2 n) returns true. May not contain
>duplicates."
>   [g n]
>   (if (satisfies? p/PPredecessorGraph g)
> (p/direct-predecessors g n)
> (filter #(p/has-edge? g % n) (p/nodes g
>
> E.g., implementations of Loom's API need to provide two implementations of 
> neighbors and need to implement add-nodes* instead of only add-node*. 
> This may not be much more work to do. However, the easier the API, the more 
> implementations there will be.
>
> Please, don't get me wrong. I think that Loom is a great project, has the 
> same goals and, in terms of functionality, is way ahead of my efforts.
>
> Said all that, I definitely don't want there to be two competing graph 
> APIs. That would be counterproductive. I see the following possible 
> solutions:
>
> 1. I keep the code to myself and let loom be the sole graph API.
> 2. We transfer the advantages of my proposal to Loom and change its API. 
> Do you know of any implementations of the API outside Loom itself? If there 
> are none, this should be possible without much trouble. Also, the README 
> states that the API is alpha-stage.
> 3. I publish my code and each API can be implemented in terms of the other 
> one. I'm not sure that this is possible in a simple way. Maybe each 
> protocol could be extended to java.lang.Object, which calls the protocols 
> of the other API, but I don't know if that is feasible.
>
> Please tell me what you think. I will also send Aysylu an email so that 
> she can chime in on the conversation.
>
>
> Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>>
>> Loom was indeed working on this, and it's a very nice library.  One thing 
>> that I particularly liked about Justin's design, was the ability to run a 
>> graph algorithm without worrying about conforming to a particular graph 
>> representation.  See for example the bread first search function, here:
>>
>> https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110
>>
>> All the bfs function requires is a neighbors function and and a start 
>> vertex.  Simple and easy to use.
>>
>> Justin had said that he won't be actively developing loom for the 
>> forseeable future; I was hoping to develop it further, but I only got as 
>> far as implementing a max flow algorithm before the rest of my life got 
>> in the way of my plans.  I know that Aysylu was doing a fair amount of work 
>> on loom, so I'd guess that her repo is the most advanced one.
>>
>> Stephen:
>> I think the set of protocols above is good, better than Loom's in fact; 
>> notably, the decision to make direct-predecessors optional is the correct 
>> one, and a lot of graph libraries get that wrong.  
>>
>> If you want to compare how loom did it:
>> https://github.com/jkk/loom/blob/master/src/loom/graph.clj
>>
>>
>>
>>
>>
>> On Monday, June 17, 2013 1:14:34 PM UTC-7, dgrnbrg wrote:
>>>
>>> I think that there's already a project working on this called Loom. The 
>>> furthest-developed fork is here: https://github.com/aysylu/loom which 
>>> appears to have protocols for graphs, bindings to Titanium (the 
>>

Re: Graph API

[Niels van Klaveren]

As a user of the old version of Loom (thanks for the link to aysylu's fork 
!)  it'd be great if there was a well maintained pure Clojure graph library.
The ideas and improvements on Loom you put forward are pretty sensible, and 
I hope you and Aysylu can find a way to collaborate !

On Tuesday, June 18, 2013 9:10:23 AM UTC+2, Stephen Kockentiedt wrote:
>
> My bad. I did only find the original repository of loom and thought it was 
> abandoned. I should have taken more care while looking at it. My approach 
> was apparently the same in abstracting multiple graph implementations under 
> one API. However, I see some problems with Loom's API, namely:
>
> 1. The specifications of the protocol functions are very sparse. E.g., 
> which nodes shall a directed graph return from neighbors? Successors, 
> predecessors or both?
> 2. How do I know if the graph implementation works by mutating the given 
> object or returning a new one?
> 3. Loom assumes that every graph is editable. That is definitely not the 
> case.
> 4. I think a protocol should be as easy to implement as possible. The 
> additional functionality can be given by functions relying on the protocol 
> functions. E.g., in the user API of my code, there is a function 
> direct-predecessors which provides this functionality (albeit slow) for 
> graph implementations which did not implement the corresponding protocol 
> function:
>
> (defn direct-predecessors
>   "Returns a set or sequence of all nodes n2 for which
>(has-edge? g n2 n) returns true. May not contain
>duplicates."
>   [g n]
>   (if (satisfies? p/PPredecessorGraph g)
> (p/direct-predecessors g n)
> (filter #(p/has-edge? g % n) (p/nodes g
>
> E.g., implementations of Loom's API need to provide two implementations of 
> neighbors and need to implement add-nodes* instead of only add-node*. 
> This may not be much more work to do. However, the easier the API, the more 
> implementations there will be.
>
> Please, don't get me wrong. I think that Loom is a great project, has the 
> same goals and, in terms of functionality, is way ahead of my efforts.
>
> Said all that, I definitely don't want there to be two competing graph 
> APIs. That would be counterproductive. I see the following possible 
> solutions:
>
> 1. I keep the code to myself and let loom be the sole graph API.
> 2. We transfer the advantages of my proposal to Loom and change its API. 
> Do you know of any implementations of the API outside Loom itself? If there 
> are none, this should be possible without much trouble. Also, the README 
> states that the API is alpha-stage.
> 3. I publish my code and each API can be implemented in terms of the other 
> one. I'm not sure that this is possible in a simple way. Maybe each 
> protocol could be extended to java.lang.Object, which calls the protocols 
> of the other API, but I don't know if that is feasible.
>
> Please tell me what you think. I will also send Aysylu an email so that 
> she can chime in on the conversation.
>
>
> Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>>
>> Loom was indeed working on this, and it's a very nice library.  One thing 
>> that I particularly liked about Justin's design, was the ability to run a 
>> graph algorithm without worrying about conforming to a particular graph 
>> representation.  See for example the bread first search function, here:
>>
>> https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110
>>
>> All the bfs function requires is a neighbors function and and a start 
>> vertex.  Simple and easy to use.
>>
>> Justin had said that he won't be actively developing loom for the 
>> forseeable future; I was hoping to develop it further, but I only got as 
>> far as implementing a max flow algorithm before the rest of my life got 
>> in the way of my plans.  I know that Aysylu was doing a fair amount of work 
>> on loom, so I'd guess that her repo is the most advanced one.
>>
>> Stephen:
>> I think the set of protocols above is good, better than Loom's in fact; 
>> notably, the decision to make direct-predecessors optional is the correct 
>> one, and a lot of graph libraries get that wrong.  
>>
>> If you want to compare how loom did it:
>> https://github.com/jkk/loom/blob/master/src/loom/graph.clj
>>
>>
>>
>>
>>
>> On Monday, June 17, 2013 1:14:34 PM UTC-7, dgrnbrg wrote:
>>>
>>> I think that there's already a project working on this called Loom. The 
>>> furthest-developed fork is here: https://github.com/aysylu/loom which 
>>>

Re: Graph API

[Stephen Kockentiedt]

My bad. I did only find the original repository of loom and thought it was 
abandoned. I should have taken more care while looking at it. My approach 
was apparently the same in abstracting multiple graph implementations under 
one API. However, I see some problems with Loom's API, namely:

1. The specifications of the protocol functions are very sparse. E.g., 
which nodes shall a directed graph return from neighbors? Successors, 
predecessors or both?
2. How do I know if the graph implementation works by mutating the given 
object or returning a new one?
3. Loom assumes that every graph is editable. That is definitely not the 
case.
4. I think a protocol should be as easy to implement as possible. The 
additional functionality can be given by functions relying on the protocol 
functions. E.g., in the user API of my code, there is a function 
direct-predecessors which provides this functionality (albeit slow) for 
graph implementations which did not implement the corresponding protocol 
function:

(defn direct-predecessors
  "Returns a set or sequence of all nodes n2 for which
   (has-edge? g n2 n) returns true. May not contain
   duplicates."
  [g n]
  (if (satisfies? p/PPredecessorGraph g)
(p/direct-predecessors g n)
(filter #(p/has-edge? g % n) (p/nodes g

E.g., implementations of Loom's API need to provide two implementations of 
neighbors and need to implement add-nodes* instead of only add-node*. This 
may not be much more work to do. However, the easier the API, the more 
implementations there will be.

Please, don't get me wrong. I think that Loom is a great project, has the 
same goals and, in terms of functionality, is way ahead of my efforts.

Said all that, I definitely don't want there to be two competing graph 
APIs. That would be counterproductive. I see the following possible 
solutions:

1. I keep the code to myself and let loom be the sole graph API.
2. We transfer the advantages of my proposal to Loom and change its API. Do 
you know of any implementations of the API outside Loom itself? If there 
are none, this should be possible without much trouble. Also, the README 
states that the API is alpha-stage.
3. I publish my code and each API can be implemented in terms of the other 
one. I'm not sure that this is possible in a simple way. Maybe each 
protocol could be extended to java.lang.Object, which calls the protocols 
of the other API, but I don't know if that is feasible.

Please tell me what you think. I will also send Aysylu an email so that she 
can chime in on the conversation.


Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:
>
> Loom was indeed working on this, and it's a very nice library.  One thing 
> that I particularly liked about Justin's design, was the ability to run a 
> graph algorithm without worrying about conforming to a particular graph 
> representation.  See for example the bread first search function, here:
>
> https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110
>
> All the bfs function requires is a neighbors function and and a start 
> vertex.  Simple and easy to use.
>
> Justin had said that he won't be actively developing loom for the 
> forseeable future; I was hoping to develop it further, but I only got as 
> far as implementing a max flow algorithm before the rest of my life got 
> in the way of my plans.  I know that Aysylu was doing a fair amount of work 
> on loom, so I'd guess that her repo is the most advanced one.
>
> Stephen:
> I think the set of protocols above is good, better than Loom's in fact; 
> notably, the decision to make direct-predecessors optional is the correct 
> one, and a lot of graph libraries get that wrong.  
>
> If you want to compare how loom did it:
> https://github.com/jkk/loom/blob/master/src/loom/graph.clj
>
>
>
>
>
> On Monday, June 17, 2013 1:14:34 PM UTC-7, dgrnbrg wrote:
>>
>> I think that there's already a project working on this called Loom. The 
>> furthest-developed fork is here: https://github.com/aysylu/loom which 
>> appears to have protocols for graphs, bindings to Titanium (the 
>> Clojurewerkz graph DB library), visualization support, and implementations 
>> of several algorithms.
>>
>> Maybe there's a way to incorporate these projects?
>>
>> On Monday, June 17, 2013 3:38:45 PM UTC-4, Stephen Kockentiedt wrote:
>>>
>>> Hello,
>>>
>>> I want to create a graph API similar to what core.matrix is for 
>>> matrices. I have created some protocols which every graph implementation 
>>> has to satisfy and a prototype implementation. Now I want your feedback on 
>>> these protocols. Which functions do you want to see which aren't there? 
>>> Which functions should be 

Re: Graph API

[Rob Lachlan]

Loom was indeed working on this, and it's a very nice library.  One thing 
that I particularly liked about Justin's design, was the ability to run a 
graph algorithm without worrying about conforming to a particular graph 
representation.  See for example the bread first search function, here:

https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110

All the bfs function requires is a neighbors function and and a start 
vertex.  Simple and easy to use.

Justin had said that he won't be actively developing loom for the 
forseeable future; I was hoping to develop it further, but I only got as 
far as implementing a max flow algorithm before the rest of my life got in 
the way of my plans.  I know that Aysylu was doing a fair amount of work on 
loom, so I'd guess that her repo is the most advanced one.

Stephen:
I think the set of protocols above is good, better than Loom's in fact; 
notably, the decision to make direct-predecessors optional is the correct 
one, and a lot of graph libraries get that wrong.  

If you want to compare how loom did it:
https://github.com/jkk/loom/blob/master/src/loom/graph.clj





On Monday, June 17, 2013 1:14:34 PM UTC-7, dgrnbrg wrote:
>
> I think that there's already a project working on this called Loom. The 
> furthest-developed fork is here: https://github.com/aysylu/loom which 
> appears to have protocols for graphs, bindings to Titanium (the 
> Clojurewerkz graph DB library), visualization support, and implementations 
> of several algorithms.
>
> Maybe there's a way to incorporate these projects?
>
> On Monday, June 17, 2013 3:38:45 PM UTC-4, Stephen Kockentiedt wrote:
>>
>> Hello,
>>
>> I want to create a graph API similar to what core.matrix is for matrices. 
>> I have created some protocols which every graph implementation has to 
>> satisfy and a prototype implementation. Now I want your feedback on these 
>> protocols. Which functions do you want to see which aren't there? Which 
>> functions should be changed? Are there problems with the general design? 
>> Have you any other feedback?
>>
>> Here are the protocol definitions:
>>
>> (defprotocol PGraph
>>   "Minimal functionality of a graph."
>>   (directed? [g]
>> "Returns true if the graph is directed and false if the
>>  graph is undirected. If it is undirected, all functions
>>  taking two nodes must be commutative with regard to
>>  these nodes.")
>>   (nodes [g]
>> "Returns a set or sequence of all nodes of the graph. May
>>  not contain duplicates.")
>>   (has-edge? [g n1 n2]
>> "Returns true if the graph g has an edge from node n1
>>  to node n2.")
>>   (direct-successors [g n]
>> "Returns a set or sequence of all nodes n2 for which
>>  (has-edge? g n n2) returns true. May not contain
>>  duplicates."))
>>
>> (defprotocol PPredecessorGraph
>>   "Optional functionality of a graph which can give a
>>list of all direct predecessors of a node."
>>   (direct-predecessors [g n]
>> "Returns a set or sequence of all nodes n2 for which
>>  (has-edge? g n2 n) returns true. May not contain
>>  duplicates."))
>>
>> (defprotocol PEditableGraph
>>   "Minimal functionality of an editable graph."
>>   (mutable? [g]
>> "Returns true if the graph is mutated in place.
>>  If true is returned, the other functions change
>>  the graph passed as the first argument and return
>>  the same graph object. If false is returned, the
>>  functions return a new graph and the old graph is
>>  unchaged.")
>>   (add-node [g n]
>> "Adds the node n to the graph g. If it already
>>  contained n, the graph will not be changed.")
>>   (remove-node [g n]
>> "Removes the node n from the graph g. If it did
>>  not contain n, the graph will not be changed.")
>>   (add-edge [g n1 n2]
>> "Adds an edge from node n1 to node n2 to the graph g.
>>  If one or both of the nodes is not present it will
>>  be added to the graph. If the edge was already present,
>>  the graph will not be changed.")
>>   (remove-edge [g n1 n2]
>> "Removes the edge from node n1 to the node n2 from
>>  the graph g. If it did not contain the edge, the graph
>>  will not be changed."))
>>
>> (defprotocol PWeightedGraph
>>   "Functionality of a graph whose edges can be weighted."
>>   (edge-weight [g n1 n2]
>> "Returns the wei

Re: Graph API

[Zack Maril]

Take a look at Tinkerpop's blueprints for a well tested Java API and 
Archimedes for simple graph operations in Clojure. 
http://www.tinkerpop.com/
https://github.com/clojurewerkz/archimedes

As far as the suggested protocols go, I would suggest doing something 
useful with them before opening it up to the community for comments. 
There's not much there to discuss in terms of merits or anything else. 
-Zack

On Monday, June 17, 2013 4:14:34 PM UTC-4, dgrnbrg wrote:
>
> I think that there's already a project working on this called Loom. The 
> furthest-developed fork is here: https://github.com/aysylu/loom which 
> appears to have protocols for graphs, bindings to Titanium (the 
> Clojurewerkz graph DB library), visualization support, and implementations 
> of several algorithms.
>
> Maybe there's a way to incorporate these projects?
>
> On Monday, June 17, 2013 3:38:45 PM UTC-4, Stephen Kockentiedt wrote:
>>
>> Hello,
>>
>> I want to create a graph API similar to what core.matrix is for matrices. 
>> I have created some protocols which every graph implementation has to 
>> satisfy and a prototype implementation. Now I want your feedback on these 
>> protocols. Which functions do you want to see which aren't there? Which 
>> functions should be changed? Are there problems with the general design? 
>> Have you any other feedback?
>>
>> Here are the protocol definitions:
>>
>> (defprotocol PGraph
>>   "Minimal functionality of a graph."
>>   (directed? [g]
>> "Returns true if the graph is directed and false if the
>>  graph is undirected. If it is undirected, all functions
>>  taking two nodes must be commutative with regard to
>>  these nodes.")
>>   (nodes [g]
>> "Returns a set or sequence of all nodes of the graph. May
>>  not contain duplicates.")
>>   (has-edge? [g n1 n2]
>> "Returns true if the graph g has an edge from node n1
>>  to node n2.")
>>   (direct-successors [g n]
>> "Returns a set or sequence of all nodes n2 for which
>>  (has-edge? g n n2) returns true. May not contain
>>  duplicates."))
>>
>> (defprotocol PPredecessorGraph
>>   "Optional functionality of a graph which can give a
>>list of all direct predecessors of a node."
>>   (direct-predecessors [g n]
>> "Returns a set or sequence of all nodes n2 for which
>>  (has-edge? g n2 n) returns true. May not contain
>>  duplicates."))
>>
>> (defprotocol PEditableGraph
>>   "Minimal functionality of an editable graph."
>>   (mutable? [g]
>> "Returns true if the graph is mutated in place.
>>  If true is returned, the other functions change
>>  the graph passed as the first argument and return
>>  the same graph object. If false is returned, the
>>  functions return a new graph and the old graph is
>>  unchaged.")
>>   (add-node [g n]
>> "Adds the node n to the graph g. If it already
>>  contained n, the graph will not be changed.")
>>   (remove-node [g n]
>> "Removes the node n from the graph g. If it did
>>  not contain n, the graph will not be changed.")
>>   (add-edge [g n1 n2]
>> "Adds an edge from node n1 to node n2 to the graph g.
>>  If one or both of the nodes is not present it will
>>  be added to the graph. If the edge was already present,
>>  the graph will not be changed.")
>>   (remove-edge [g n1 n2]
>> "Removes the edge from node n1 to the node n2 from
>>  the graph g. If it did not contain the edge, the graph
>>  will not be changed."))
>>
>> (defprotocol PWeightedGraph
>>   "Functionality of a graph whose edges can be weighted."
>>   (edge-weight [g n1 n2]
>> "Returns the weight of the edge from node n1 to
>>  node n2."))
>>
>> (defprotocol PEditableWeightedGraph
>>   "Functionality of a weighted graph whose weights can be
>>changed."
>>   (update-edge-weight [g n1 n2 f]
>> "Updates the weight of the edge from node n1 to node n2,
>>  where f is a function taking the old value and returning
>>  the new one. If the graph did not contain the edge, it
>>  will be created."))
>>
>> (defprotocol PNodeDataGraph
>>   "Functionality of a graph which stores data with its
>>nodes."
>>   (node-data [g n]
>> "Returns the data of the node n."))
>>

Re: Graph API

[dgrnbrg]

I think that there's already a project working on this called Loom. The 
furthest-developed fork is here: https://github.com/aysylu/loom which 
appears to have protocols for graphs, bindings to Titanium (the 
Clojurewerkz graph DB library), visualization support, and implementations 
of several algorithms.

Maybe there's a way to incorporate these projects?

On Monday, June 17, 2013 3:38:45 PM UTC-4, Stephen Kockentiedt wrote:
>
> Hello,
>
> I want to create a graph API similar to what core.matrix is for matrices. 
> I have created some protocols which every graph implementation has to 
> satisfy and a prototype implementation. Now I want your feedback on these 
> protocols. Which functions do you want to see which aren't there? Which 
> functions should be changed? Are there problems with the general design? 
> Have you any other feedback?
>
> Here are the protocol definitions:
>
> (defprotocol PGraph
>   "Minimal functionality of a graph."
>   (directed? [g]
> "Returns true if the graph is directed and false if the
>  graph is undirected. If it is undirected, all functions
>  taking two nodes must be commutative with regard to
>  these nodes.")
>   (nodes [g]
> "Returns a set or sequence of all nodes of the graph. May
>  not contain duplicates.")
>   (has-edge? [g n1 n2]
> "Returns true if the graph g has an edge from node n1
>  to node n2.")
>   (direct-successors [g n]
> "Returns a set or sequence of all nodes n2 for which
>  (has-edge? g n n2) returns true. May not contain
>  duplicates."))
>
> (defprotocol PPredecessorGraph
>   "Optional functionality of a graph which can give a
>list of all direct predecessors of a node."
>   (direct-predecessors [g n]
> "Returns a set or sequence of all nodes n2 for which
>  (has-edge? g n2 n) returns true. May not contain
>  duplicates."))
>
> (defprotocol PEditableGraph
>   "Minimal functionality of an editable graph."
>   (mutable? [g]
> "Returns true if the graph is mutated in place.
>  If true is returned, the other functions change
>  the graph passed as the first argument and return
>  the same graph object. If false is returned, the
>  functions return a new graph and the old graph is
>  unchaged.")
>   (add-node [g n]
> "Adds the node n to the graph g. If it already
>  contained n, the graph will not be changed.")
>   (remove-node [g n]
> "Removes the node n from the graph g. If it did
>  not contain n, the graph will not be changed.")
>   (add-edge [g n1 n2]
> "Adds an edge from node n1 to node n2 to the graph g.
>  If one or both of the nodes is not present it will
>  be added to the graph. If the edge was already present,
>  the graph will not be changed.")
>   (remove-edge [g n1 n2]
> "Removes the edge from node n1 to the node n2 from
>  the graph g. If it did not contain the edge, the graph
>  will not be changed."))
>
> (defprotocol PWeightedGraph
>   "Functionality of a graph whose edges can be weighted."
>   (edge-weight [g n1 n2]
> "Returns the weight of the edge from node n1 to
>  node n2."))
>
> (defprotocol PEditableWeightedGraph
>   "Functionality of a weighted graph whose weights can be
>changed."
>   (update-edge-weight [g n1 n2 f]
> "Updates the weight of the edge from node n1 to node n2,
>  where f is a function taking the old value and returning
>  the new one. If the graph did not contain the edge, it
>  will be created."))
>
> (defprotocol PNodeDataGraph
>   "Functionality of a graph which stores data with its
>nodes."
>   (node-data [g n]
> "Returns the data of the node n."))
>
> (defprotocol PEditableNodeDataGraph
>   "Functionality of a graph which stores editable data
>with its nodes."
>   (update-node-data [g n f]
> "Updates the data of the node n, where f is a function
>  taking the old value and returning the new one. If the
>  graph did not contain the node, it will be added."))
>
> (defprotocol PEdgeDataGraph
>   "Functionality of a graph which stores data with its edges."
>   (edge-data [g n1 n2]
> "Returns the data of the edge from node n1 to node n2."))
>
> (defprotocol PEditableEdgeDataGraph
>   "Functionality of a graph which stores editable data
>with its edges."
>   (update-edge-data [g n1 n2 f]
> "Changes the data of the edge from node n1 to n2, where
>  f is a func

Graph API

[Stephen Kockentiedt]

Hello,

I want to create a graph API similar to what core.matrix is for matrices. I 
have created some protocols which every graph implementation has to satisfy 
and a prototype implementation. Now I want your feedback on these 
protocols. Which functions do you want to see which aren't there? Which 
functions should be changed? Are there problems with the general design? 
Have you any other feedback?

Here are the protocol definitions:

(defprotocol PGraph
  "Minimal functionality of a graph."
  (directed? [g]
"Returns true if the graph is directed and false if the
 graph is undirected. If it is undirected, all functions
 taking two nodes must be commutative with regard to
 these nodes.")
  (nodes [g]
"Returns a set or sequence of all nodes of the graph. May
 not contain duplicates.")
  (has-edge? [g n1 n2]
"Returns true if the graph g has an edge from node n1
 to node n2.")
  (direct-successors [g n]
"Returns a set or sequence of all nodes n2 for which
 (has-edge? g n n2) returns true. May not contain
 duplicates."))

(defprotocol PPredecessorGraph
  "Optional functionality of a graph which can give a
   list of all direct predecessors of a node."
  (direct-predecessors [g n]
"Returns a set or sequence of all nodes n2 for which
 (has-edge? g n2 n) returns true. May not contain
 duplicates."))

(defprotocol PEditableGraph
  "Minimal functionality of an editable graph."
  (mutable? [g]
"Returns true if the graph is mutated in place.
 If true is returned, the other functions change
 the graph passed as the first argument and return
 the same graph object. If false is returned, the
 functions return a new graph and the old graph is
 unchaged.")
  (add-node [g n]
"Adds the node n to the graph g. If it already
 contained n, the graph will not be changed.")
  (remove-node [g n]
"Removes the node n from the graph g. If it did
 not contain n, the graph will not be changed.")
  (add-edge [g n1 n2]
"Adds an edge from node n1 to node n2 to the graph g.
 If one or both of the nodes is not present it will
 be added to the graph. If the edge was already present,
 the graph will not be changed.")
  (remove-edge [g n1 n2]
"Removes the edge from node n1 to the node n2 from
 the graph g. If it did not contain the edge, the graph
 will not be changed."))

(defprotocol PWeightedGraph
  "Functionality of a graph whose edges can be weighted."
  (edge-weight [g n1 n2]
"Returns the weight of the edge from node n1 to
 node n2."))

(defprotocol PEditableWeightedGraph
  "Functionality of a weighted graph whose weights can be
   changed."
  (update-edge-weight [g n1 n2 f]
"Updates the weight of the edge from node n1 to node n2,
 where f is a function taking the old value and returning
 the new one. If the graph did not contain the edge, it
 will be created."))

(defprotocol PNodeDataGraph
  "Functionality of a graph which stores data with its
   nodes."
  (node-data [g n]
"Returns the data of the node n."))

(defprotocol PEditableNodeDataGraph
  "Functionality of a graph which stores editable data
   with its nodes."
  (update-node-data [g n f]
"Updates the data of the node n, where f is a function
 taking the old value and returning the new one. If the
 graph did not contain the node, it will be added."))

(defprotocol PEdgeDataGraph
  "Functionality of a graph which stores data with its edges."
  (edge-data [g n1 n2]
"Returns the data of the edge from node n1 to node n2."))

(defprotocol PEditableEdgeDataGraph
  "Functionality of a graph which stores editable data
   with its edges."
  (update-edge-data [g n1 n2 f]
"Changes the data of the edge from node n1 to n2, where
 f is a function taking the old value and returning the
 new one. If the graph did not contain the edge, it will
 be added."))

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Bojan Jovičić]

Dear Max,
thank you very much for explanation :)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Max Weber]

Hi Bojan,

there has been a global change within the Facebook Graph API, it
doesn't sent a referer in the headers of the authentication callback
request anymore.
A middleware function of clj-facebook-graph has relied upon this
referer. I have fixed this issue in version 0.1.3-SNAPSHOT, but now
you have to pay attention that you specify the correct :redirect-uri
in your clj-facebook-graph facebook-app-info map, otherwise the
changed middleware will not be able to detect that a request is a
callback request of the facebook authentication flow or just an
ordinary request with a code query parameter. I have to release a
version 0.1.3 soon. Nevertheless the version on GitHub also supports
FQL queries now.

Cheers,

Max

On 6 Jun., 07:52, Bojan Jovičić  wrote:
> I got latest version of your framework from Github and it works OK.
>
> I am not sure if this is related to new settings in Facebook App page (I put
> most of them to Disabled now) or some global change.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Bojan Jovičić]

I got latest version of your framework from Github and it works OK. 

I am not sure if this is related to new settings in Facebook App page (I put 
most of them to Disabled now) or some global change. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Bojan Jovičić]

Dear Max,
have there been some changes around Facebook authentication, because now it 
seems as token that is returned is not valid?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Bojan Jovičić]

Dear Max,
this works like a charm.

Thank you very much for real fast response.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Max Weber]

Hi Bojan,

I've added a basic support to post something against the Facebook
Graph API. The documentation for this new feature can be found under
https://github.com/maxweber/clj-facebook-graph

Best regards

Max

On 9 Mai, 20:22, Bojan Jovičić  wrote:
> Hi Max,
> I have started investigating this, and it works very nice.
>
> I am a noob in Clojure/Java and I have a question about posting to FB using
> your library. I tried something like this:
>
> *(def auth-token (facebook-auth-by-name))
> (def auth-name (first (keys auth-token)))
> (with-facebook-auth-by-name auth-name (fb-get [:me :feed (str "message="
> "test")]))
> *
> But it seems not to work for processing parameters. The documentation for
> posting to FB is 
> here<http://developers.facebook.com/docs/reference/api/post/>(bottom of the 
> page).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Bojan Jovičić]

Hi Max,
I have started investigating this, and it works very nice. 

I am a noob in Clojure/Java and I have a question about posting to FB using 
your library. I tried something like this:

*(def auth-token (facebook-auth-by-name))
(def auth-name (first (keys auth-token)))
(with-facebook-auth-by-name auth-name (fb-get [:me :feed (str "message=" 
"test")]))
*
But it seems not to work for processing parameters. The documentation for 
posting to FB is 
here(bottom of the 
page).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Alfredo]

Hi Max,
I'm already using your library for a university project, and it's very
well written.
Good job!

Best,
Alfredo

On Apr 8, 12:16 pm, Max Weber  wrote:
> Hello everyone,
>
> I like to introduce you to clj-facebook-graph, it is a Clojure client
> for the Facebook Graph API and it is based on clj-http and Ring. I
> have written a blog post about how to leverage clj-facebook-graph to
> query the Facebook Graph API:
>
> http://max-weber.tumblr.com/post/4183433816/clj-facebook-graph
>
> The library is open source and it is hosted on GitHub (https://
> github.com/maxweber/clj-facebook-graph).
>
> Best regards
>
> Max

-- 
You 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

ANN: A Clojure library for the Facebook Graph API - clj-facebook-graph

[Max Weber]

Hello everyone,

I like to introduce you to clj-facebook-graph, it is a Clojure client
for the Facebook Graph API and it is based on clj-http and Ring. I
have written a blog post about how to leverage clj-facebook-graph to
query the Facebook Graph API:

http://max-weber.tumblr.com/post/4183433816/clj-facebook-graph

The library is open source and it is hosted on GitHub (https://
github.com/maxweber/clj-facebook-graph).

Best regards

Max

-- 
You 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