Re: maintainability, DSLs, declarative APIs, etc.

[Mars0i]

One more point that no one has emphasized: Lisps allow code to write code. 
Sometimes the way to provide an abstraction or generalization of a pattern 
is by writing a code-writer.  Macros provide a convenient way of using that 
capability.  

(On a project years ago, for every Java class of kind X, we needed a 
corresponding Java class of kind Y.  There were many X classes, so I ended 
up writing a Perl script to construct Y source files from X source files.  
It was much easier to do that with Perl than to write a Java 
code-translator.  For an analogous problem with Clojure code, it would be 
even easier use Clojure to generate the new code.)

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

[ANN] Cornet 0.1.0 - Clojure asset pipeline for minification and compilation of LessCSS and CoffeeScript (...more coming soon)

[Marcin Skotniczny]

https://github.com/cosmi/cornet

Cornet is a simple asset pipeline that will help you compile on the flight 
LessCSS, CoffeeScript and minify all your CSSes and JSes.

I wasn't happy with what's already there 
(dieter isn't 
really in spirit of Clojure) - I wanted something simple to use and 
compatible with Compojure. So here it is - my third iteration of the idea.

There's simple basic usage described in the README, but I am really proud 
of the architecture of the library. It is very extendable and can combine 
transformations in any way you want, so I will work on new usage modes if 
needed (or you can figure it out by yourself :) ).

Let me know what you think.

Also, how are you managing this now?


Marcin

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

Re: [ANN] Yesql 0.2.1 - Clojure & SQL queries rethought.

[Gary Johnson]

Hi Kris,

  I really like your approach, but I've also been feeling the burn a bit 
with having to store each SQL query in its own file (especially since my 
data exploration frequently leaves me cataloging hundreds of them). Take a 
look at the approach used in sql-phrasebook:

  https://github.com/ray1729/sql-phrasebook

  I'm hoping it will give you some ideas to extend Yesql to address this 
particular issue, ideally with a nicer syntax than that used in 
sql-phrasebook. Otherwise, I think Yesql is bound for great things!

  Cheers,
~Gary

On Tuesday, November 12, 2013 5:14:14 AM UTC-5, Kris Jenkins wrote:
>
> It depends on which kind of composability you mean. If we're talking about 
> a "SELECT ... FROM ..." here with a "WHERE ..." there, I don't see why not. 
> It's a down-the-road feature, but I'm open to it.
>
> But the kind of composability that would get me excited is the 
> cascalog/datalog kind. Where you could say, "SELECT * FROM employee" and 
> mix that with "SELECT * FROM deparment" and get an automatic, 
> sensibly-optimised join. That's real composibility, beyond mere string 
> concatenation. No, I don't see Yesql ever supporting that. (There again, I 
> haven't seen it from any of the Clojure-SQL-DSLs either. If you have, 
> please point me to them. I'd be interested!)
>
> Cheers,
> Kris
>
> On Tuesday, 12 November 2013 03:35:46 UTC, John Hume wrote:
>>
>> For me, the one feature that can justify an internal DSL for generating 
>> SQL is the ability to compose queries. I assume that's not on the Yesql 
>> roadmap. 
>> On Nov 11, 2013 5:10 AM, "Kris Jenkins"  wrote:
>>
>>> https://github.com/krisajenkins/yesql
>>>
>>> Yesql is a simple library for blending SQL & Clojure together, cleanly. 
>>> Here's how it works , 
>>> and how to use it .
>>>
>>> Feedback welcomed,
>>> Kris
>>>
>>> -- 
>>> -- 
>>> 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/groups/opt_out.
>>>
>>

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

Re: maintainability, DSLs, declarative APIs, etc.

[James Reeves]

The first rule of macro club is "Don't write macros."

Macros are powerful, but they should be considered the last avenue of
attack. Often macros are a slim wrapper around an API made out of
functions, and there just to provide some syntax sugar.

Libraries that use macros more extensively, like core.logic, or the "go"
form in core.async, are relatively rare, and cover the cases where nothing
else but macros are powerful enough to implement the desired functionality.

Instead, it's far better to start with a data-driven approach. A data
structure is always preferable over an API, and an API is always preferable
over a DSL.

This approach can be seen in Datomic, which uses data structures to
represent queries and commands, or Ring, where data structures are used to
represent HTTP requests and responses. Clojure heavily emphasises data, far
more than most other languages, and certainly more than OOP.

