Re: [ldnclj] Re: Suggestions for open source contributions?

[Steven Deobald]

Wow, folks. This is a fantastic list. It is really helpful to know not only
a project's contribution needs but also the maintainer's appetite for
working with newer/younger contributors.

Our mentoring process will proceed for another week or two. In the
meantime, we'd love to see more suggestions. :)

Thanks everyone!

Steven Deobald -- ⌀ -- nilenso.com

On 2 February 2016 at 22:37, Jason Felice  wrote:

> We have a lot of focus on being new-Clojurian and new-programmer friendly
> for Avi, including being able to spend a couple hours a week
> remote-pairing.  I think this is a good project if the person is familiar
> with (or especially fond of) Vim.
>
> https://github.com/maitria/avi
>
> -Jason
>
> On Tue, Feb 2, 2016 at 9:12 AM, Bozhidar Batsov 
> wrote:
>
>> If you're into tooling - there's always plenty of work to be done on
>> cider-nrepl (https://github.com/clojure-emacs/cider-nrepl) :-)
>>
>> On 2 February 2016 at 10:28, Chris Howe-Jones 
>> wrote:
>>
>>> Another open source library that has some real momentum behind it at the
>>> moment is baid-chat https://github.com/braidchat/meta/wiki . It's the
>>> Clojure Communities OSS alternative to Slack.
>>>
>>> Why is it needed? Lots of reasons that are elaborated in the motivations
>>> page of the wiki but one of the most urgent is that Slack has adopted a
>>> policy of closing community teams to new members once they get large
>>> (anecdotally around 7000 members) and the Clojurians Slack channel is
>>> already over 4800.
>>>
>>>
>>> On 2 Feb 2016, at 08:22, Mikera  wrote:
>>>
>>> If you are interested in data science, help with core.matrix and the
>>> associated libraries is always appreciated, and we are very
>>> contributor-friendly in the numerical Clojure community.
>>>
>>> On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:

 Hey folks!

 Today is the first day nilenso has ever had an intern on-staff. He's
 been in the industry for a few years but he's relatively new to Clojure. We
 try to ramp people up as slowly and supportively as possible. For interns,
 we figure writing (and re-writing, natch) open source is the safest place
 to start.

 With that context set, does anyone on the list have suggestions for
 projects we can guide him through? We will be working with him through some
 the standard Clojure literature over the coming months, as well as
 providing guidance with his patches/pull-requests.

 We're open to any shape of project: applications, libraries, tools. If
 you have a Clojure project you would like help with (or that you wish
 someone would start), we would love to evaluate it as a learning
 opportunity.

 Thanks everyone!

 Steven Deobald -- ⌀ -- nilenso.com

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "London Clojurians" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to london-clojurians+unsubscr...@googlegroups.com.
>>> To post to this group, send email to london-clojuri...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/london-clojurians.
>>> 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.
>>
>
>

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

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Zach Tellman]

This is incidental to the topic of the thread, but to address why Manifold 
exists when there's already core.async, there's a write-up of the rationale 
linked in the readme: http://aleph.io/manifold/rationale.html.

On Saturday, January 23, 2016 at 6:50:34 AM UTC-5, qsys wrote:
>
> Depends on what you want... what I really like is the easy modularity: 
> deploy new 'verticles' somewhere in your network, and they're just all 
> connected through a the eventbus. I make a 'new' module, I put it somewhere 
> and it's automatically picked up by the appication and I can communicate 
> with it using that event bus. Is there something similar in clojure, or can 
> I achieve something similar in clojure? I checked 
> - catacumba: web toolkit, not what I'm after
> - sente: is about the web
> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and 
> well, no 'event bus' (a kind of wrapper around netty etc).
> - manifold: I don't really see the added value, having core.async - but I 
> may fail to see something important here
> - pomegranate: is possibly very interesting in adding new modules... not 
> for removing 'old versions' of a module.
> - pedestal: have to have a deeper look into it, but so far, I have a 
> feeling it's more about web than 'intra-program' communication
>
> So, so far, I don't see how to implement something like the vert.x event 
> bus, with autodiscovery, in clojure (although I would love to see something 
> like it), expanding to the browser. I don't mind (and prefer) composing it 
> using different libraries, but I feel to see how to have this functionality 
> in clojure (now, I wrap the vertx eventbus in my clojure programs), and 
> since I already load vertx for the eventbus, I use it as web server as 
> well, if I need one... So well, if someone has an idea, it might be a nice 
> project I'd love to work on :).
>
> thx, qsys
>
> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>>
>> I've done some evaluations of Vert.x in the past and was rather 
>> underwhelmed. What is it that you are trying to accomplish? Stuff like 
>> Pedestal offers async web services, but without the complexity of an 
>> traditional evented server. So perhaps if we had a better idea of your 
>> requirements we could be a bit more helpful.
>>
>> So I'd say, look into Pedestal and then define what you need that it 
>> cannot do. Same for other toolkits like ring and httpkit. 
>>
>> Timothy
>>
>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>
>>>
>>> It used to be that Vert.x 2.x had integration for Clojure, but version 
>>> 3.x hasn't added it yet. Has anyone used this version through the Java API 
>>> and if so, how painful was it? Is Reactor any 
>>> better in that respect? What are people using when they want this kind of 
>>> back end?
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[kovas boguta]

On Tue, Feb 2, 2016 at 6:15 PM, Herwig Hochleitner 
wrote:
>
> When dealing with ground tags generically (like data.xml does), i.e. the
> mapped-to structures add no information over the ground tags, I'd say it
> would be still pretty easy to create a reader, which uses optimized
> structures for content-only, or attribute-only tags and the like. Even
> common things like space-separated (class-) lists in attribute tags, ...
> Dynamic runtimes can also optimize for object shapes "automagically". For
> reference, google optimization tips for v8
> Of course, none of this will decide for you that ordering of your child
> tags is irrelevant and that it can be used to facilitate O(1) hash-lookup.
> Thus it _is_ unfortunate that there exists no accepted standard for
> encoding arbitrary associative structures in XML, because it pushes you
> towards app-specific representations.
>

