Re: go-circuit for clojure

[gamma235]

I get the feeling that Cognitect has about  four or five secret projects 
that they are going to unleash on the world, a ridonculously distributed 
asynchronous  networking system being one of them. Datomic is kind of a 
step in that direction, is it not?

-- 
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: go-circuit for clojure

[François Rey]

On 10/05/14 22:59, Michał T. Lorenc wrote:
Since, core.async has goroutines maybe it would be possible to 
implement go-circuit 
 
for clojure to distrubute goroutines across computer nodes?
In a previous topic 
 about 
core.async over websocket + cljs + clojure was an argument 
 that 
sticks in my mind: trying to make distribution of processing 
transparent, ie look as local CSP using the same api as core.async, is 
probably not a good idea, since there may be semantic differences that 
may not be easy to resolve, e.g. blocking semantics, latency, and 
failure modes could be awkward to retrofit into an api designed for 
local CSP processing. A related concept is the one of leaky abstraction 
, whereby the things 
below that have been abstracted (sort of made invisible) find a way to 
become painfully visible at the level above. This is not saying that 
it's impossible, it just requires a very careful design to avoid 
leakiness and complection. This isn't a new idea by the way, and if 
anyone would like to go that way, she/he should start by reading this 
paper 
 
that concludes as follows:


   /A better approach is to accept that there are
   irreconcilabledifferences between local and distributed
   computing, andto be conscious of those differences at all stages
   of the //design and implementation of distributed
   applications.Rather than trying to merge local and remote
   objects, engi//neers need to be constantly reminded of the
   differencesbetween the two, and know when it is appropriate to
   use //each kind of object./

Anyway, I'm no specialist here but I thought this would be good 
references to start with.


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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] tools.analyzer(.jvm) 0.1.0-alpha1

[Gregg Reynolds]

On Friday, January 10, 2014 7:23:56 PM UTC-6, Nicola Mometto wrote:
>
>
> Today I released the first version of the tools.analyzer[1] and 
> tools.analyzer.jvm[2] contrib libraries, here are the leiningen 
> coordinates: 
>
> [org.clojure/tools.analyzer "0.1.0-alpha1"] 
> [org.clojure/tools.analyzer.jvm "0.1.0-alpha1"] 
>
> Right now the only documentation for both those libraries is in the form 
> of docstrings and can be found at 
> http://clojure.github.io/tools.analyzer/ and 
> http://clojure.github.io/tools.analyzer.jvm/ more extended documentation 
> will be available before the first non-alpha release, hopefully very soon. 
>

Hi,

I've begun experimenting with this and I wonder if there is any further 
documentation or more extensive examples.  So far I'm just trying to use 
walk, prewalk, postwalk to crawl an AST, but I think I must be doing 
something wrong.  Using analyze on something like "(do (def a 1) (def b 
2))" I would expect four leaf nodes, a, 1, b, and 2, but using postwalk I 
bottom out on the whole subexpressions (def a 1) and (def b 2).  Also, 
location data (file, col, line) appears to not be subordinate to the node 
it describes, so I must be misinterpreting something.

I want to do the basic DOM -like stuff like get-parent, get-first-child, 
etc., but dumping a node produces a vast amount of data whose structure 
isn't really clear to me.  I can access :children, which is a vector, but I 
don't see how to descend in the tree.

Thanks for any help,

Gregg


-- 
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] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Alan Moore]

It would be interesting to compare rete4frames with clara-rules and maybe 
some other clojure-based RETE implementation.

Having spent some time with Clara and only looked over rete4frames it is 
clear that Clara has been heavily optimized for working with 
collections/accumulators.

Especially interesting is that Clara is built using protocols for key RETE 
components, e.g. working memory, transport, etc. This has been demonstrated 
to implement Storm clusters/topologies doing distributed hash-based joins 
that leverage Clara's immutability... See:

https://github.com/rbrush/clara-storm

Your rete4frames provides a good example of the power of the RETE 
algorithm. Also, in both rete4frames and Clara, I was surprised at the 
small size of the code as compared to the Drools/Jess/CLIPS code bases. 
This compactness is due in large measure to the host language being 
Clojure. :-)

Take care.

Alan