- James


On 15 November 2013 19:51, Brian Craft  wrote:

> Pulling this from another thread:
>
> On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:
>
> The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no
> magic (Python). This probably comes down to personal preference, and so is
> a potential benefit of any of them, depending on your preference, but it's
> a significant difference, so it's worth pointing out. By "magic" I just
> mean when the system seems to be more doing something much more powerful
> than you can readily see just by looking at the code. A simple few lines of
> code are doing all these wondrous things that aren't spelled out completely
> in the code (unless you peek under the covers and can understand the black
> arts that lie there). In Ruby/Rails this is the result of a lot of
> metaprogramming happening, based on conventions (that must be learned). In
> Clojure this happens through macros that implement powerful DSLs. In
> Python, it doesn't happen nearly as much. Code tends to be more transparent.
>
>
>
> This description of ruby, clojure, and python very much matches my
> experience (though with ruby I'm relying on the accounts of other
> developers that I know, since I haven't personally used ruby).
>
> Why are black arts and opaque code desirable? It's almost a tautology that
> these things are unmaintainable: you can't maintain code if you can't
> readily understand it, e.g. if it depends on "black arts", or is not
> transparent.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: maintainability, DSLs, declarative APIs, etc.

[Jay Fields]

On Fri, Nov 15, 2013 at 3:30 PM, Brian Craft  wrote:
> I've heard people doing contract work in ruby swearing when
> they encounter another DSL: it kills their productivity.
>

those same people wouldn't have Ruby contracting work if it weren't
for metaprogramming...

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

Re: maintainability, DSLs, declarative APIs, etc.

[Brian Craft]

On Friday, November 15, 2013 12:10:59 PM UTC-8, Karsten Schmidt wrote:
>
> To me macros & DSLs are just an instance/extension of the DRY principle 
> and not that much different to using functions (albeit with more syntactic 
> freedom, e.g. by supplying a body expression to be wrapped or transformed 
> into something more complex). Of course there's the potential loss of 
> control & understanding when using 3rd party macros, but in Clojure the use 
> of library macros is often hardly enforced without also having a purely 
> functional way as alternative. I think the stronger reliance on certain 
> naming conventions (e.g. in RoR) or the type specific overriding of 
> operators in C++ has much more of a magical/mysterious element to it than 
> most of the CLJ macros I've been using thus far. Last but not least, since 
> most libs are open source, what stops you from studying a specific 
> macro/DSL?
>

Thanks for your perspective. Regarding the last question, it's a matter of 
scaling. Often in production code you have to be in and out of an 
unfamiliar piece of code in a few hours. You can't stop to study an 
unfamiliar DSL for a couple days. I've heard people doing contract work in 
ruby swearing when they encounter another DSL: it kills their productivity.

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

Re: What does Clojure get from Java 8?

[Andy Fingerhut]

There are only two changes I am aware of for JDK8 preparation so far, and
they are simply to allow Clojure to compile without warnings [1] and pass
all of the unit tests without failure when using JDK8 [2].  These are minor
changes.

[1] http://dev.clojure.org/jira/browse/CLJ-1264
[2] http://dev.clojure.org/jira/browse/CLJ-1246

[2] was really an existing issue before JDK8 -- it is simply that a change
in the annotations of the Java class library caused the problem to be
exposed with the existing unit tests when run on JDK 8.

Andy


On Fri, Nov 15, 2013 at 11:54 AM, Charles Harvey III <
charlesnhar...@gmail.com> wrote:

> I had read that the Clojure team was prepping the build to work on the new
> JDK8 and it got me to thinking - what does Clojure get from Java 8? Will it
> be using some of the new features or does the compiler just need to be
> ready for changes in the JDK so compilation passes? Clojure already has
> much of what Java 8 is delivering, so will it switch its internals to using
> the Java internals or just leave it alone?
>
> Again, just curious. 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/groups/opt_out.
>

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

Re: maintainability, DSLs, declarative APIs, etc.

[Jay Fields]

I've worked extensively in Java, Ruby, and Clojure, so I have plenty
of experience with having and not having meta-programming and macros.
In my opinion meta-programming and macros are not black art, they are
simply part of the language. If someone chooses to do something that
isn't easy to understand, that's not the fault of the language, it's
the fault of the programmer.

(this is the royal You, not Brian)
Your language choice should probably factor in your desire to dig into
metaprogramming or macros. You don't need to use those features of the
language in your own code, but you'll surely run into both using
someone else's framework or library. If you prefer not to deal with
the complexities that can arise from having those features available,
not using Ruby or Clojure is probably a good choice. Conversely, if
you want the power of metaprogramming and macros, and are willing to
learn them deeply enough that you can deal with some poorly written
metaprogramming or macros, then you should prefer Ruby or Clojure.
Better to have the ability when you desire it, than not to have it -
if you're willing to put up with other people (ab)using that power at
times.

It's a balance, and I strongly believe that people program in many
different ways. (among other tradeoffs) You can have a powerful IDE
and a ton of boiler plate, explicit code, or you can have little
refactoring support and the ability to eliminate the boiler plate
code; you have to chose which you value more. You also need to know
that the choice you make will eliminate working with some people -
those that choose the other way. Neither group of people will be good
or bad, both will have great and terrible programmers who simply
prefer to program in differing ways.

On Fri, Nov 15, 2013 at 2:51 PM, Brian Craft  wrote:
> Pulling this from another thread:
>
> On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:
>
> The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no
> magic (Python). This probably comes down to personal preference, and so is a
> potential benefit of any of them, depending on your preference, but it's a
> significant difference, so it's worth pointing out. By "magic" I just mean
> when the system seems to be more doing something much more powerful than you
> can readily see just by looking at the code. A simple few lines of code are
> doing all these wondrous things that aren't spelled out completely in the
> code (unless you peek under the covers and can understand the black arts
> that lie there). In Ruby/Rails this is the result of a lot of
> metaprogramming happening, based on conventions (that must be learned). In
> Clojure this happens through macros that implement powerful DSLs. In Python,
> it doesn't happen nearly as much. Code tends to be more transparent.
>
>
>
> This description of ruby, clojure, and python very much matches my
> experience (though with ruby I'm relying on the accounts of other developers
> that I know, since I haven't personally used ruby).
>
> Why are black arts and opaque code desirable? It's almost a tautology that
> these things are unmaintainable: you can't maintain code if you can't
> readily understand it, e.g. if it depends on "black arts", or is not
> transparent.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: maintainability, DSLs, declarative APIs, etc.

[Karsten Schmidt]

To me macros & DSLs are just an instance/extension of the DRY principle and
not that much different to using functions (albeit with more syntactic
freedom, e.g. by supplying a body expression to be wrapped or transformed
into something more complex). Of course there's the potential loss of
control & understanding when using 3rd party macros, but in Clojure the use
of library macros is often hardly enforced without also having a purely
functional way as alternative. I think the stronger reliance on certain
naming conventions (e.g. in RoR) or the type specific overriding of
operators in C++ has much more of a magical/mysterious element to it than
most of the CLJ macros I've been using thus far. Last but not least, since
most libs are open source, what stops you from studying a specific
macro/DSL?

My 2p...
On 15 Nov 2013 19:51, "Brian Craft"  wrote:

> Pulling this from another thread:
>
> On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:
>
> The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no
> magic (Python). This probably comes down to personal preference, and so is
> a potential benefit of any of them, depending on your preference, but it's
> a significant difference, so it's worth pointing out. By "magic" I just
> mean when the system seems to be more doing something much more powerful
> than you can readily see just by looking at the code. A simple few lines of
> code are doing all these wondrous things that aren't spelled out completely
> in the code (unless you peek under the covers and can understand the black
> arts that lie there). In Ruby/Rails this is the result of a lot of
> metaprogramming happening, based on conventions (that must be learned). In
> Clojure this happens through macros that implement powerful DSLs. In
> Python, it doesn't happen nearly as much. Code tends to be more transparent.
>
>
>
> This description of ruby, clojure, and python very much matches my
> experience (though with ruby I'm relying on the accounts of other
> developers that I know, since I haven't personally used ruby).
>
> Why are black arts and opaque code desirable? It's almost a tautology that
> these things are unmaintainable: you can't maintain code if you can't
> readily understand it, e.g. if it depends on "black arts", or is not
> transparent.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

What does Clojure get from Java 8?

[Charles Harvey III]

I had read that the Clojure team was prepping the build to work on the new 
JDK8 and it got me to thinking - what does Clojure get from Java 8? Will it 
be using some of the new features or does the compiler just need to be 
ready for changes in the JDK so compilation passes? Clojure already has 
much of what Java 8 is delivering, so will it switch its internals to using 
the Java internals or just leave it alone?

Again, just curious. 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/groups/opt_out.

maintainability, DSLs, declarative APIs, etc.

[Brian Craft]

Pulling this from another thread:

On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:

The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no 
magic (Python). This probably comes down to personal preference, and so is 
a potential benefit of any of them, depending on your preference, but it's 
a significant difference, so it's worth pointing out. By "magic" I just 
mean when the system seems to be more doing something much more powerful 
than you can readily see just by looking at the code. A simple few lines of 
code are doing all these wondrous things that aren't spelled out completely 
in the code (unless you peek under the covers and can understand the black 
arts that lie there). In Ruby/Rails this is the result of a lot of 
metaprogramming happening, based on conventions (that must be learned). In 
Clojure this happens through macros that implement powerful DSLs. In 
Python, it doesn't happen nearly as much. Code tends to be more transparent.



This description of ruby, clojure, and python very much matches my 
experience (though with ruby I'm relying on the accounts of other 
developers that I know, since I haven't personally used ruby).

Why are black arts and opaque code desirable? It's almost a tautology that 
these things are unmaintainable: you can't maintain code if you can't 
readily understand it, e.g. if it depends on "black arts", or is not 
transparent.

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

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

And yes, you could still customize by overriding the templates in their new 
path (which all being under _admin would not reasonably conflict with an 
app that intends to use the admin).

On Friday, November 15, 2013 10:20:25 AM UTC-8, Justin Smith wrote:
>
> Yes, I've made significant progress in moving the templates, but a few of 
> the field editing partials are not accounted for yet. Right now most of the 
> admin works in the new branch, but a few of the field editors have some 
> errors introduced. You are welcome to check out the namespaced-templates 
> branch of the caribou-admin 
> projectif 
> you would like to help and submit a pull request.
>
> On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote:
>>
>> Justin Smith  writes: 
>>
>> Hi Justin, 
>>
>> > The your own resources subdirectory is merged over the admin one, the 
>> > structure visible here: caribou admin 
>> > templates<
>> https://github.com/caribou/caribou-admin/tree/master/resources/templates> 
>>
>>
>> Ok, thanks for the clarification.  At least login and logout seem like 
>> very likely names to be picked by users, too. 
>>
>> > Update: I have created a namespaced-templates branch of caribou-admin, 
>> > and the fix actually looks like it will be a shallow change (if 
>> > moderately tedious given our lack of relative partial paths in 
>> > templates which gives me another idea...). 
>>
>> That looks like a good change to me.  If I'm right, I can still override 
>> admin templates by creating a _admin/login.html for example, right? 
>>
>> Bye, 
>> Tassilo 
>>
>

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

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

Yes, I've made significant progress in moving the templates, but a few of 
the field editing partials are not accounted for yet. Right now most of the 
admin works in the new branch, but a few of the field editors have some 
errors introduced. You are welcome to check out the namespaced-templates 
branch of the caribou-admin 
projectif 
you would like to help and submit a pull request.

On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote:
>
> Justin Smith > writes: 
>
> Hi Justin, 
>
> > The your own resources subdirectory is merged over the admin one, the 
> > structure visible here: caribou admin 
> > templates<
> https://github.com/caribou/caribou-admin/tree/master/resources/templates> 
>
> Ok, thanks for the clarification.  At least login and logout seem like 
> very likely names to be picked by users, too. 
>
> > Update: I have created a namespaced-templates branch of caribou-admin, 
> > and the fix actually looks like it will be a shallow change (if 
> > moderately tedious given our lack of relative partial paths in 
> > templates which gives me another idea...). 
>
> That looks like a good change to me.  If I'm right, I can still override 
> admin templates by creating a _admin/login.html for example, right? 
>
> Bye, 
> Tassilo 
>

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

Re: Caribou: custom templates shadow _admin templates

[Tassilo Horn]

Justin Smith  writes:

Hi Justin,

> The your own resources subdirectory is merged over the admin one, the
> structure visible here: caribou admin
> templates

Ok, thanks for the clarification.  At least login and logout seem like
very likely names to be picked by users, too.

> Update: I have created a namespaced-templates branch of caribou-admin,
> and the fix actually looks like it will be a shallow change (if
> moderately tedious given our lack of relative partial paths in
> templates which gives me another idea...).

That looks like a good change to me.  If I'm right, I can still override
admin templates by creating a _admin/login.html for example, right?

Bye,
Tassilo

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

Re: A Design (Simplification) Problem

[Oskar Kvist]

Thank you everyone for your input!

@James

Hm, I think I understand what you mean. Interesing idea, I will think some 
more about it.

@Sacha

Ah, yes, of course. I don't know why I didn't think of it. Probably because 
I had I similar idea when I first started out but discarded it for some 
forgotten reason. But this is probably the way I'll go.

@Cedric

I had not thought about that. Although it would not work out so well in my 
game, it's an interesing idea.

Thanks again to you all!

On Wednesday, November 13, 2013 8:30:45 PM UTC+1, Cedric Greevey wrote:
>
> One might also wish to consider a "pull" model, in which clients 
> explicitly request information they need from the server. A client could 
> ask for an object's health, given its ID; or for the current ids and 
> positions of monsters in a particular small geographical area (which the 
> server would look up using interval trees).
>
>
> On Wed, Nov 13, 2013 at 1:46 PM, Phlex >wrote:
>
>> Instead of making changes to your data structure, then creating an event, 
>> you could :
>> -create a modification command as a data structure {:type :move 
>> :character-id 12 :move-to {some coords..}}
>> -apply it to your data structure (each and every modification to the data 
>> structure would have to be done via those commands)
>> -send it to the client as an event (some filtering might be in order)
>>
>> This way you have a clear way to channel all your commands to your world, 
>> a clean separation between command, world and client. A clean interface to 
>> your world and finally a clean wire protocol  ! (and easy logging, replay 
>> from save point etc...)
>>
>> Sacha
>>
>>
>>
>> -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

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

Re: How could you solve this problem

[Leon Grapenthin]

Round Robin: In case you are new to Clojure, I have written extended 
commentary of my implementation here: 
http://programmers.stackexchange.com/questions/194487/ring-of-numbers-where-adjacent-entries-sum-up-to-a-prime/218470#218470,
 
were somebody else asked about the problem in April.

On Tuesday, November 12, 2013 11:39:18 PM UTC+1, Round Robin wrote:
>
> Can anyone help me solving this problem in clojure 1196 - Ring of Primes 
> http://coj.uci.cu/24h/problem.xhtml?abb=1196
>

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

Re: Do web apps need Clojure?

[Marcus Blankenship]

Thanks Sean, wonderful input!  

On Nov 14, 2013, at 2:28 AM, Sean Johnson  wrote:

> I'm a "Rails guy" who now uses Clojure for all new web development, so don't 
> take what I'm about to say as disagreeing with Justin. 
> 
> As someone with a foot firmly in both worlds, a couple of Justin's points 
> aren't really marks in Clojure's favor, at least compared to Ruby/Rails (I 
> can't say as much about Python/Django). I also have a few other benefits to 
> bring up that Justin didn't:
> 
> Clojure provides execution efficiency that Ruby or Python cannot match. This 
> translates to lowered hosting costs.
> 
> Agreed. This is a huge point. And not just in lowered hosting costs, but also 
> potentially a better user experience (lower latency).
>  
> The lein tool provides very clean and isolated dependency management, that 
> makes setting up dev environments and deployment very straightforward.
> 
> The pair of Bundler/rake does this very effectively for  Ruby.
> 
> Targeting the JVM means that each deploy can be a single jar or war file that 
> you upload to the server.
> 
> True. Clojure offers potentially much simpler deployment schemes, but if this 
> is important to you, there's JRuby.
>  
> The ring middleware system is a very clean way of including functionality in 
> an app.
> 
> Rack is every bit as clean in the Ruby world.
>  
> Working with immutable data structures and threadsafe bindings as a pervasive 
> default does a lot for stability, and rules out many of the round about ways 
> one of heisenbugs end up in the system.
> 
> True, but this comes up less frequently than you might expect with the 
> typical web app. With the stateless nature of HTTP, and the MVC (of a sort) 
> convention of Rail/Django, typical web app code in these frameworks ends up 
> being more short lived, imperative, and object based in nature rather than 
> long running, object-oriented, and stateful.
> 
> Here are several additional points to consider:
> 
> Conciseness. Terseness. Or to put a more positive spin on it, expressiveness. 
> Idiomatic Clojure is more concise than idiomatic Ruby or Python. I find that 
> having 2x or less code to implement the same functionality to be very 
> refreshing and empowering. Big Rails/Django apps suffer entropy much faster 
> than comparable Clojure apps.
> 
> Full-stack with ClojureScript. The ability to code all in one language, and 
> to share code between client and server, is quite nice compared to 
> Ruby/JavaScript, Ruby/CoffeeScript. It's one small reason node.js has gained 
> momentum so quickly.
> 
> Neither Rails nor Django has a robust, mature threading story. Both achieve 
> concurrency primarily through many processes. This can eat through memory on 
> your hosts quickly as the footprint for Rails and Django themselves is not 
> small and is replicated in each process. This comes up as you end up serving 
> web requests to multiple processes to concurrently, and end up with a many 
> processes model for working background requests. This has gotten a bit better 
> in the Ruby/Rails world as Rails is now thread safe and so can be run 
> multithreaded in alternative Ruby implementations (other than MRI), and 
> Sidekiq has come on the scene for background work, and it leverages 
> Celluloid's actor implementation, borrowed from Erlang, to provide 
> multi-threaded Rails workers. Django has celery but I think that's still 
> process based like resque is in the Ruby world. Not positive, but I don't 
> think Django is threadsafe though.
> 
> Framework vs. ecosystem of interoperable libraries. The monolithic framework 
> (see Rails and Django) is not the way web development is done in Clojure. 
> Instead imagine the Clojure world as a set of legos. You get to build 
> whatever you want with your legos, selecting just the blocks you need, in the 
> colors and sizes you want, and they all snap together [1]. The benefit to 
> this approach is simplicity. There is a LOT to know about the Rails and 
> Django frameworks, as they are big, mature things that have grown to solve 
> all the common web development needs, and you start your development with ALL 
> of that framework. Your starting point with Clojure on the other hand is much 
> simpler. It will seem too simple... at first you'll be wondering... where is 
> all the "stuff"? You start with maybe just ring and compojure (web middleware 
> and routing) and a few lines of your code and your first couple of stories 
> are already complete. You add libraries as you find you need them as you 
> build out your app over time, but at all times your app is as simple as it 
> can be, and only has the "stuff" it needs. It's therefore much easier to 
> understand and less a "big ball of mud".
> 
> The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no 
> magic (Python). This probably comes down to personal preference, and so is a 
> potential benefit of any of them, depending on your preference, but it's a 
> signif

Re: Do web apps need Clojure?

[Marcus Blankenship]

Me too!  Thanks to everyone who’s contributed, it’s been *very* helpful!

On Nov 14, 2013, at 10:43 AM, Waldemar Schwan  
wrote:

> I just want to say that this is one of the most interesting discussions I 
> followed on this mailing list.
> 
> Thanks to all participants.
> 
> Am 14.11.2013 um 19:24 schrieb Brian Craft :
> 
>> 
>> 
>> On Thursday, November 14, 2013 9:42:52 AM UTC-8, Jonathan Irving wrote:
>> I agree with much of what you write James - I'm paid to write rails and 
>> node.js code, and I'm finding that node is encouraging me to compose 
>> small components and basically sidestep a lot of the issues that rails 
>> is designed to address. 
>> 
>> Can you give a concrete example? 
>> 
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

Update: I have created a namespaced-templates branch of caribou-admin, and 
the fix actually looks like it will be a shallow change (if moderately 
tedious given our lack of relative partial paths in templates which gives 
me another idea...).

On Friday, November 15, 2013 6:36:30 AM UTC-8, Justin Smith wrote:
>
> The your own resources subdirectory is merged over the admin one, the 
> structure visible here: caribou admin 
> templates
>
> And yes, anything which has the same directory structure in your project 
> is merged over the admin templates (this is useful for per-project 
> customization, in my experience).
>
> The javascript and css are stashed under resources/public/_admin/, and it 
> would probably be a good idea to move all the admin templates under a 
> unique subdirectory as well, but it is a more complex change. I am 
> seriously considering creating a templates/_admin/ and bumping all admin 
> templates under that path.
>
> On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
>>
>> Hi all, 
>>
>> I'm just toying around with Caribou.  I successfully created the models 
>> of my toy app, and now I started defining routes, pages, and templates. 
>> I started with this: 
>>
>> --8<---cut here---start->8--- 
>> (def routes 
>>   [["/":home 
>> [["login"  :login   []) 
>>
>> (def pages 
>>   {:home  {:GET {:controller 'home  :action 'home  :template 
>> "home.html"}} 
>>:login {:GET {:controller 'login :action 'login :template 
>> "login.html"}}}) 
>> --8<---cut here---end--->8--- 
>>
>> And wow, indeed http://localhost:3/login now shows the page 
>> generated by filling out the login.html template like my login action 
>> said. 
>>
>> However, that has also broken the Admin login page.  Visiting 
>> http://localhost:3/_admin/login now also shows my custom login page, 
>> but the template variables aren't filled out (because that's rendered by 
>> the admin controller, not my controller). 
>>
>> So it seems that template names have to be unique and in order not to 
>> interfere with Admin templates.  Is that intended?  I guess no... 
>>
>> For the time being, I'll prefix my custom templates with the project 
>> name in order to have them unique. 
>>
>> Bye, 
>> Tassilo 
>>
>

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

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

The your own resources subdirectory is merged over the admin one, the 
structure visible here: caribou admin 
templates

And yes, anything which has the same directory structure in your project is 
merged over the admin templates (this is useful for per-project 
customization, in my experience).

The javascript and css are stashed under resources/public/_admin/, and it 
would probably be a good idea to move all the admin templates under a 
unique subdirectory as well, but it is a more complex change. I am 
seriously considering creating a templates/_admin/ and bumping all admin 
templates under that path.

On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
>
> Hi all, 
>
> I'm just toying around with Caribou.  I successfully created the models 
> of my toy app, and now I started defining routes, pages, and templates. 
> I started with this: 
>
> --8<---cut here---start->8--- 
> (def routes 
>   [["/":home 
> [["login"  :login   []) 
>
> (def pages 
>   {:home  {:GET {:controller 'home  :action 'home  :template "home.html"}} 
>:login {:GET {:controller 'login :action 'login :template 
> "login.html"}}}) 
> --8<---cut here---end--->8--- 
>
> And wow, indeed http://localhost:3/login now shows the page 
> generated by filling out the login.html template like my login action 
> said. 
>
> However, that has also broken the Admin login page.  Visiting 
> http://localhost:3/_admin/login now also shows my custom login page, 
> but the template variables aren't filled out (because that's rendered by 
> the admin controller, not my controller). 
>
> So it seems that template names have to be unique and in order not to 
> interfere with Admin templates.  Is that intended?  I guess no... 
>
> For the time being, I'll prefix my custom templates with the project 
> name in order to have them unique. 
>
> Bye, 
> Tassilo 
>

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

Caribou: custom templates shadow _admin templates

[Tassilo Horn]

Hi all,

I'm just toying around with Caribou.  I successfully created the models
of my toy app, and now I started defining routes, pages, and templates.
I started with this:

--8<---cut here---start->8---
(def routes
  [["/":home
[["login"  :login   [])

(def pages
  {:home  {:GET {:controller 'home  :action 'home  :template "home.html"}}
   :login {:GET {:controller 'login :action 'login :template "login.html"}}})
--8<---cut here---end--->8---

And wow, indeed http://localhost:3/login now shows the page
generated by filling out the login.html template like my login action
said.

However, that has also broken the Admin login page.  Visiting
http://localhost:3/_admin/login now also shows my custom login page,
but the template variables aren't filled out (because that's rendered by
the admin controller, not my controller).

So it seems that template names have to be unique and in order not to
interfere with Admin templates.  Is that intended?  I guess no...

For the time being, I'll prefix my custom templates with the project
name in order to have them unique.

Bye,
Tassilo

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

Re: Clojure Users Group - Denmark

[Krukow]

On Thursday, November 14, 2013 11:40:08 PM UTC+1, Jacob Mortensen wrote:
>
> I do clojure+clojurescript hobby programming at home. I live in 
> copenhagen. It seems there is a clojure user group here in copenhagen, but 
> I havent been able to locate it.
>


We've started to write some of the concurrent infrastructure in Xamarin 
Test Cloud in Clojure. 

I know YouSee is using Clojure in at least one project.

- Karl

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