Out-of-band schemas/assumptions or automagic inference are incidental
complexity to deal with the fact that XML cannot directly represent the
concepts that algorithms want to deal in. This is the point I was making
originally.

-- 
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] walmartlabs/active-status 0.1.2

[Leon Grapenthin]

That seems like a cool thing to have. Thank you.


On Tuesday, February 2, 2016 at 10:31:10 PM UTC+1, Howard M. Lewis Ship 
wrote:
>
> Library for allowing a command line application to report status of 
> multiple asynchronous jobs using an update-in-place status board 
> implemented using terminal capabilities.  Jobs push updates into the status 
> board via core.async channels. Handy for really long running commands.
>
>
> https://github.com/walmartlabs/active-status
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Herwig Hochleitner]

2016-02-02 23:34 GMT+01:00 kovas boguta :

>
> In general yes, but there are endless specific ways to do this. Do you
> represent a kv-pair as a single element? Do you have  and  as
> elements? Or do you use the name of the key as the name of the element? And
> then multiply that times the opportunities to use attributes rather than
> elements. I've seen all these variations and more.
>

> In EDN (and JSON) there is a *specific* literal that represents a Map,
> with *defined interfaces and runtime semantics* corresponding to the notion
> of a Map. That there are additional ways to encode the information contents
> of a Map (but losing its runtime semantics) is obviously true and
> irrelevant.
>

In a better world, those alternatives would be equally irrelevant in XML as
well.
It's unfortunate that the preferred representation for kv-types in xml (tag
attributes) is so limited that formats will use tag content, even when
ordering is irrelevant.

Huh? Is there an optimizing XML reader that automagically detects all the
> possible variation of a Map encoding and generates an optimized backing
> datastructure?
>

Let's not conflate the "ground" xml tags and the runtime structures which
they are supposed to map to (this distinction also exists for edn, but is
not pronounced there, since its has everything commonly found in simple
"config" data, did you know that fressian encodes maps as #map [k v k v
...])
When dealing with ground tags generically (like data.xml does), i.e. the
mapped-to structures add no information over the ground tags, I'd say it
would be still pretty easy to create a reader, which uses optimized
structures for content-only, or attribute-only tags and the like. Even
common things like space-separated (class-) lists in attribute tags, ...
Dynamic runtimes can also optimize for object shapes "automagically". For
reference, google optimization tips for v8
Of course, none of this will decide for you that ordering of your child
tags is irrelevant and that it can be used to facilitate O(1) hash-lookup.
Thus it _is_ unfortunate that there exists no accepted standard for
encoding arbitrary associative structures in XML, because it pushes you
towards app-specific representations.

When talking about app-specific structures, which deserialize from xml:
Here you're down to coding against a specific schema and your runtime's
efficiency will be dominated by the pull parser and your builder pattern.

Well, show me an evaluator that directly operates on ascii-serialized EDN
>> (or even binary-serialized fressian) and I'll agree on this.
>>
>
> I'm talking about the programmatic API.
>

In this case, the problem still doesn't go away EDN. Sure, it has more
builtins, but e.g. when working with graphs, I'll still need to know how to
decode my #graph/edgelist [[:a :b 2] [:b :c 1.7] [:c :a #complex [1.7
0.3]], possibly transforming it into a more domain-specific representation
in the process. OTOH when passing around a graph as a blackbox, I'll not
need to know its internal structure in XML or EDN either.

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[kovas boguta]

On Tue, Feb 2, 2016 at 3:45 PM, Herwig Hochleitner 
wrote:
>
> basically attributes, and child elements
>

In general yes, but there are endless specific ways to do this. Do you
represent a kv-pair as a single element? Do you have  and  as
elements? Or do you use the name of the key as the name of the element? And
then multiply that times the opportunities to use attributes rather than
elements. I've seen all these variations and more.

but this is also the case in clojure:
>
> {:key "value" ...} vs [:key "value" ...] vs [[:key "value"] ...]
>

In EDN (and JSON) there is a *specific* literal that represents a Map, with
*defined interfaces and runtime semantics* corresponding to the notion of a
Map. That there are additional ways to encode the information contents of a
Map (but losing its runtime semantics) is obviously true and irrelevant.


Of course, its also a disaster from an efficiency point of view, since
>> there is basically only 1 datastructure.
>>
>
> That's the same as saying: "Dynamic typing is an efficiency disaster,
> because everything derives from the root class". True in a lot of cases,
> but mostly irrelevant + mitigable by PICs and other
> sufficiently-smart-compiler things.
>

Huh? Is there an optimizing XML reader that automagically detects all the
possible variation of a Map encoding and generates an optimized backing
datastructure?

Well, show me an evaluator that directly operates on ascii-serialized EDN
> (or even binary-serialized fressian) and I'll agree on this.
>

I'm talking about the programmatic API.

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Mark Engelberg]

On Tue, Feb 2, 2016 at 2:05 AM, Mikera  wrote:

> I share the same unease. I haven't quite fully been able to articulate all
> the reasons, but here are the things that concern me most:
>
> 1) Completing the API for data access with the representation
> 2) Refactoring challenges
> 3) Performance
>
>
These are legitimate concerns.  The "Clojure way" has a lot of very nice
properties, but you have articulated very well the challenges that come
from working with deeply nested, non-encapsulated data.

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Gary Schiltz]

Joining the "dump on XML" bandwagon, I believe that adoption of RDF and OWL 
a decade ago was greatly hindered by the W3C's decision to embrace XML as 
the serialization mechanism. I suspect I wasn't the only semantic web 
hacker to adopt the much simpler N3 and turtle notations for human 
consumption, and only convert to RDF/XML for consumption by machine.

On Monday, February 1, 2016 at 5:02:23 PM UTC-5, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

-- 
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] walmartlabs/active-status 0.1.2

[Howard Lewis Ship]