On Monday, May 12, 2014 8:58:33 PM UTC-7, ru wrote:
>
> Before creating own rete implementation I have used in my applications 
> Drools for several years. Drools is becoming more and more complex and in 
> the end ceased to support my applications. I decided to create my own 
> implementation as simple as possible to have a full control and quick 
> search in case of an error in application. As I understand from quick look 
> Clara rete implementation is a similar to Drools.  It is intresting to 
> compare Clara, Drools and rete4frames on traditional benchmarks such as 
> Mrs.Manners and Waltz algorithm. I tried to compare my implementation with 
> Drools, but Manners example of Drools in the last version I looked at was 
> brocken. I wrote to Mark Proctor about this and he promised to fix this but 
> I did not look at that ever since.. :( Hope I will find time to accomplish 
> this comparison.
>
> понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:
>>
>> New feature: added Java interface. Eclipse project example.
>>
>> Home: https://github.com/rururu/rete4frames
>>
>> Have fun!
>>
>> Sincerely,
>>   Ru
>>
>

-- 
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: Expected inconsistency between set and map w/ ArrayList?

[Mike Fikes]

To facilitate inlining, the patch calls out to a separate larger method 
which handles a group of cases.

+if(o.getClass().getName().startsWith("java.util."))
+return doalienhasheq(o);
+return o.hashCode();


I was wondering whether an efficient improvement is possible that would support 
things like Guava ImmutableList.


In particular, I was wonder which "default" cases are currently handled by the 
return o.hashCode() above. Replacing the three lines above with 


+return doalienhasheq(o);


would allow the patch to also handle non-java.util collection implementations, 
but push the "default" cases down into the bottom of that method.


On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:
>
> I've posted a patch that makes java.util.{List,Map,Map.Entry,Set} 
> hashes consistent with those of appropriate Clojure collection types 
> on the ticket. 
>

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

Best method for REST api authentication?

[Ivan Schuetz]

Hi,

I'm new to Clojure and have little experience with api development. I'm 
looking for a way to implement REST api authentication. As far I 
understand, the best way to do this is using an authentication token. The 
goal is use this for mobile apps.

I would prefer to avoid sending the login data in each request, since this 
would mean I have to store the password in the app. This is unwanted.


I have looked in the available options for authentication in Clojure, but 
no one seems to provide a complete method to do this. I started with Friend 
- thanks to help I got in this 
thread I 
was able to implement a service to login a user via JSON. I see the 
credentials function returns me an identity id - which so far I understand, 
is what the client would use to identify subsequent requests. I printed 
this identity, it looks like this:

{:cemerick.friend/identity {:current user1, :authentications {user1 
{:identity user1, :username user1

I assume I can provide a custom function to generate a token instead and 
insert it in the headers of the response...

Now I need to insert this in subsequent requests and check it using a new 
middleware? I came across this 
one which 
would do this. Probably, since I'm using Friend, I could implement it as a 
workflow instead, which checks the headers, and if the token is correct 
passes control to the handler, otherwise returns an error (via JSON).


This just looks very cumbersome to me and I wonder if I'm missing the 
"correct way" to do it, or isn't there a complete solution for REST 
authentication yet...? Also some things missing about my solution, like the 
TTL of this token, how I generate it, security aspects, etc...

I would appreciate pointing me in the right direction, how this is 
typically done in Clojure, etc.


Thanks in advance!

-- 
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: Expected inconsistency between set and map w/ ArrayList?

[Michał Marczyk]

It's not just to facilitate inlining, but also to limit the perf hit
for hashing non-collections, some of which make completely reasonable
map keys and set members. I've used the classes Alex Miller mentioned
he was interested in for benchmarking: Class, Character, Var; these
are all good examples, and only one is under Clojure's control.

I used a "map or map entry or collection" test in earlier versions of
the patch, but switched to the class name hack because the three-way
type check seems to slow down getting to the default case much more
than examining the class name. For types that actually implement
IHashEq, however, the original patch was faster, so I think HotSpot is
happy to inline either version.


On 13 May 2014 14:00, Mike Fikes  wrote:
> To facilitate inlining, the patch calls out to a separate larger method
> which handles a group of cases.
>
> +if(o.getClass().getName().startsWith("java.util."))
> +return doalienhasheq(o);
> +return o.hashCode();
>
>
> I was wondering whether an efficient improvement is possible that would
> support things like Guava ImmutableList.
>
>
> In particular, I was wonder which "default" cases are currently handled by
> the return o.hashCode() above. Replacing the three lines above with
>
>
> +return doalienhasheq(o);
>
>
> would allow the patch to also handle non-java.util collection
> implementations, but push the "default" cases down into the bottom of that
> method.
>
>
> On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:
>>
>> I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
>> hashes consistent with those of appropriate Clojure collection types
>> on the ticket.
>
> --
> 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: Expected inconsistency between set and map w/ ArrayList?

[Michał Marczyk]

Also, = defers to equals in all cases except two: (1) numeric
arguments, (2) at least one IPersistentCollection among the arguments.

Clojure collections are allowed to determine whether they are = to the
other thing or not. So, we should calculate special hashCodes for the
java.util collections Clojure collections know about.

Other collection types will just use equals for comparisons and so for
them we have to return hashCode to preserve =/hash semantics by
relying on the equals/hashCode contract -- there is nothing else we
can do. Well, strictly speaking we could apply an arbitrary function
to hashCode, so murmuring it (as with Strings) is an option; that
would come at a performance cost, however (I benchmarked a version
that did that), and I don't think there'd be much benefit -- certainly
none at all for classes using identity hash codes.

Cheers,
Michał


On 13 May 2014 14:20, Michał Marczyk  wrote:
> It's not just to facilitate inlining, but also to limit the perf hit
> for hashing non-collections, some of which make completely reasonable
> map keys and set members. I've used the classes Alex Miller mentioned
> he was interested in for benchmarking: Class, Character, Var; these
> are all good examples, and only one is under Clojure's control.
>
> I used a "map or map entry or collection" test in earlier versions of
> the patch, but switched to the class name hack because the three-way
> type check seems to slow down getting to the default case much more
> than examining the class name. For types that actually implement
> IHashEq, however, the original patch was faster, so I think HotSpot is
> happy to inline either version.
>
>
> On 13 May 2014 14:00, Mike Fikes  wrote:
>> To facilitate inlining, the patch calls out to a separate larger method
>> which handles a group of cases.
>>
>> +if(o.getClass().getName().startsWith("java.util."))
>> +return doalienhasheq(o);
>> +return o.hashCode();
>>
>>
>> I was wondering whether an efficient improvement is possible that would
>> support things like Guava ImmutableList.
>>
>>
>> In particular, I was wonder which "default" cases are currently handled by
>> the return o.hashCode() above. Replacing the three lines above with
>>
>>
>> +return doalienhasheq(o);
>>
>>
>> would allow the patch to also handle non-java.util collection
>> implementations, but push the "default" cases down into the bottom of that
>> method.
>>
>>
>> On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:
>>>
>>> I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
>>> hashes consistent with those of appropriate Clojure collection types
>>> on the ticket.
>>
>> --
>> 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: Expected inconsistency between set and map w/ ArrayList?

[Michał Marczyk]

Unfortunately the Guava example means that this approach doesn't
really solve the problem at hand... Thanks for pointing it out.

The earlier version with the three-way test in place of the
"java.util." check should be semantically correct, at least.


On 13 May 2014 14:40, Michał Marczyk  wrote:
> Also, = defers to equals in all cases except two: (1) numeric
> arguments, (2) at least one IPersistentCollection among the arguments.
>
> Clojure collections are allowed to determine whether they are = to the
> other thing or not. So, we should calculate special hashCodes for the
> java.util collections Clojure collections know about.
>
> Other collection types will just use equals for comparisons and so for
> them we have to return hashCode to preserve =/hash semantics by
> relying on the equals/hashCode contract -- there is nothing else we
> can do. Well, strictly speaking we could apply an arbitrary function
> to hashCode, so murmuring it (as with Strings) is an option; that
> would come at a performance cost, however (I benchmarked a version
> that did that), and I don't think there'd be much benefit -- certainly
> none at all for classes using identity hash codes.
>
> Cheers,
> Michał
>
>
> On 13 May 2014 14:20, Michał Marczyk  wrote:
>> It's not just to facilitate inlining, but also to limit the perf hit
>> for hashing non-collections, some of which make completely reasonable
>> map keys and set members. I've used the classes Alex Miller mentioned
>> he was interested in for benchmarking: Class, Character, Var; these
>> are all good examples, and only one is under Clojure's control.
>>
>> I used a "map or map entry or collection" test in earlier versions of
>> the patch, but switched to the class name hack because the three-way
>> type check seems to slow down getting to the default case much more
>> than examining the class name. For types that actually implement
>> IHashEq, however, the original patch was faster, so I think HotSpot is
>> happy to inline either version.
>>
>>
>> On 13 May 2014 14:00, Mike Fikes  wrote:
>>> To facilitate inlining, the patch calls out to a separate larger method
>>> which handles a group of cases.
>>>
>>> +if(o.getClass().getName().startsWith("java.util."))
>>> +return doalienhasheq(o);
>>> +return o.hashCode();
>>>
>>>
>>> I was wondering whether an efficient improvement is possible that would
>>> support things like Guava ImmutableList.
>>>
>>>
>>> In particular, I was wonder which "default" cases are currently handled by
>>> the return o.hashCode() above. Replacing the three lines above with
>>>
>>>
>>> +return doalienhasheq(o);
>>>
>>>
>>> would allow the patch to also handle non-java.util collection
>>> implementations, but push the "default" cases down into the bottom of that
>>> method.
>>>
>>>
>>> On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:

 I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
 hashes consistent with those of appropriate Clojure collection types
 on the ticket.
>>>
>>> --
>>> 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.

ANN Langohr 2.10.1 is released

[Michael Klishin]

Langohr [1] is a small, feature complete Clojure client for RabbitMQ.

Release notes:
http://blog.clojurewerkz.org/blog/2014/05/13/langohr-2-dot-10-dot-1-is-released/

1. http://clojurerabbitmq.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: Expected inconsistency between set and map w/ ArrayList?

[Michał Marczyk]

New patch reinstates the three-way check, but puts it in a separate
static method. Performance seems to be just fine.

I wonder if my previous round of benchmarking with the inline
three-way check was somehow flawed... Either that or the JIT is
happier with the new arrangement for some reason. In any case I kind
of like the separate isAlien.


On 13 May 2014 14:47, Michał Marczyk  wrote:
> Unfortunately the Guava example means that this approach doesn't
> really solve the problem at hand... Thanks for pointing it out.
>
> The earlier version with the three-way test in place of the
> "java.util." check should be semantically correct, at least.
>
>
> On 13 May 2014 14:40, Michał Marczyk  wrote:
>> Also, = defers to equals in all cases except two: (1) numeric
>> arguments, (2) at least one IPersistentCollection among the arguments.
>>
>> Clojure collections are allowed to determine whether they are = to the
>> other thing or not. So, we should calculate special hashCodes for the
>> java.util collections Clojure collections know about.
>>
>> Other collection types will just use equals for comparisons and so for
>> them we have to return hashCode to preserve =/hash semantics by
>> relying on the equals/hashCode contract -- there is nothing else we
>> can do. Well, strictly speaking we could apply an arbitrary function
>> to hashCode, so murmuring it (as with Strings) is an option; that
>> would come at a performance cost, however (I benchmarked a version
>> that did that), and I don't think there'd be much benefit -- certainly
>> none at all for classes using identity hash codes.
>>
>> Cheers,
>> Michał
>>
>>
>> On 13 May 2014 14:20, Michał Marczyk  wrote:
>>> It's not just to facilitate inlining, but also to limit the perf hit
>>> for hashing non-collections, some of which make completely reasonable
>>> map keys and set members. I've used the classes Alex Miller mentioned
>>> he was interested in for benchmarking: Class, Character, Var; these
>>> are all good examples, and only one is under Clojure's control.
>>>
>>> I used a "map or map entry or collection" test in earlier versions of
>>> the patch, but switched to the class name hack because the three-way
>>> type check seems to slow down getting to the default case much more
>>> than examining the class name. For types that actually implement
>>> IHashEq, however, the original patch was faster, so I think HotSpot is
>>> happy to inline either version.
>>>
>>>
>>> On 13 May 2014 14:00, Mike Fikes  wrote:
 To facilitate inlining, the patch calls out to a separate larger method
 which handles a group of cases.

 +if(o.getClass().getName().startsWith("java.util."))
 +return doalienhasheq(o);
 +return o.hashCode();


 I was wondering whether an efficient improvement is possible that would
 support things like Guava ImmutableList.


 In particular, I was wonder which "default" cases are currently handled by
 the return o.hashCode() above. Replacing the three lines above with


 +return doalienhasheq(o);


 would allow the patch to also handle non-java.util collection
 implementations, but push the "default" cases down into the bottom of that
 method.


 On Tuesday, May 13, 2014 12:38:54 AM UTC-4, Michał Marczyk wrote:
>
> I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
> hashes consistent with those of appropriate Clojure collection types
> on the ticket.

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

Re: [ANN] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[ru]

Alan. You absolutely right! Clojure must return thinking of programmers 
back to solving problems from vanity and narcissism of unnecessary 
complexity :) I certainly will look on Clara more attentively and may be 
switch to it in my applications.

cheers,
   Ru

понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:
>
> New feature: added Java interface. Eclipse project example.
>
> Home: https://github.com/rururu/rete4frames
>
> Have fun!
>
> Sincerely,
>   Ru
>

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

clojurescript: modifying function definitions

[t x]

Suppose we had the following:


(defn stupid-wrapper [f args]
  (. js/console log args)
  (let [ans (f args)]
(. js/console log ans)
ans))

It basically logs the arguments + return value on every function call.


Now, suppose I wanted to do this to _functions that already existed_ .
Is there a way to do this?

I.e. someone already wrote:


(defn foo [ ... ] ... )

now, I want to do :

(black-magic! foo)

;; and have this "wrap" the foo function. Is there a way to make this work?

Thnaks!

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

To make sure - brief

[Francisco]

Hi, thanks in advance. This is for a college course. I'll be short.

I need to capture with a cam (or maybe a few cams) the motion of a ball. 
Process the video and obtain a few calculus like speed of ball, trajectory, 
height reached from ground... And finally make a recreation which displays 
those calculus (a simple yellow circle moving, no effects or high-detail 
needed).

It's Clojure a good solution for this? I think so, because I've got better 
knowledges in Java than in C or Python and I don't wanna use a non-free 
license product like Matlab.

Will be a compatibility problem using macOS?

Thanks again.

-- 
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: To make sure - brief

[James Reeves]

OpenCV  is a common open source tool for computer
vision processing, and there are libraries and various tutorials online for
integrating this with Clojure (and Java). However, I've yet to play around
with it in depth, so take what I say with a pinch of salt :)

- James


On 13 May 2014 10:51, Francisco  wrote:

> Hi, thanks in advance. This is for a college course. I'll be short.
>
> I need to capture with a cam (or maybe a few cams) the motion of a ball.
> Process the video and obtain a few calculus like speed of ball, trajectory,
> height reached from ground... And finally make a recreation which displays
> those calculus (a simple yellow circle moving, no effects or high-detail
> needed).
>
> It's Clojure a good solution for this? I think so, because I've got better
> knowledges in Java than in C or Python and I don't wanna use a non-free
> license product like Matlab.
>
> Will be a compatibility problem using macOS?
>
> Thanks again.
>
>  --
> 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: To make sure - brief

[Maik Schünemann]

I think clojure will be a great language for this.
You have access to all mature java libraries you can think of and clojure
as great high level language to glue the components together and write
clever algorithms.
Would be great if you could do a blog post/experience report afterwards ;)


On Tue, May 13, 2014 at 5:20 PM, James Reeves  wrote:

> OpenCV  is a common open source tool for computer
> vision processing, and there are libraries and various tutorials online for
> integrating this with Clojure (and Java). However, I've yet to play around
> with it in depth, so take what I say with a pinch of salt :)
>
> - James
>
>
> On 13 May 2014 10:51, Francisco  wrote:
>
>> Hi, thanks in advance. This is for a college course. I'll be short.
>>
>> I need to capture with a cam (or maybe a few cams) the motion of a ball.
>> Process the video and obtain a few calculus like speed of ball, trajectory,
>> height reached from ground... And finally make a recreation which displays
>> those calculus (a simple yellow circle moving, no effects or high-detail
>> needed).
>>
>> It's Clojure a good solution for this? I think so, because I've got
>> better knowledges in Java than in C or Python and I don't wanna use a
>> non-free license product like Matlab.
>>
>> Will be a compatibility problem using macOS?
>>
>> Thanks again.
>>
>>  --
>> 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.
>

-- 
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: using atoms as logs for channels in core.async

[Gary Verhaegen]

What about the following? (as is bound to clojure.core.async ns)

(defn decorate-channel
  [chan at]
  (as/map> (fn [x] (swap! at conj x) x)
   (as/map< (fn [x] (swap! at pop) x)
   chan)))

As far as I can tell, it should do what you want, without introducing
global vars. It also returns a "normal" async channel that can be used
anywhere a channel is expected, without special handling. This could
be very handy for debugging.


On 13 May 2014 06:02, gamma235  wrote:
>
> Hey guys, I took your suggestions and just wanna deliver the finished
> product. I included the macro in there for practice, but agree it is
> probably not necessary. Thanks for all your help.
>
> p is for pretty :)
>
>>
>> (defn pchan [ch]
>>
>>   {:channel ch, :buffer (atom [])})
>
>
>>
>> (defn pbuff [{:keys [ch buffer]}]
>>(println @buffer))
>
>
>>
>> (defn pput [{:keys [channel buffer]} v]
>>   (do
>> (go
>>  (>! channel v))
>> (swap! buffer conj v)
>> (println "put " v)))
>
>
>>
>> (defn ptake [{:keys [channel buffer]}]
>> (go
>>  (let [v (>(if-not (empty? @buffer)
>> (do
>>(swap! buffer pop)
>>(println "took " v)
>> (println "take pending ..."))
>
>
>>
>> (defmacro def-pchan
>>   ([name]
>>`(def ~name (pchan (chan
>>   ([name buff]
>>`(def ~name (pchan (chan ~buff)
>
>
>>
>> (defn clear-buffer [{:keys [buffer]}]
>>   (reset! buffer []))
>>
> it works!
>>
>> (def-pchan pc)
>> (:buffer pc)
>> (pbuff pc)
>> (ptake pc)
>> (pput pc 42)
>> (clear-buffer pc)
>
> --
> 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.

Loading native libs from Clojure

[Gary Verhaegen]

Hi everyone,

I have recently been working on something [0] that required (consisted
mainly of, really) loading native dlls. I have encountered a
surprising (to me) behaviour: calling (System/load path) from Clojure
correctly loaded the library, but did not link the JNI methods,
whereas just switching to Java did link everything correctly.

I spent more time on this than I care to admit, but in the end what
worked was creating a Java class with a single static method that
called System.load [1] and calling that from Clojure [2].

So my question is: is that somehow expected behaviour, or should I
file a bug report (after I investigate a bit more so I can provide
more details)?


[0] https://github.com/gaverhae/naughtmq
[1] 
https://github.com/gaverhae/naughtmq/blob/master/src/naughtmq/PrivateLoader.java
[2] https://github.com/gaverhae/naughtmq/blob/master/src/naughtmq/core.clj#L89

-- 
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] tools.analyzer(.jvm) 0.1.0-alpha1

[Max Kreminski]

On Tuesday, May 13, 2014 4:14:16 AM UTC-7, Gregg Reynolds wrote:
> I've begun experimenting with this and I wonder if there is any further 
> documentation or more extensive examples.  So far I'm just trying to use 
> walk, prewalk, postwalk to crawl an AST, but I think I must be doing 
> something wrong.  Using analyze on something like "(do (def a 1) (def b 2))" 
> I would expect four leaf nodes, a, 1, b, and 2, but using postwalk I bottom 
> out on the whole subexpressions (def a 1) and (def b 2).  Also, location data 
> (file, col, line) appears to not be subordinate to the node it describes, so 
> I must be misinterpreting something.
> 
> I want to do the basic DOM -like stuff like get-parent, get-first-child, 
> etc., but dumping a node produces a vast amount of data whose structure isn't 
> really clear to me.  I can access :children, which is a vector, but I don't 
> see how to descend in the tree.

I wrote a quickref to the AST node structures that also includes a description 
of a generic method for traversing an arbitrary AST. You can find it at 
http://mkremins.github.io/clojure-ast-ref.

The essence of it is that the :children vector is an ordered vector of keys 
into the AST node. Each of these keys is guaranteed to point t

-- 
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] Hermod a core.async message passing library

[kovas boguta]

This is extremely cool!

Some questions:

1. What, besides full buffers, would cause the message to be dropped?
2. What is the practical limit on the size of messages?

I'm trying to understand if manual ack'ing is necessary for say a
map-reduce type distributed application.

If manual ack'ing is truly necessary, then the temptation is to make
the message size bigger so as to reduce the overhead.

In general is hard to understand how its possible to guarantee
delivery of the parts of the message, but not of the message itself.

thanks!















On Fri, May 9, 2014 at 1:27 PM, Timothy Baldridge  wrote:
> Although still in pre-1.0, I'm happy enough with a library I've been working
> on to make an official release.
>
> Hermod is a network-aware message passing library built on core.async. The
> details are best explained by the project's README:
>
> https://github.com/halgari/com.tbaldridge.hermod
>
> There are most likely some bugs still left, but give it a whirl and let me
> know what you think.
>
> Thanks,
>
> Timothy Baldridge
>
> --
> 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: Loading native libs from Clojure

[Aaron Cohen]

System.loadLibrary in java has counter-intuitive behaviour. It examines the
stack to figure out what class invoked it, then loads the native library
into the Classloader of that class. At the REPL, this classloader is
usually a transient instance of DynamicClassLoader, which isn't very
helpful in terms of actually having access to the library once it's been
loaded.

This is why the function clojure.lang.RT/loadLibrary exists. Since RT is
loaded by clojure's parent classloader, any libraries loaded using that
method end up in the correct place.

TLDR: use (clojure.lang.RT/loadLibrary ...) instead of
(java.lang.System/loadLibrary ...)

--Aaron



On Tue, May 13, 2014 at 3:00 PM, Gary Verhaegen wrote:

> Hi everyone,
>
> I have recently been working on something [0] that required (consisted
> mainly of, really) loading native dlls. I have encountered a
> surprising (to me) behaviour: calling (System/load path) from Clojure
> correctly loaded the library, but did not link the JNI methods,
> whereas just switching to Java did link everything correctly.
>
> I spent more time on this than I care to admit, but in the end what
> worked was creating a Java class with a single static method that
> called System.load [1] and calling that from Clojure [2].
>
> So my question is: is that somehow expected behaviour, or should I
> file a bug report (after I investigate a bit more so I can provide
> more details)?
>
>
> [0] https://github.com/gaverhae/naughtmq
> [1]
> https://github.com/gaverhae/naughtmq/blob/master/src/naughtmq/PrivateLoader.java
> [2]
> https://github.com/gaverhae/naughtmq/blob/master/src/naughtmq/core.clj#L89
>
> --
> 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] tools.analyzer(.jvm) 0.1.0-alpha1

[Max Kreminski]

Hi Greg,

I wrote a quickref to the AST node structures that also describes a generic 
method for traversing an arbitrary AST. It can be found here: 
http://mkremins.github.io/clojure-ast-ref

Essentially, the :children vector is an ordered list of keys into the AST node. 
Each of these keys is guaranteed to point to another AST node or vector of AST 
nodes – so you can look at :children to determine which of a node's keys 
themselves point to AST nodes, then visit the nodes at these keys as necessary.

I'm not yet entirely familiar with how the provided pre- and postwalk functions 
are used for AST traversal, but when last I checked they make use of this 
strategy internally. This allows generic walkers to ignore nodes they don't 
care about (i.e. simply not include any code to handle nodes of a particular 
type) while still being able to visit children of the ignored nodes.

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
--- 
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] Hermod a core.async message passing library

[Timothy Baldridge]

Under-the-sheets Hermod uses TCP. Thus the idea is, if a connection is
dropped mid-transmission the message is dropped. If a buffer is full,
messages are dropped.

Technically I've heard it's possible for TCP to hand you corrupted data
(it's pretty rare, but it could happen). In that case it is assumed that
Fressian will throw an error on deserialization, in such a case the message
will be discarded. I could add another level of corruption handling, but I
haven't attempted this yet.

So the gist of this all is: the system is no more reliable than TCP, and no
less.

So yes, manual acking is needed if you want to make sure a message arrives.
But in my experience I've found it much easier to reason about a system
that pushes acking into the app, than one that attempts to handle it at a
lower level. This allows for per-message retry limits, fire-and-forget
messages, sliding windows, or any other type of co-ordination desired.

Timothy


On Tue, May 13, 2014 at 1:04 PM, kovas boguta wrote:

> This is extremely cool!
>
> Some questions:
>
> 1. What, besides full buffers, would cause the message to be dropped?
> 2. What is the practical limit on the size of messages?
>
> I'm trying to understand if manual ack'ing is necessary for say a
> map-reduce type distributed application.
>
> If manual ack'ing is truly necessary, then the temptation is to make
> the message size bigger so as to reduce the overhead.
>
> In general is hard to understand how its possible to guarantee
> delivery of the parts of the message, but not of the message itself.
>
> thanks!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, May 9, 2014 at 1:27 PM, Timothy Baldridge 
> wrote:
> > Although still in pre-1.0, I'm happy enough with a library I've been
> working
> > on to make an official release.
> >
> > Hermod is a network-aware message passing library built on core.async.
> The
> > details are best explained by the project's README:
> >
> > https://github.com/halgari/com.tbaldridge.hermod
> >
> > There are most likely some bugs still left, but give it a whirl and let
> me
> > know what you think.
> >
> > Thanks,
> >
> > Timothy Baldridge
> >
> > --
> > 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

[ANN] Automat: better FSMs through combinators

[Zach Tellman]

https://github.com/ztellman/automat

This has been languishing in my Github for a while, for lack of a few 
finishing touches on the code and documentation.  I think this is one of 
cooler libraries I've written, and beyond the obvious use for parsers, the 
set theoretic operators could be a powerful way to specify actions in 
response to complex browsing behaviors on a site, or any other number of 
things.  I'm excited to see how it's used.

I'm happy to answer any questions.  Suggestions on how to improve the 
documentation are encouraged.

Zach

-- 
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] tools.analyzer(.jvm) 0.1.0-alpha1

[Timothy Baldridge]

My Clojure/West talk covers how to write such a pass, and the comments on
this video include a link to the source code.

https://www.youtube.com/watch?v=KhRQmT22SSg


On Tue, May 13, 2014 at 1:16 PM, Max Kreminski wrote:

> Hi Greg,
>
> I wrote a quickref to the AST node structures that also describes a
> generic method for traversing an arbitrary AST. It can be found here:
> http://mkremins.github.io/clojure-ast-ref
>
> Essentially, the :children vector is an ordered list of keys into the AST
> node. Each of these keys is guaranteed to point to another AST node or
> vector of AST nodes – so you can look at :children to determine which of a
> node's keys themselves point to AST nodes, then visit the nodes at these
> keys as necessary.
>
> I'm not yet entirely familiar with how the provided pre- and postwalk
> functions are used for AST traversal, but when last I checked they make use
> of this strategy internally. This allows generic walkers to ignore nodes
> they don't care about (i.e. simply not include any code to handle nodes of
> a particular type) while still being able to visit children of the ignored
> nodes.
>
> 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
> ---
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: JSON authentication with cemerick/friend?

[Ivan Schuetz]

Okay. One question, what is the point to implement this as middleware? It's 
just a request to /login, which checks the credentials against a database 
and returns the status as JSON... in my case the HTTP status code will not 
change... (200 for success/failure). I thought it was maybe the case to 
modify the HTTP headers, e.g. to add a session id, but it seems this is 
also possible with normal handlers.

I would see sense in using a middleware to protect resources that need 
authentication. But don't see it right now for /login service.




Am Dienstag, 6. Mai 2014 12:56:33 UTC+2 schrieb Erik Bakstad:
>
> You can also pass inn options to wrap-json-body so you don't have to use 
> keywordize-keys:
>
> (def app
>   (wrap-json-body handler {:keywords? true :bigdecimals? true}))
>
>
> kl. 12:04:10 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>>
>> Thanks. I just found out that my middlewares work, I just had to reorder 
>> them like this:
>>
>> (def app
>>   (->
>>   (handler/api app-routes)
>>  (friend/authenticate {:credential-fn (partial 
>> creds/bcrypt-credential-fn users)
>> :login-url "/login"
>> :workflows [
>> (ajax-login)
>> ]})
>>
>>   (format/wrap-restful-format)
>> 
>>   (middleware/wrap-json-body)
>>   (middleware/wrap-json-params)
>>   (middleware/wrap-json-response)
>>
>>   )
>>   )
>>
>> Now I don't need slurp... still had to change this line in ajax-login, 
>> since the format using these middlewares is a bit different:
>>
>>   (if-let [{:keys [username password] :as creds} (get-in 
>> request [:params :json-params])]
>>
>> with:
>>
>>   (if-let [{:keys [username password] :as creds} 
>> (clojure.walk/keywordize-keys(:json-params request))]
>>
>>
>>
>>
>>
>>
>> Am Dienstag, 6. Mai 2014 08:03:47 UTC+2 schrieb Erik Bakstad:
>>>
>>> We're using a custom jsonparam-extractor middleware that basically does 
>>> this:
>>>
>>> (update-in req [:params] assoc :json-params (read-json (slurp (:body 
>>> req)) true))
>>>
>>> I should probably have clarified this, sorry.
>>>
>>> Also, we're not using interactive-form so I haven't tested if the two 
>>> workflows work together. It shouldn't be a problem to make them work 
>>> together though.
>>>
>>> kl. 02:31:30 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:

 Sorry. I mean accepts the request map as an argument. This map doesn't 
 contain the parameters.


 Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:
>
> The snippet provided by Eric doesn't use the body... it returns a 
> function that accepts params as argument, but they were not being 
> passed... 
> body was set instead, that's why I added slurp.
>
> So maybe there's something wrong with the 
>  (middleware/wrap-json-params), because it's evidently not having effect.
>
>
> Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>>
>> (middleware/wrap-json-params) slurps the body up completely - 
>> this is a mutation, so you won't be able to access the body again.
>>
>>   Ivan Schuetz
>>  May 5, 2014 3:49 PM
>> Concerning the workflow with the ajax-login... for some reason the 
>> middleware to set params with json body of my POST isn't working.
>>
>> As a workaround I added this to ajax-login, to parse the params:
>>
>> (checore/parse-string (slurp (:body request)) true)  
>>
>>
>>
>> I had also to remove the interactive-form workflow I had... now my 
>> middleware looks like this:
>>
>>
>>(friend/authenticate {:credential-fn (partial 
>> creds/bcrypt-credential-fn users)
>> :login-url "/login"
>> :workflows [
>> (ajax-login)
>> ]})
>>
>>
>>
>> I do have the middlewares supposedly responsible for setting :params 
>> ... not idea why this is not being done. This is the complete block:
>>
>> (def app
>>   (->
>>   (handler/api app-routes)
>>
>>   (format/wrap-restful-format)
>> 
>>   (middleware/wrap-json-body)
>>   (middleware/wrap-json-params)
>>   (middleware/wrap-json-response)
>>
>>(friend/authenticate {:credential-fn (partial 
>> creds/bcrypt-credential-fn users)
>> :login-url "/login"
>> :workflows [
>> (ajax-login)
>> ]})
>>
>>   )
>>   )
>>
>> But well, it works for now.
>>
>>
>>
>> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Sc

Re: [ANN] tools.analyzer(.jvm) 0.1.0-alpha1

[Gregg Reynolds]

On Tue, May 13, 2014 at 2:16 PM, Max Kreminski wrote:

> Hi Greg,
>
> I wrote a quickref to the AST node structures that also describes a
> generic method for traversing an arbitrary AST. It can be found here:
> http://mkremins.github.io/clojure-ast-ref
>
> Max - perfect!  That's just what I was looking for.

Thanks,

gregg

-- 
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] Automat: better FSMs through combinators

[Colin Fleming]

I'm also very excited about Automat, although I haven't had time to look at
it closely yet. Ragel is one of my favourite pieces of software. Here's an
article from Zed Shaw about using state charts for networked apps:
http://www.zedshaw.com/essays/ragel_state_charts.html. I read an article
(or an interview, I can't remember) where he discussed the state machines
in Mongrel in more depth, it was fascinating and quite amazing how much it
simplified the code, made it much more robust and consistently handled
tricky corners of HTTP while easily supporting things like websockets.

I'll take a look when I get a moment and provide some feedback - in
particular I'm excited about the possibility of compiling state machines
without the build time precompile step, I think there are a lot of
interesting possibilities with this.

Cheers,
Colin


On 14 May 2014 07:27, Zach Tellman  wrote:

> https://github.com/ztellman/automat
>
> This has been languishing in my Github for a while, for lack of a few
> finishing touches on the code and documentation.  I think this is one of
> cooler libraries I've written, and beyond the obvious use for parsers, the
> set theoretic operators could be a powerful way to specify actions in
> response to complex browsing behaviors on a site, or any other number of
> things.  I'm excited to see how it's used.
>
> I'm happy to answer any questions.  Suggestions on how to improve the
> documentation are encouraged.
>
> Zach
>
> --
> 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: Proposing a new Clojure documentation system (in Clojure)

[bob]

Any Result? Talk is cheap

On Sunday, April 27, 2014 12:39:04 AM UTC+8, Val Waeselynck wrote:
>
> Hello to all,
>
> *Short version :* I think Clojure needs a documentation system in 
> Clojure, I would like to know if some efforts exist in that direction, and 
> I am willing to create it / contribute to it.
>
> *Long version :*
>
> I've been thinking for a while that the Clojure community could benefit a 
> lot from a more sophisticated and ergonomic documentation system. 
>
> I have seen some existing plugins like lein-sphinx, but I think it would 
> be really good to have documentation that would be written in Clojure, for 
> the following reasons :
>
>- we're all very fond of Clojure data structures and their syntax. (I 
>don't know about you, but I find that even HTML looks better in 
> Clojurethan in HTML). Plus, Clojure 
> programmers already know how to edit them.
>- (better reason) The facts that Vars are first-class citizens and 
>that symbols can be referred explicitly with hardly any ceremony (macros) 
>are a exceptional opportunity to make smart and highly-structured 
>documentation very easily.
>- if it's in Clojure, Clojure programmers can seamlessly build *ad 
> hoc*documentation functionality on top of it to suit their own particular 
> needs.
>
> I haven't found anything of the like yet, and if it exists, I would be 
> grateful if someone would redirect me to it.
>
> Here are *my thoughts on this :*
>
>1. Clojure doc-strings, although they are quite handy as reminders and 
>for doc-indexation, are *too raw a content*. Even when they are done 
>right, they tend to be cumbersome, and it's too bad to have such concise 
>code drown in the middle of so much documentation. What's more, I believe 
>that when programmers program a function (or anything), they tend to think 
>more about the implementation than the (uninformed) usage, so they have 
>little incentive to make it right.
>2. Building on 1. having a system where documentation and programs 
>live in separate files, in the same way as tests, would enforce a healthy 
>separation of concerns. Importantly, it would make life much easier on the 
>Version Control perspective.
>3. Documentation should probably be made differently than what people 
>have got accustomed to by classical languages. Because you seldom find 
>types, and because IMHO Clojure programs are formed more by factoring out 
>recurring mechanisms in code than from implementing intellectual 
>abstractions, the relevant concepts tend not to be obvious in the code. 
>Since in Clojure we program with verbs, not 
> nouns,
>  
>I think *documentation is best made by example*.
>4. Documentation of a Var should not be a formal description of what 
>it is and what it does with some cryptically-named variables. *Every 
>bit of documentation should be a micro-tutorial*. Emphasis should be 
>put on usage, examples, tips, pitfalls, howtos.
>5. There should be structure in the documentation, and it shouldn't be 
>just :see-also links - *there should be semantics* in it.  For 
>example, some functions/macros are really meant to be nothing but 
>shorthands for calling other functions : that kind of relationship should 
>be explicitly documented.
>6. Documentation should not be just information about each separate 
>Var in a namespace. There should be a hierarchy to make the most useful 
>elements of an API more obvious. Also, adding cross-vars documentation 
>elements such as tags and topics could make it easier to navigate and 
>understand.
>7. *Documentation in the REPL is great*, it was one of the very good 
>surprises when I started learning Clojure. However, a rich and 
> good-looking 
>presentation like in Javadocs would be welcome too.
>
> Of course, all of the above are just vague principles. Here is *some 
> functionality I suggest for a start :*
>
>1. Documentation content elements could be written in a Clojure DSL 
>emulating some kind of docbook-like markup language.
>2. On the user side, the documentation would be accessible through a 
>generated web interface, a REPL interface, and maybe other formats like 
>Wiki.
>3. Documentation could be programmed anywhere in a project by simply 
>referring to the relevant Vars and calling the documentation API. Ideally, 
>there would be a dedicated folder for documentation files, and a Leiningen 
>plugin to compile them and generate the HTML from them.
>4. I often find myself lost because I have no idea what shape some 
>arguments to a function should have, such as config maps and maps 
>representing application-specific models. To adress this, I propose to 
>explicitly declare and describe *"stereotypes"* in

Re: [ANN] tools.analyzer(.jvm) 0.1.0-alpha1

[Gregg Reynolds]

On Tue, May 13, 2014 at 2:17 PM, Timothy Baldridge wrote:

> My Clojure/West talk covers how to write such a pass, and the comments on
> this video include a link to the source code.
>
> https://www.youtube.com/watch?v=KhRQmT22SSg
>

Just watched, very helpful.  Thanks.

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

[Brandon Bloom]

Leif is right, but isa?'s docstring doesn't mention this behavior. Here's 
the relevant 
code: 
https://github.com/clojure/clojure/blob/028af0e0b271aa558ea44780e5d951f4932c7842/src/clj/clojure/core.clj#L5120

On Tuesday, May 13, 2014 12:22:28 AM UTC-4, Leif wrote:
>
> Hi, Ranko.
>
> I *think* it's because vectors are handled specially during dispatch, to 
> easily handle both dispatching on multiple args and hierarchies:
>
> "isa?works
>  with vectors by calling 
> isa?on
>  their corresponding elements:
>
> (isa? [::square ::rect] [::shape ::shape])"
>
> --Leif
>
> On Monday, May 12, 2014 8:41:35 PM UTC-4, r wrote:
>>
>> Why is something like 
>>
>> (derive [::matrix ::ring-element] ::ring-element)
>>
>> prevented by the assertion in clojure.core/derive?
>> Is there something that is an actual show-stopper 
>> or is this an implementation detail?
>>
>> Cheers,
>> ranko
>>
>>
>>

-- 
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: using atoms as logs for channels in core.async

[gamma235]

Hi Gary, 

Your function looks interesting and succinct, but I am still new to this 
subject so am not sure how it would be used. Could you give some examples?

Jesse

On Wednesday, May 14, 2014 3:34:17 AM UTC+9, Gary Verhaegen wrote:
>
> What about the following? (as is bound to clojure.core.async ns) 
>
> (defn decorate-channel 
>   [chan at] 
>   (as/map> (fn [x] (swap! at conj x) x) 
>(as/map< (fn [x] (swap! at pop) x) 
>chan))) 
>
> As far as I can tell, it should do what you want, without introducing 
> global vars. It also returns a "normal" async channel that can be used 
> anywhere a channel is expected, without special handling. This could 
> be very handy for debugging. 
>
>
> On 13 May 2014 06:02, gamma235 > 
> wrote: 
> > 
> > Hey guys, I took your suggestions and just wanna deliver the finished 
> > product. I included the macro in there for practice, but agree it is 
> > probably not necessary. Thanks for all your help. 
> > 
> > p is for pretty :) 
> > 
> >> 
> >> (defn pchan [ch] 
> >> 
> >>   {:channel ch, :buffer (atom [])}) 
> > 
> > 
> >> 
> >> (defn pbuff [{:keys [ch buffer]}] 
> >>(println @buffer)) 
> > 
> > 
> >> 
> >> (defn pput [{:keys [channel buffer]} v] 
> >>   (do 
> >> (go 
> >>  (>! channel v)) 
> >> (swap! buffer conj v) 
> >> (println "put " v))) 
> > 
> > 
> >> 
> >> (defn ptake [{:keys [channel buffer]}] 
> >> (go 
> >>  (let [v ( >>(if-not (empty? @buffer) 
> >> (do 
> >>(swap! buffer pop) 
> >>(println "took " v) 
> >> (println "take pending ...")) 
> > 
> > 
> >> 
> >> (defmacro def-pchan 
> >>   ([name] 
> >>`(def ~name (pchan (chan 
> >>   ([name buff] 
> >>`(def ~name (pchan (chan ~buff) 
> > 
> > 
> >> 
> >> (defn clear-buffer [{:keys [buffer]}] 
> >>   (reset! buffer [])) 
> >> 
> > it works! 
> >> 
> >> (def-pchan pc) 
> >> (:buffer pc) 
> >> (pbuff pc) 
> >> (ptake pc) 
> >> (pput pc 42) 
> >> (clear-buffer pc) 
> > 
> > -- 
> > 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" 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.

Joy of Clojure question

[gamma235]

I am reading The Joy of Clojure now and am finishing chapter 5 on sequence 
abstractions. There is an example given that demonstrates how to locate the 
index of an element in a sequence by value, but I don't understand why the 
character lookup here is returning 13. Can somebody please explain this to 
me?

(defn index [coll]
>   (cond
>(map? coll) (seq coll)
>(set? coll) (map vector coll coll)
>:else (map vector (iterate inc 0) coll)))
>
> (defn pos [pred coll]
>   (for [[i v] (index coll) :when (pred v)] i))
>
 

> (pos \3 ":a 4 :b 1 :c 3 :d 4")   

 

=> 13


J 

-- 
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: clojurescript: modifying function definitions

[Dave Sann]

I have done this sort of this with with-redefs to look at the input and 
output of functions inside a library I was using.

http://clojuredocs.org/clojure_core/clojure.core/with-redefs

I may have a small macro to assist. I can post later if you wish.

You need to be careful of binding boundaries though - so its not ideal in 
all situations (i.e later lazy evaluations).

Dave


On Wednesday, 14 May 2014 00:09:22 UTC+10, t x wrote:
>
> Suppose we had the following: 
>
>
> (defn stupid-wrapper [f args] 
>   (. js/console log args) 
>   (let [ans (f args)] 
> (. js/console log ans) 
> ans)) 
>
> It basically logs the arguments + return value on every function call. 
>
>
> Now, suppose I wanted to do this to _functions that already existed_ . 
> Is there a way to do this? 
>
> I.e. someone already wrote: 
>
>
> (defn foo [ ... ] ... ) 
>
> now, I want to do : 
>
> (black-magic! foo) 
>
> ;; and have this "wrap" the foo function. Is there a way to make this 
> work? 
>
> Thnaks! 
>

-- 
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] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Dave Sann]

this code (and the related create) is unusual:

(defn reset []
  "Reset: clear and initialize all memories"
  (def =AMEM= (object-array @ACNT))
  (def =BMEM= (object-array =BCNT=))
  (def =FMEM= (create-fmem =TEMPL=))
  (def =FMMB= (create-fmem =TEMPL=))
  (def =FIDS= (HashMap.))
  (def CFSET (atom nil))
  (def FCNT (atom 0)))

It implies that you can only have one set of rules/engine in any usage of the 
library. Even if you plan to use mutable data - this seems to create additional 
restrictions. Why not put all of these into a map and pass that around as the 
ruleset/engine state?


On Tuesday, 13 May 2014 23:32:49 UTC+10, ru wrote:
>
> Alan. You absolutely right! Clojure must return thinking of programmers 
> back to solving problems from vanity and narcissism of unnecessary 
> complexity :) I certainly will look on Clara more attentively and may be 
> switch to it in my applications.
>
> cheers,
>Ru
>
> понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:
>>
>> New feature: added Java interface. Eclipse project example.
>>
>> Home: https://github.com/rururu/rete4frames
>>
>> Have fun!
>>
>> Sincerely,
>>   Ru
>>
>

-- 
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: Joy of Clojure question

[Bridget]

\3 is a character literal, so you're looking up the character 3. You're 
looking it up in a collection which is a string. Count from the first 
position, 0, a colon, then 1, the letter a, and so on. 3 is at the 13th 
position.

On Tuesday, May 13, 2014 9:44:38 PM UTC-4, gamma235 wrote:
>
> I am reading The Joy of Clojure now and am finishing chapter 5 on sequence 
> abstractions. There is an example given that demonstrates how to locate the 
> index of an element in a sequence by value, but I don't understand why the 
> character lookup here is returning 13. Can somebody please explain this to 
> me?
>
> (defn index [coll]
>>   (cond
>>(map? coll) (seq coll)
>>(set? coll) (map vector coll coll)
>>:else (map vector (iterate inc 0) coll)))
>>
>> (defn pos [pred coll]
>>   (for [[i v] (index coll) :when (pred v)] i))
>>
>  
>
>> (pos \3 ":a 4 :b 1 :c 3 :d 4")   
>
>  
>
> => 13
>
>
> J 
>

-- 
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: Joy of Clojure question

[Guru Devanla]

The call to (index) returns this vector

([0 \:] [1 \a] [2 \space] [3 \4] [4 \space] [5 \:] [6 \b] [7 \space] [8 \1]
[9 \space] [10 \:] [11 \c] [12 \space] [13 \3] [14 \space] [15 \:] [16 \d]
[17 \space] [18 \4])

And, 3 here is in the 13th position. Your (cond) in index function is
picking up the :else branch.


On Tue, May 13, 2014 at 6:44 PM, gamma235  wrote:

> I am reading The Joy of Clojure now and am finishing chapter 5 on sequence
> abstractions. There is an example given that demonstrates how to locate the
> index of an element in a sequence by value, but I don't understand why the
> character lookup here is returning 13. Can somebody please explain this to
> me?
>
> (defn index [coll]
>>   (cond
>>(map? coll) (seq coll)
>>(set? coll) (map vector coll coll)
>>:else (map vector (iterate inc 0) coll)))
>>
>> (defn pos [pred coll]
>>   (for [[i v] (index coll) :when (pred v)] i))
>>
>
>
>> (pos \3 ":a 4 :b 1 :c 3 :d 4")
>
>
>
> => 13
>
>
> J
>
> --
> 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] brute 0.2.0 - A lightweight Entity Component System library for writing games

[Atamert Ölçgen]

This is nice!

I'm working on a component-entity-system myself. (
https://github.com/muhuk/clecs)

I aim for pluggable backends, so you can choose between a persistent world
or an in-memory world etc. The reference backend is based on an atom. So
clecs is not as side-effect free as brute. But the public API somewhat
mimics atoms and allows for changes only within atomic transactions.

Anyways, I'll keep an eye on brute and maybe steal some ideas from it
without shame.




On Tue, May 13, 2014 at 7:22 AM, Mark Mandel  wrote:

> Brute is a simple and lightweight Entity Component System library for
> writing games with Clojure.
>
> This is a rewrite of Brute 0.1.1, to get rid of all the global internal
> refs, and make it so that Brute simply passes around an immutable
> collection.  This makes things far nicer to deal with, and makes the
> library far more flexible.
>
> Full Blog Post on changes:
>
> http://www.compoundtheory.com/brute-entity-component-system-library-0-2-0-the-sequel/
>
> The aim of this project was to use basic Clojure building blocks to form
> an Entity System architecture, and get out of the author's way when
> deciding exactly what approach would best fit their game when integrating
> with this library.
>
> To that end:
>
>
>- Entities are UUIDs.
>- The Component type system can be easily extended through a
>multimethod get-component-type, but defaults to using the component's
>instance class as its type.
>- Components can therefore be defrecords or deftypes by default, but
>could easily be maps or just about anything else.
>- Systems are simply references to functions of the format (fn
>[delta]).
>
>  Project can be found on Github at:
> https://github.com/markmandel/brute
>
> Sample Pong Game can be found on Github as well:
> https://github.com/markmandel/brute-play-pong
>
>
> --
> E: mark.man...@gmail.com
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

[gamma235]

Okay, both these answers make lots of sense. thank you for your help. 

J

On Wednesday, May 14, 2014 11:47:51 AM UTC+9, Guru Devanla wrote:
>
> The call to (index) returns this vector 
>
> ([0 \:] [1 \a] [2 \space] [3 \4] [4 \space] [5 \:] [6 \b] [7 \space] [8 
> \1] [9 \space] [10 \:] [11 \c] [12 \space] [13 \3] [14 \space] [15 \:] [16 
> \d] [17 \space] [18 \4])
>
> And, 3 here is in the 13th position. Your (cond) in index function is 
> picking up the :else branch.
>
>
> On Tue, May 13, 2014 at 6:44 PM, gamma235 
> > wrote:
>
>> I am reading The Joy of Clojure now and am finishing chapter 5 on 
>> sequence abstractions. There is an example given that demonstrates how to 
>> locate the index of an element in a sequence by value, but I don't 
>> understand why the character lookup here is returning 13. Can somebody 
>> please explain this to me?
>>
>> (defn index [coll]
>>>   (cond
>>>(map? coll) (seq coll)
>>>(set? coll) (map vector coll coll)
>>>:else (map vector (iterate inc 0) coll)))
>>>
>>> (defn pos [pred coll]
>>>   (for [[i v] (index coll) :when (pred v)] i))
>>>
>>  
>>
>>> (pos \3 ":a 4 :b 1 :c 3 :d 4")   
>>
>>  
>>
>> => 13
>>
>>
>> J 
>>
>> -- 
>> 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" 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] brute 0.2.0 - A lightweight Entity Component System library for writing games

[Zach Oakes]

Thanks Mark, this is impressive. Let me know if there is anything I can do 
on my end to make play-clj more agnostic regarding entity systems. The 
built-in entity system is quite simple and doesn't do much for you, so this 
looks like a great alternative.

On Monday, May 12, 2014 7:22:07 PM UTC-4, Mark Mandel wrote:
>
> Brute is a simple and lightweight Entity Component System library for 
> writing games with Clojure.
>
> This is a rewrite of Brute 0.1.1, to get rid of all the global internal 
> refs, and make it so that Brute simply passes around an immutable 
> collection.  This makes things far nicer to deal with, and makes the 
> library far more flexible.
>
> Full Blog Post on changes: 
>
> http://www.compoundtheory.com/brute-entity-component-system-library-0-2-0-the-sequel/
>
> The aim of this project was to use basic Clojure building blocks to form 
> an Entity System architecture, and get out of the author's way when 
> deciding exactly what approach would best fit their game when integrating 
> with this library.
>
> To that end:
>
>
>- Entities are UUIDs.
>- The Component type system can be easily extended through a 
>multimethod get-component-type, but defaults to using the component's 
>instance class as its type. 
>- Components can therefore be defrecords or deftypes by default, but 
>could easily be maps or just about anything else.
>- Systems are simply references to functions of the format (fn 
>[delta]).
>
>  Project can be found on Github at:
> https://github.com/markmandel/brute
>
> Sample Pong Game can be found on Github as well:
> https://github.com/markmandel/brute-play-pong
>
>
> -- 
> E: mark@gmail.com 
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>  

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

ANN Monger 2.0 RC1 is released

[Michael Klishin]

Monger [1] is a Clojure MongoDB client for a more civilized age.

2.0 is a major release that has *breaking public API changes*.

Release notes:
http://blog.clojurewerkz.org/blog/2014/05/14/monger-2-dot-0-0-rc1-is-released/

Please give this RC a try. This is the biggest revision of Monger in
the entire history of the project.

1. http://clojuremongodb.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Ryan Brush]

It's cool to see different approaches to Rete in Clojure. I think a solid 
implementation could really disrupt Drools. Why would I want to write in a 
limited rule language if I can get rule-like semantics and the 
expressiveness of Clojure at the same time? Of course I'm going to be 
biased towards Clara, but more important is the fact that Clojure provides 
a stronger foundation for expert systems than anything else out there. This 
is an opportunity for Clojure to make inroads. 

Regarding the benchmarking questions, I'm sure Drools will run Ms. Manners 
and other benchmarks faster than Clara at this point. This is partially 
because I've emphasized correctness and simplicity in Clara first, although 
I've recently started doing some significant profiling and optimizations. 
But Ms. Manners is really a poor example of typical rule engine use...it 
was created specifically to exercise some worst case scenarios. It's also 
constraint-oriented, so I'd actually use core.logic to solve that problem 
before I'd use any forward-chaining approach.

More important is to ask whether a system is fast enough for your needs. I 
gladly pay some overhead for persistent data structures because they are 
fast enough and save me a lot of time. (And I can spend that time 
optimizing the real bottlenecks of the program!)  These advantages tend to 
pay off in surprising ways, such as the recent excitement around how fast 
React and Om are. Clara will get optimized, but not at the cost of Clojure 
ideals like immutability.

In any case, it's great to see activity around Rete in Clojure. Clara was 
designed for a particular problem space I've been working in, but it's 
certainly not the only approach we should consider.

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

ANN: zip-visit and fast-zip-visit 1.0.2

[Alexander Hudek]

The zip-visit library implements zipper-based visitors that allow one to 
carry
and modify state during a depth first traversal of a zipper. There is an
extensive description here:

https://github.com/akhudek/zip-visit

A short example of a zipper-based version of some. Here n is the node and
s is the state:

(defn some-tree-visitor [f]
  (visitor :pre [n s] (if-let [v (f n)] {:state v :break true})))

(defn some-tree [f zipper]
  (:state (visit zipper nil [(some-tree-visitor f)])))

(def my-zip (z/vector-zip [1 3 [4 5 [6] 7 [8 9]]]))

user=> (some-tree #(if (and (number? %) (even? %)) %) my-zip)4

This release includes a bug fix for distinguishing between false and nil. 
The fast-zip-visit 
library is identical, but uses fast-zip instead of clojure.zip.

Alex

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

[ANN] Clojure RETE implementation - CLIPS-like expert system

[daly]

Ryan,

Does this system compile the left hand sides into a shared data structure?

Tim Daly

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

[ANN] Clojure RETE implementation - CLIPS-like expert system

[Ryan Brush]

Hi Tim,

Yes. Clara does Rete-style structural sharing of equivalent rule constraints, 
and then compiles those constraints into Clojure expressions. This actually 
happens when a rule session is created for a set of rules, but this is memoized 
by default so you only pay that cost the first time.

There are some opportunities to do more fine-grained sharing of parts of rule 
constraints, but that's an optimization we haven't gotten to yet. :)

-Ryan

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