Library for allowing a command line application to report status of
multiple asynchronous jobs using an update-in-place status board
implemented using terminal capabilities.  Jobs push updates into the status
board via core.async channels. Handy for really long running commands.


https://github.com/walmartlabs/active-status

-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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: The empty string can become a symbol, but it can't be resolved

[Herwig Hochleitner]

While there is no reader syntax for the empty symbol, I agree that the
StringIndexOutOfBoundsException is wonky and should be fixed. Though some
might view it as a consequence of clojure's GIGO philosophy, I don't concur
with such arguments, because the separation of read and eval is there for a
reason.
Funny: Interning the empty symbol and derefing its var works: @(intern *ns*
(symbol "") "val") evaluates to "val"
I would expect a ticket for this to be accepted, but receive low priority.

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Herwig Hochleitner]

2016-02-02 20:41 GMT+01:00 kovas boguta :

> XML is data, but its data that thwarts easy manipulation from a
> programming language. It doesn't cleanly map onto computational concepts.
>

How so? I mean, rolling key-value access and positional access into a
single data-structure, php-style, isn't the best idea in the world, but
it's not the worst either.
The real problem with XML starts where you can only store strings as
attribute values. This is even more constrained than JSON's
only-string-keys constraint, and leads to ambiguity in  how to properly
encode maps.

Quick: how many ways can you represent key-value pairs in XML?
>

basically attributes, and child elements

but this is also the case in clojure:

{:key "value" ...} vs [:key "value" ...] vs [[:key "value"] ...]

Of course, its also a disaster from an efficiency point of view, since
> there is basically only 1 datastructure.
>

That's the same as saying: "Dynamic typing is an efficiency disaster,
because everything derives from the root class". True in a lot of cases,
but mostly irrelevant + mitigable by PICs and other
sufficiently-smart-compiler things.
To me the one-datastructure thing is just distasteful, because it reminds
me of PHP.

So to use XML, you often first need to convert it to something you can
> actually manipulate, and then back again (and there is no standard way to
> do this). With EDN these problems go away.
>

Well, show me an evaluator that directly operates on ascii-serialized EDN
(or even binary-serialized fressian) and I'll agree on this.
But I guess there isn't such thing. In most cases, the representation of
previously serialized data will be runtime-specific, even if it's just
PersistentVector vs ImmutableArrayList

Enough nitpicking. Ad. Topic:

To me, the real horror of XML is that it pretends to be
ascii-read/writable, but it's just horrible to eye-read and hand-write,
mainly because of the redundancy for start/end tags.
Ironically, this doesn't matter as much for data formats, because people
are happy to use tools to manipulate them. It does matter a lot for code,
because people hate generated source files.
Combine this with unclear mapping conventions, esoteric rules for quoting,
escaping and namespacing + the fact, that even the best XML editors (like
IntelliJ's, emacs' or chrome's devtools) feel quite clumsy

Then, there is also no unifying story for XML-based DSLs, each one has to
roll its own evaluator, and get all the details right, like lexical scope,
loops, performance, ... All while constantly fighting the urge to introduce
cute features just to go with the grain of the horrible base syntax.
Sure, EDN also has no builtin evaluator, but there is at least one
excellent REPL to work with first-class EDN values, then it also supports
arbitrary nesting of structures, there is paredit, .. the lack of those
things in XML adds up quickly.

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[kovas boguta]

XML is data, but its data that thwarts easy manipulation from a programming
language. It doesn't cleanly map onto computational concepts.

Quick: how many ways can you represent key-value pairs in XML?

Of course, its also a disaster from an efficiency point of view, since
there is basically only 1 datastructure.

So to use XML, you often first need to convert it to something you can
actually manipulate, and then back again (and there is no standard way to
do this). With EDN these problems go away.





On Mon, Feb 1, 2016 at 5:02 PM, Josh Tilles 
wrote:

> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
> Distributed Computing for Clojure”
> , I'm distracted by a
> nagging worry that we —as a community— are somehow falling into the same
> trap as the those advocating XML in the early 2000s. That said, it's a very
> *vague* unease, because I don’t know much about why the industry seems to
> have rejected XML as “bad”; by the time I started programming
> professionally there was already a consensus that XML sucked, and that
> libraries/frameworks that relied heavily on XML configuration files were to
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code”
> mentality and the rise of XML? Or, assuming there is a legitimate
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is
> it the case that the widespread backlash against XML threw a baby out with
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>
> --
> 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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Alan Thompson]

I do think the whole "code is data" thing is a bit overstated.

The earliest computers used paper tape for data records:

At Bletchley Park, the "data"  (ciphertext to be broken) was encoded onto
the paper tape in the photo. The "code" was hardwired into the design of
the machine & its electronics, and was most definitely separate from the
"data" on the paper tape.

Later, the first "stored-program" computers used electronic memory to hold
both "code" bits and "data" bits. So one could change both the code and the
data more easily. However, they are both just bits stored in a single
memory system.

A simple program accepts bytes as input and produces bytes as output, then
terminates. Only humans can interpret some bytes as "code" and other bytes
as "data", based on intended future usage. To the computer it has always
been a case of "bytes is bytes".

So, what is the difference between data & code? Code is what is executing
on the CPU; everything else is just data [1]. Some data is never executed.
Because it has no "motion" it is simpler than "code" which is in some sense
alive and in motion and has more ways to cause problems. So, the basic idea
is that "data" is simpler than "code" because "stationary" objects are
simpler (& more predictable) than "moving" objects.

Since we like "simple", there is a preference for data over code for many
uses. However, there are limits.

Consider adding two numbers.  I could give you a lookup table for all
possible pairs of 32-bit integers. I hesitate to estimate the weight of
that much paper!  So, the lookup table is a very costly solution, but one
that is "pure data".

Or, I could give you a simple recipe for calculating the result, which
would fit on one piece of paper. This set of instructions is "code", and is
not as simple as a the lookup table.  It is, however, much cheaper than the
giant lookup table! [2]

The point is that both code and data have value, but they have different
values when applied to different problems. Your goal is *use both of them
in order to solve problems for a minimal cost* (& with a maximal
probability of success!).

Both code and data are valuable tools that we can use to solve problems. It
is only their interpretation by humans and the way they are used by humans
that determines if they are a good tool or bad tool for a given problem.
Also, keep in mind that most problems are best solved by using *many* tools
in different ways and in different amounts. Our job is to find the optimal
combination of all the possible choices.

Alan


[1] Of course, the currently executing code may modify data, which is then
executed later. Hence we have assemblers, compilers, macros, etc.
[2] Notice that both the lookup table "data" and the addition recipe "code"
were delivered to you as ink on paper, analogous to the computer where both
data and code are expressed as bytes.


On Tue, Feb 2, 2016 at 9:37 AM, Frank Castellucci 
wrote:

> Josh
>
> To assume there is/was a problem because someone said so will waste your
> time. Through all the religious zealotry and opposing opinions, my comment
> would be:
>
> "Eschew commentary. View each technology option as a tool in your
> tool-belt, and expand it as time goes on. When the right problem comes
> along, using the right tool regardless of politics will get the job done
> right"
>
>
> On Monday, February 1, 2016 at 5:02:23 PM UTC-5, Josh Tilles wrote:
>>
>> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
>> Distributed Computing for Clojure”
>> , I'm distracted by a
>> nagging worry that we —as a community— are somehow falling into the same
>> trap as the those advocating XML in the early 2000s. That said, it's a very
>> *vague* unease, because I don’t know much about why the industry seems
>> to have rejected XML as “bad”; by the time I started programming
>> professionally there was already a consensus that XML sucked, and that
>> libraries/frameworks that relied heavily on XML configuration files were to
>> be regarded with suspicion and/or distaste.
>>
>> So, am I incorrect in seeing a similarity between the “data > code”
>> mentality and the rise of XML? Or, assuming there is a legitimate
>> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use
>> edn instead of XML sidestep everything that went wrong in the 2000s? Or is
>> it the case that the widespread backlash against XML threw a baby out with
>> the bathwater, forgetting the advantages of data over code?
>>
>> Cheers,
>> Josh
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---

Re: Counting nodes in two seperate subtrees

[Dmitry Lipovoi]

This solution will be quite slow for large N (which is height of the tree).
Even more, you don't have to build and/or traverse a tree to solve this
problem at all.
Hint: number of nodes in full binary tree of height k is 2^{k+1} - 1.


On Tue, Feb 2, 2016 at 8:40 PM, Frank Castellucci 
wrote:

>
> On SO:
> http://stackoverflow.com/questions/35136560/counting-nodes-in-two-different-subtrees-in-clojure
>
>
> On Monday, February 1, 2016 at 1:16:31 PM UTC-5, xCaM wrote:
>>
>> Hi
>>
>> Im trying to write the functions for this probem
>>
>> https://uva.onlinejudge.org/external/116/11615.pdf
>>
>> as i'm new to clojure i have very very limited knowledge of the language
>> and if someone could help me i'd be so grateful
>>
>> Cam
>>
> --
> 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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Gregg Reynolds]

On Mon, Feb 1, 2016 at 4:02 PM, Josh Tilles 
wrote:

> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
> Distributed Computing for Clojure”
> , I'm distracted by a
> nagging worry that we —as a community— are somehow falling into the same
> trap as the those advocating XML in the early 2000s. That said, it's a very
> *vague* unease, because I don’t know much about why the industry seems to
> have rejected XML as “bad”; by the time I started programming
> professionally there was already a consensus that XML sucked, and that
> libraries/frameworks that relied heavily on XML configuration files were to
> be regarded with suspicion and/or distaste.
>

XML was expressly designed for documents and it really has no competition
for serious, professional documentation work.  It's when people started
using it to encode data and code that bad things started to happen.
Classic example of using the wrong tool for the job.


> So, am I incorrect in seeing a similarity between the “data > code”
> mentality and the rise of XML? Or, assuming there is a legitimate
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is
> it the case that the widespread backlash against XML threw a baby out with
> the bathwater, forgetting the advantages of data over code?
>

It's unnecessary to be alarmed.  Of course, you can misuse Clojure/edn just
like you can misuse anything, but there's really no comparison with XML.
Don't forget that maps, keywords, etc. may look like data but they're
really functions - you can treat {} as a data constructor or a (finite)
function constructor.  Or maybe it would be more accurate to say that the
distinction between code and data has always been a side effect of language
designs and implementations, and Clojure goes a long way toward eliminating
it.  I'm not sure what you mean by "data > code mentality", but these days
I often find myself going in the other direction - thinking of my data in
terms of functions and protocols.  With Clojure you can do the right thing,
whatever works best for the problem at hand.

-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: Counting nodes in two seperate subtrees

[Frank Castellucci]

On 
SO: 
http://stackoverflow.com/questions/35136560/counting-nodes-in-two-different-subtrees-in-clojure


On Monday, February 1, 2016 at 1:16:31 PM UTC-5, xCaM wrote:
>
> Hi 
>
> Im trying to write the functions for this probem
>
> https://uva.onlinejudge.org/external/116/11615.pdf
>
> as i'm new to clojure i have very very limited knowledge of the language 
> and if someone could help me i'd be so grateful
>
> Cam 
>

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Frank Castellucci]

Josh

To assume there is/was a problem because someone said so will waste your 
time. Through all the religious zealotry and opposing opinions, my comment 
would be:

"Eschew commentary. View each technology option as a tool in your 
tool-belt, and expand it as time goes on. When the right problem comes 
along, using the right tool regardless of politics will get the job done 
right"


On Monday, February 1, 2016 at 5:02:23 PM UTC-5, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

-- 
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: [ldnclj] Re: Suggestions for open source contributions?

[Jason Felice]

We have a lot of focus on being new-Clojurian and new-programmer friendly
for Avi, including being able to spend a couple hours a week
remote-pairing.  I think this is a good project if the person is familiar
with (or especially fond of) Vim.

https://github.com/maitria/avi

-Jason

On Tue, Feb 2, 2016 at 9:12 AM, Bozhidar Batsov  wrote:

> If you're into tooling - there's always plenty of work to be done on
> cider-nrepl (https://github.com/clojure-emacs/cider-nrepl) :-)
>
> On 2 February 2016 at 10:28, Chris Howe-Jones 
> wrote:
>
>> Another open source library that has some real momentum behind it at the
>> moment is baid-chat https://github.com/braidchat/meta/wiki . It's the
>> Clojure Communities OSS alternative to Slack.
>>
>> Why is it needed? Lots of reasons that are elaborated in the motivations
>> page of the wiki but one of the most urgent is that Slack has adopted a
>> policy of closing community teams to new members once they get large
>> (anecdotally around 7000 members) and the Clojurians Slack channel is
>> already over 4800.
>>
>>
>> On 2 Feb 2016, at 08:22, Mikera  wrote:
>>
>> If you are interested in data science, help with core.matrix and the
>> associated libraries is always appreciated, and we are very
>> contributor-friendly in the numerical Clojure community.
>>
>> On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
>>>
>>> Hey folks!
>>>
>>> Today is the first day nilenso has ever had an intern on-staff. He's
>>> been in the industry for a few years but he's relatively new to Clojure. We
>>> try to ramp people up as slowly and supportively as possible. For interns,
>>> we figure writing (and re-writing, natch) open source is the safest place
>>> to start.
>>>
>>> With that context set, does anyone on the list have suggestions for
>>> projects we can guide him through? We will be working with him through some
>>> the standard Clojure literature over the coming months, as well as
>>> providing guidance with his patches/pull-requests.
>>>
>>> We're open to any shape of project: applications, libraries, tools. If
>>> you have a Clojure project you would like help with (or that you wish
>>> someone would start), we would love to evaluate it as a learning
>>> opportunity.
>>>
>>> Thanks everyone!
>>>
>>> Steven Deobald -- ⌀ -- nilenso.com
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "London Clojurians" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to london-clojurians+unsubscr...@googlegroups.com.
>> To post to this group, send email to london-clojuri...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/london-clojurians.
>> 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.
>

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Laws]

> I don’t know much about why the industry seems to have rejected XML as 
“bad”

Off-topic, but I think 2 issues dominated

1.) Unnecessary complexity in the 
standards: http://harmful.cat-v.org/software/xml/soap/simple

2.) draconian error-checking. I assume the move to JSON was to get away 
from the strict error checking



On Monday, February 1, 2016 at 5:02:23 PM UTC-5, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

-- 
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] boot-criterium 0.2.0 - Tasks that run your benchmarks!

[platonovadim]

Hello all,

we're pleased to announce boot-criterium 
 - a simple way to benchmark code 
using Criterium. 
The only prerequisites are JVM and Boot , 
the glorious build tool.

You can even call it from the command line!

boot -d tulos/boot-criterium \
>   bench -l "1.6" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.6.0 -- \ 
>   bench -l "1.7" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.7.0 -- \ 
>   bench -l "1.8" -g "'(reduce + (range 1000))" -Q -d org.clojure/
clojure:1.8.0 -- \ 
>   report -f table -O 

| :benchmark/goal |  :mean |   :variance |   :upper-q |   :lower-q | :
evaluation-count | :outlier-effect | 
|-++-+++---+-|
 
| 1.6 | 38.2482 µs |   4.2256 µs | 42.7620 µs | 31.0620 µs |   
  18966 |   :moderate | 
| 1.7 | 10.6118 µs |   1.3260 µs | 11.9993 µs |  9.2158 µs |   
  67692 |   :moderate | 
| 1.8 |  9.0259 µs | 525.3190 ns |  9.6581 µs |  8.3780 µs |   
  64428 |   :moderate |


Have fun!

-- 
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: Attempting to call unbound fn

[Gary Verhaegen]

My first step would be to run

lein deps :tree

On the project where the error appears, and look for unexpected versions of
dependencies.

On Monday, 1 February 2016, Pedro Santos  wrote:

> Hello,
>
> I'm referencing a fn on another lib/namespace. Is this one:
>
> https://github.com/clanhr/clanhr-api/blob/master/src/clanhr_api/core.clj#L197
>
> We don't use declare, it's just a "normal" fn. On another project that
> references that fn, we get:
>
> #error {
>  :cause Attempting to call unbound fn:
> #'clanhr-api.core/query-string-builder
>  :via
>  [{:type java.lang.IllegalStateException
>:message Attempting to call unbound fn:
> #'clanhr-api.core/query-string-builder
>:at [clojure.lang.Var$Unbound throwArity Var.java 43]}]
>  :trace
>  [[clojure.lang.Var$Unbound throwArity Var.java 43]
>   [clojure.lang.AFn invoke AFn.java 36]
>   [clanhr.absences_api.core.get_events$query_string_builder invokeStatic
> get_events.clj 4
>
> The "clanhr.absences_api.core.get_events$query_string_builder" is just a
> wrapper that calls the other one.
>
> Any tips on how to troubleshoot this? Running clj 1.8.
>
> --
> Pedro Pereira Santos
> https://twitter.com/donbonifacio
>
> --
> 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: [ldnclj] Re: Suggestions for open source contributions?

[Bozhidar Batsov]

If you're into tooling - there's always plenty of work to be done on
cider-nrepl (https://github.com/clojure-emacs/cider-nrepl) :-)

On 2 February 2016 at 10:28, Chris Howe-Jones 
wrote:

> Another open source library that has some real momentum behind it at the
> moment is baid-chat https://github.com/braidchat/meta/wiki . It's the
> Clojure Communities OSS alternative to Slack.
>
> Why is it needed? Lots of reasons that are elaborated in the motivations
> page of the wiki but one of the most urgent is that Slack has adopted a
> policy of closing community teams to new members once they get large
> (anecdotally around 7000 members) and the Clojurians Slack channel is
> already over 4800.
>
>
> On 2 Feb 2016, at 08:22, Mikera  wrote:
>
> If you are interested in data science, help with core.matrix and the
> associated libraries is always appreciated, and we are very
> contributor-friendly in the numerical Clojure community.
>
> On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
>>
>> Hey folks!
>>
>> Today is the first day nilenso has ever had an intern on-staff. He's been
>> in the industry for a few years but he's relatively new to Clojure. We try
>> to ramp people up as slowly and supportively as possible. For interns, we
>> figure writing (and re-writing, natch) open source is the safest place to
>> start.
>>
>> With that context set, does anyone on the list have suggestions for
>> projects we can guide him through? We will be working with him through some
>> the standard Clojure literature over the coming months, as well as
>> providing guidance with his patches/pull-requests.
>>
>> We're open to any shape of project: applications, libraries, tools. If
>> you have a Clojure project you would like help with (or that you wish
>> someone would start), we would love to evaluate it as a learning
>> opportunity.
>>
>> Thanks everyone!
>>
>> Steven Deobald -- ⌀ -- nilenso.com
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "London Clojurians" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to london-clojurians+unsubscr...@googlegroups.com.
> To post to this group, send email to london-clojuri...@googlegroups.com.
> Visit this group at https://groups.google.com/group/london-clojurians.
> 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: [ldnclj] Re: Suggestions for open source contributions?

[Chris Howe-Jones]

Another open source library that has some real momentum behind it at the moment 
is baid-chat https://github.com/braidchat/meta/wiki 
 . It's the Clojure Communities OSS 
alternative to Slack.

Why is it needed? Lots of reasons that are elaborated in the motivations page 
of the wiki but one of the most urgent is that Slack has adopted a policy of 
closing community teams to new members once they get large (anecdotally around 
7000 members) and the Clojurians Slack channel is already over 4800.


> On 2 Feb 2016, at 08:22, Mikera  wrote:
> 
> If you are interested in data science, help with core.matrix and the 
> associated libraries is always appreciated, and we are very 
> contributor-friendly in the numerical Clojure community.
> 
> On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
> Hey folks!
> 
> Today is the first day nilenso has ever had an intern on-staff. He's been in 
> the industry for a few years but he's relatively new to Clojure. We try to 
> ramp people up as slowly and supportively as possible. For interns, we figure 
> writing (and re-writing, natch) open source is the safest place to start.
> 
> With that context set, does anyone on the list have suggestions for projects 
> we can guide him through? We will be working with him through some the 
> standard Clojure literature over the coming months, as well as providing 
> guidance with his patches/pull-requests.
> 
> We're open to any shape of project: applications, libraries, tools. If you 
> have a Clojure project you would like help with (or that you wish someone 
> would start), we would love to evaluate it as a learning opportunity.
> 
> Thanks everyone!
> 
> Steven Deobald -- ⌀ -- nilenso.com 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "London Clojurians" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to london-clojurians+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to london-clojuri...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/london-clojurians 
> .
> 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.

The empty string can become a symbol, but it can't be resolved

[SanjayL]

Ran into this weird case while writing some test code:

user=> (symbol "")

user=> (symbol? (symbol ""))
true
user=> (ns-resolve *ns* (symbol ""))
StringIndexOutOfBoundsException String index out of range: 0 
 java.lang.String.charAt (String.java:658)

I'm guessing that the ghost symbol should resolve to nil?

Thanks for you help, 
Sanjay

-- 
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] DEEP-IMPACT-AG/flowgic

[Juan A. Ruz @tangrammer]

 

Hi guys, here sharing an (alpha) approach to write logic flows in a 
declarative way

https://github.com/DEEP-IMPACT-AG/flowgic 


One of the final purposes of this utility is to visualise the 
intended/written logic as you can see here 
https://cloud.githubusercontent.com/assets/731829/10277888/8a5bf848-6b59-11e5-96de-1b67fab4981b.png


Looking forward  your impressions and comments ... so I could keep 
improving it


Have a good day!


PS: it uses https://github.com/DEEP-IMPACT-AG/flowgic.graph to 
connect https://github.com/ztellman/rhizome as graph visualisation



-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Colin Yates]

I see the same issues/feel the same pain, but I attribute it much more
to dynamic typing than data. Changing the API is always going to be
expensive but without typing we pretty much to do it without tool
support.

Even in Java and the magic of IDEs there is still pain - changing the
return type of a method from one type to another is still painful -
sure, the IDE will help with the impact analysis but you still have to
work it through.

I think the problem is more exposed as there isn't any indirection
between the thing you want and the getting of the thing you want but
yeah, changing API is hard. Nothing to stop your API being (defn get-a
[m]) if you want that indirection, but that isn't idiomatic.

Performance I can't comment about other than to say for the scale of
projects I am involved with I haven't seen the performance as the
bottleneck.

On 2 February 2016 at 10:05, Mikera  wrote:
> I share the same unease. I haven't quite fully been able to articulate all
> the reasons, but here are the things that concern me most:
>
> 1) Completing the API for data access with the representation
>
> This is my biggest issue. Good practice IMHO is to keep APIs abstracted from
> underlying implementation details. There are many cases where you may want
> to change the underlying data representation without changing the API
> (adding indexing functionality, changing a "stored" value to a "calculated"
> value, caching of repeated values etc.) It is *really* annoying when you
> want to change the internal representation but have the problem of breaking
> all the callers who have hard-coded assumptions about the structure.
>
> 2) Refactoring challenges
>
> It's pretty easy to refactor Java code with modern IDEs - changing method
> names, updating all references etc. Doing this in Clojure when everything is
> represented in nested data structures is a tricky task, because you
> typically don't have the ability to catch all uses of a particular part of a
> data structure. I've lost count of the number of times I have had
> hard-to-track bugs because of changed keywords etc.
>
> This is less of an issue in small projects, but a much bigger issue once you
> have a large project that passed complex values between subsystems.
>
> Furthermore, given that Clojure is a dynamically typed language, you
> typically have more tests to compensate for the lack of type safety being
> enforced by the compiler. Refactoring costs become even greater when you
> need to refactor a large number of tests as well.
>
> 3) Performance
>
> If you express everything in nested data structures, you end up paying
> significant performance overheads
> a) Lack of fast type-based dispatch (you can use defrecord / protocols, but
> then you are going the way of typed records anyway... so it isn't really
> pure data)
> b) Validation at runtime of deeply nested structures is expensive. You often
> have to walk the entire tree to ensure compliance with a specific schema
> c) Inherent overheads of boxing numbers. Less of a big deal for business
> domain objects, but problematic for the data scientists among us.
> d) If your data structure represents "operations" you effectively need to
> write an "interpreter" to execute these. I'd rather have fast compiled code
> :-)
> e) The JVM is very good at optimising method calls / object access access
> when it knows the types. With everything as "Object"... less so. You end up
> with lots of casts and instance checks.
>
> Don't get me wrong, I think that immutable data as values are a great thing
> overall. But I would urge caution about an ideological crusade to "data all
> the things".
>
>
> On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>>
>> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
>> Distributed Computing for Clojure”, I'm distracted by a nagging worry that
>> we —as a community— are somehow falling into the same trap as the those
>> advocating XML in the early 2000s. That said, it's a very vague unease,
>> because I don’t know much about why the industry seems to have rejected XML
>> as “bad”; by the time I started programming professionally there was already
>> a consensus that XML sucked, and that libraries/frameworks that relied
>> heavily on XML configuration files were to be regarded with suspicion and/or
>> distaste.
>>
>> So, am I incorrect in seeing a similarity between the “data > code”
>> mentality and the rise of XML? Or, assuming there is a legitimate parallel,
>> is it perhaps unnecessary to be alarmed? Does the tendency to use edn
>> instead of XML sidestep everything that went wrong in the 2000s? Or is it
>> the case that the widespread backlash against XML threw a baby out with the
>> bathwater, forgetting the advantages of data over code?
>>
>> Cheers,
>> Josh
>
> --
> 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

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Colin Yates]

I think the message is 'data doesn't have to be code' not 'code should
be expressed in data' which is significantly different. XML went wrong
because people tried to write code in XML.

Nobody (I think) is saying explicitly that we should write code, logic
etc. as data only that there is no need to wrap data in code.

Of course, Clojure's/Lisps homoiconicity means the _expression_ of
code is the same _expression_ as data so code can be treated as data.

In concrete terms, sure, XML (and YAML etc.) all tried to capture
logic which failed, that isn't what is being recommended in Clojure.

(if (some-pred? a) (do-this a) (do-that a))
is code that can be treated as data. Where it would go horribly wrong
is if you started trying to impose a DSL on top of this:
{:predicate #(some-pred? a) :predicate-match #(do-this a)
:predicate-fail #(do-that a)}
which is analogous (I think) to where XML etc. went down the rabbit hole.

On 2 February 2016 at 10:05, Mikera  wrote:
> I share the same unease. I haven't quite fully been able to articulate all
> the reasons, but here are the things that concern me most:
>
> 1) Completing the API for data access with the representation
>
> This is my biggest issue. Good practice IMHO is to keep APIs abstracted from
> underlying implementation details. There are many cases where you may want
> to change the underlying data representation without changing the API
> (adding indexing functionality, changing a "stored" value to a "calculated"
> value, caching of repeated values etc.) It is *really* annoying when you
> want to change the internal representation but have the problem of breaking
> all the callers who have hard-coded assumptions about the structure.
>
> 2) Refactoring challenges
>
> It's pretty easy to refactor Java code with modern IDEs - changing method
> names, updating all references etc. Doing this in Clojure when everything is
> represented in nested data structures is a tricky task, because you
> typically don't have the ability to catch all uses of a particular part of a
> data structure. I've lost count of the number of times I have had
> hard-to-track bugs because of changed keywords etc.
>
> This is less of an issue in small projects, but a much bigger issue once you
> have a large project that passed complex values between subsystems.
>
> Furthermore, given that Clojure is a dynamically typed language, you
> typically have more tests to compensate for the lack of type safety being
> enforced by the compiler. Refactoring costs become even greater when you
> need to refactor a large number of tests as well.
>
> 3) Performance
>
> If you express everything in nested data structures, you end up paying
> significant performance overheads
> a) Lack of fast type-based dispatch (you can use defrecord / protocols, but
> then you are going the way of typed records anyway... so it isn't really
> pure data)
> b) Validation at runtime of deeply nested structures is expensive. You often
> have to walk the entire tree to ensure compliance with a specific schema
> c) Inherent overheads of boxing numbers. Less of a big deal for business
> domain objects, but problematic for the data scientists among us.
> d) If your data structure represents "operations" you effectively need to
> write an "interpreter" to execute these. I'd rather have fast compiled code
> :-)
> e) The JVM is very good at optimising method calls / object access access
> when it knows the types. With everything as "Object"... less so. You end up
> with lots of casts and instance checks.
>
> Don't get me wrong, I think that immutable data as values are a great thing
> overall. But I would urge caution about an ideological crusade to "data all
> the things".
>
>
> On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>>
>> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
>> Distributed Computing for Clojure”, I'm distracted by a nagging worry that
>> we —as a community— are somehow falling into the same trap as the those
>> advocating XML in the early 2000s. That said, it's a very vague unease,
>> because I don’t know much about why the industry seems to have rejected XML
>> as “bad”; by the time I started programming professionally there was already
>> a consensus that XML sucked, and that libraries/frameworks that relied
>> heavily on XML configuration files were to be regarded with suspicion and/or
>> distaste.
>>
>> So, am I incorrect in seeing a similarity between the “data > code”
>> mentality and the rise of XML? Or, assuming there is a legitimate parallel,
>> is it perhaps unnecessary to be alarmed? Does the tendency to use edn
>> instead of XML sidestep everything that went wrong in the 2000s? Or is it
>> the case that the widespread backlash against XML threw a baby out with the
>> bathwater, forgetting the advantages of data over code?
>>
>> Cheers,
>> Josh
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Mikera]

I share the same unease. I haven't quite fully been able to articulate all 
the reasons, but here are the things that concern me most:

1) Completing the API for data access with the representation

This is my biggest issue. Good practice IMHO is to keep APIs abstracted 
from underlying implementation details. There are many cases where you may 
want to change the underlying data representation without changing the API 
(adding indexing functionality, changing a "stored" value to a "calculated" 
value, caching of repeated values etc.) It is *really* annoying when you 
want to change the internal representation but have the problem of breaking 
all the callers who have hard-coded assumptions about the structure.

2) Refactoring challenges

It's pretty easy to refactor Java code with modern IDEs - changing method 
names, updating all references etc. Doing this in Clojure when everything 
is represented in nested data structures is a tricky task, because you 
typically don't have the ability to catch all uses of a particular part of 
a data structure. I've lost count of the number of times I have had 
hard-to-track bugs because of changed keywords etc.

This is less of an issue in small projects, but a much bigger issue once 
you have a large project that passed complex values between subsystems.

Furthermore, given that Clojure is a dynamically typed language, you 
typically have more tests to compensate for the lack of type safety being 
enforced by the compiler. Refactoring costs become even greater when you 
need to refactor a large number of tests as well.

3) Performance

If you express everything in nested data structures, you end up paying 
significant performance overheads
a) Lack of fast type-based dispatch (you can use defrecord / protocols, but 
then you are going the way of typed records anyway... so it isn't really 
pure data)
b) Validation at runtime of deeply nested structures is expensive. You 
often have to walk the entire tree to ensure compliance with a specific 
schema
c) Inherent overheads of boxing numbers. Less of a big deal for business 
domain objects, but problematic for the data scientists among us.
d) If your data structure represents "operations" you effectively need to 
write an "interpreter" to execute these. I'd rather have fast compiled code 
:-)
e) The JVM is very good at optimising method calls / object access access 
when it knows the types. With everything as "Object"... less so. You end up 
with lots of casts and instance checks.

Don't get me wrong, I think that immutable data as values are a great thing 
overall. But I would urge caution about an ideological crusade to "data all 
the things".

On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

-- 
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: Suggestions for open source contributions?

[Gregg Reynolds]

On Tue, Feb 2, 2016 at 2:22 AM, Mikera  wrote:

> If you are interested in data science, help with core.matrix and the
> associated libraries is always appreciated, and we are very
> contributor-friendly in the numerical Clojure community.
>

Speaking of which,  the topic of Clojure came up on the Julia mailing list
recently.
One comment was "I suspect the biggest issue is the lack of a good
dataframes library for Clojure,..."  So something along that line would be
a good project.

-- 
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: Power function

[Jon]

Thanks, all of you! I had totally forgotten about this topic. After all, 
it's almost 8 years since I posted my question to this group. ;-)

tirsdag 2. februar 2016 09.24.34 UTC+1 skrev Mikera følgende:
>
> There is a `pow` function in core.matrix, that computes powers over whole 
> arrays at the same time.
>
> Tests / patches to improve this always welcome.
>
> On Tuesday, 3 June 2008 16:55:15 UTC+8, Jon wrote:
>>
>> As I could not find a ** function in boot.clj, I wrote this one: 
>>
>> (defn ** 
>> "nth power of x" 
>> [x n] 
>> (if (== n 0) 
>> 1 
>> (* (if (bit-test n 0) x 1) 
>> (** (* x x) (bit-shift-right n 1)) ) ) ) 
>>
>> In my opinion, it has one weakness: It loops forever when n<0, like in 
>> (** 2 -3). The reason is that (bit-shift-right -1 1) returns -1. 
>> If anybody knows a faster/better Clojure power function, let me 
>> know. ;-) 
>>
>> /Jon
>
>

-- 
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: Power function

[Mikera]

There is a `pow` function in core.matrix, that computes powers over whole 
arrays at the same time.

Tests / patches to improve this always welcome.

On Tuesday, 3 June 2008 16:55:15 UTC+8, Jon wrote:
>
> As I could not find a ** function in boot.clj, I wrote this one: 
>
> (defn ** 
> "nth power of x" 
> [x n] 
> (if (== n 0) 
> 1 
> (* (if (bit-test n 0) x 1) 
> (** (* x x) (bit-shift-right n 1)) ) ) ) 
>
> In my opinion, it has one weakness: It loops forever when n<0, like in 
> (** 2 -3). The reason is that (bit-shift-right -1 1) returns -1. 
> If anybody knows a faster/better Clojure power function, let me 
> know. ;-) 
>
> /Jon

-- 
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: Suggestions for open source contributions?

[Mikera]

If you are interested in data science, help with core.matrix and the 
associated libraries is always appreciated, and we are very 
contributor-friendly in the numerical Clojure community.

On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
>
> Hey folks!
>
> Today is the first day nilenso has ever had an intern on-staff. He's been 
> in the industry for a few years but he's relatively new to Clojure. We try 
> to ramp people up as slowly and supportively as possible. For interns, we 
> figure writing (and re-writing, natch) open source is the safest place to 
> start.
>
> With that context set, does anyone on the list have suggestions for 
> projects we can guide him through? We will be working with him through some 
> the standard Clojure literature over the coming months, as well as 
> providing guidance with his patches/pull-requests.
>
> We're open to any shape of project: applications, libraries, tools. If you 
> have a Clojure project you would like help with (or that you wish someone 
> would start), we would love to evaluate it as a learning opportunity.
>
> Thanks everyone!
>
> Steven Deobald -- ⌀ -- nilenso.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: Complex swap!

[Jochen]

Hi Steve…

thanks for all the pointers. Seems that someone is already on it... :-)

Ciao

…Jochen

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