[ANN] Clojure 1.9.0-alpha20

[Joel Holdbrooks]

Are there any plans to make the ## reader macro extensible in the future?

-- 
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: remote - DSL for clj-http/cljs-http

[Joel Holdbrooks]

Are you tired of writing the same clj-http/cljs-https boilerplate? Looking 
for an easy way to express an endpoint or a service API? Then "remote" is 
the library for you!

Github: https://github.com/outpace/remote
Leiningen: [com.outpace/remote "0.3.1"]

This library has been closed source up until now and by popular demand has 
been made available to the public. On behalf of the Outpace staff and 
myself we hope you or your team find this library useful.

Thanks!

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

Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

On Saturday, April 11, 2015 at 8:40:07 AM UTC-7, kovas boguta wrote:
> On Sat, Apr 11, 2015 at 10:46 AM, Malcolm Sparks  
> 
> So, in summary, I think it would be useful to have a single 'default' routing 
> library in Clojure that supported isomorphism and was built on protocols, as 
> a minimum. Now that Clojure is attracting so many new users, it would be 
> great to discuss the outstanding differences between all the routing 
> libraries and try to drive some consensus as to what a combined library would 
> include.
> 
> 
> I'm on board with most of this post (and the Bidi approach in particular), 
> I'm not sure consensus is necessary but I'll throw in my 2 cents. 
> 
> 
> - Please, no more defroute etc macros 
> - Routing should be composable. I want to take some routes and just plug them 
> in at some level of my existing hierarchy. 
> - Middleware should be decoupled from the routes as much as possible. The 
> process for associating middleware to the request should be 
> parallel/complementary to resolving the resource. Maybe "middleware" is not 
> the best concept to begin with. 
>  

I'm definitely in agreement that the approach Bidi and Silk have taken is much 
better than what exists on master in Secretary. Most of the undesirable aspects 
pointed out about Secretary have largely been resolved on the 2.0.0 branch for 
Secretary. The other desirable qualities found in Silk (unsure about Bidi) have 
been in existence in Secretary for sometime but the library was not oriented 
properly to make those features "idiomatic".

I do not agree that "defroute etc macros" should be eliminated from the 
picture. There is nothing inherently wrong with authoring and/or encouraging 
their use. It is only an issue when those macros are the only way to use a 
library effectively. People enjoy using DSL's (until they hit a wall with them) 
and for small to medium scale projects they are completely appropriate and just 
as effective as the "it's just data" style of routing for "getting shit done."

I will also say the same about middleware. Although I do not like the 
middleware pattern I do not believe it is worth throwing out the window just 
because it is "not the best concept." It is a familiar pattern and sometimes 
that familiarity is worth avoiding the friction of learning a something else 
for some individuals and teams.

tl;dr retaining features that people enjoy using and are familiar with is fine 
so long as there is a composable API underneath it that can be used 
alternatively.

-- 
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: State of Clojure/ClojureScript 2014 survey results

[Joel Holdbrooks]

On Thursday, October 23, 2014 8:59:21 AM UTC-7, Alex Miller wrote:
> I've published links to the State of Clojure and ClojureScript 2014 survey 
> results here:
> http://blog.cognitect.com/blog/2014/10/20/results-of-2014-state-of-clojure-and-clojurescript-survey
> 
> 
> 
> That page links to some reports with graphs where you can also export the raw 
> data. I also have links to broken out answers from each of the open text 
> questions for easier consumption. Those are redundant, but perhaps useful. 
> 
> 
> I have not had the time to do any analysis or commentary on these yet. Of 
> particular interest in a few questions are comparisons with prior years which 
> are also linked from the post.
> 
> 
> Big thanks to everyone that participated - it's invaluable to get this 
> snapshot of the community every year, especially as we grow.
> 
> 
> Alex

I missed the survey but I'm curious; why was there no response bubble for 
"Error Messages" in the "What has been most frustrating..." section. It is 
apparent from scanning the responses "debugging" and "error messages" are a 
source of pain for many developers.

-- 
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] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

I'm in agreement that Silk is a step in the right direction. I've reached out 
to Dom and I think we can learn a lot from each other and work together to 
improve the routing story in Clojure overall.

> There are some really good things in secretary. What do you think about them? 
> Splat, regex, format matchers. 
> protocol based render function for multiple arity "unmatching." this is 
> really great. 

These are definitely nice things and I'm willing to bet Silk would be capable 
of supporting some of them.

It's obvious to me to that if we can iron out the details with Silk, Secretary 
could built on top of it as a higher level interface while at the same time 
taking advantage of what Silk has to offer. It might mean some breaking changes 
in Secretary but those were already slated anyway.

-- 
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] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

> Bidirectional routes are indeed especially important to render and dispatch 
> routes in Om etc. In secretary its a bit awkward since you have to write 
> stuff like (defroute front-page "/" [] :front-page) and then a separate 
> thingie for matching the keywords back to the routes.

We have written several Om applications at work and this style of routing has 
never been a source of problems. The `defroute` macros does , perhaps 
unfortunately, provide the dual concern of adding a route to the global routes 
(which we plan to remove) and, optionally, giving you a route generator 
function if you name it (which we'll probably keep). We added this additional 
option because we felt that these two concerns came up frequently enough in the 
same context that it should just be convenient to do them at the same time. 
That is to say, every time we created a route we would have a function for 
generating a url to go with it.

> On the other hand secretary will probably serve non-React apps well with its 
> dispatch actions when you dont have React lifecycle methods.

I think this observation is a bit misguided. We have actually found Secretary 
to be solid in practice and that it works *very* well with Om and React. If you 
interpret route changes as a top level state transition this becomes easy to 
recognize.

Each of our routing functions returns all of the data necessary to transition 
the app to the next state such as route parameters, view name, etc. Since 
secretary/dispatch! returns the result of the routing function, we can pass 
that data to a transition function which handles the actual mutation of the 
global application state. Each view name is mapped to a component which then 
receives the application state, so and so forth. This allows us to treat each 
of our main views as if they were pages (except much better, of course).

This actually fits in with the lifecycle perfectly because the 
mounting/unmounting for a "view" component can be thought of as visiting and 
leaving a page. It works out nicely for situations like route and query 
parameter changes.

tl;dr an Om and Secretary combination does work. In fact, our routes.cljs 
(where we defroute) and history.cljs (where we dispatch!) are files we rarely 
edit because this design works without much fuss. To recap the pattern for this 
looks like:

(Google History) hash change token → dispatch! → data → transition! (Om)

In conclusion, I would argue that the choices you make about how you manipulate 
your application state will have more consequences than the routing library you 
choose.

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

Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

Dom,

We’re actually well aware of many of the flaws you have pointed out with 
Secretary. In fact, we even have open issues for some of them.

> While I value all of these features that Secretary lacks, I think that last 
> one, impurity, is the most significant... Mutation is always possible, but 
> uncontrolled mutation is frowned upon and intentionally difficult

It is not as if we don’t understand the benefits of immutability or know 
Clojure idioms. There’s no need to school anyone. We're not n00bs here. :-) 
When I became a committer to the library I did what I could to improve what was 
already there.

Personally, I do not like the overly complex macro that we have nor do I like 
the global state. These are just implementation details and it wouldn’t require 
too much effort to switch to something that’s immutable with a minimum amount 
of breaking change. We already have several vanilla functions for 
adding/removing routes that could easily be made stateless. The three of us 
(myself, Gianni, and Joel) have been busy and just haven’t had the chance to 
fix it.

Anyway, you’ve done a great job enumerating your reasons for writing Silk and 
flaws about Secretary; some of it is accurate, some of it is misguided. I’m not 
going to return fire by addressing them because I don’t think it will make much 
of a difference. Really, what we need to do is work together.

We can continue this discussion elsewhere.

Joel

-- 
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] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

Edit: s/\(routers in the Clojure\)Script/\1 

-- 
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] Silk, an isomorphic routing library for Clojure and ClojureScript

[Joel Holdbrooks]

Awesome work. It's fantastic to see a library that's interested in targeting 
both the front-end and the back-end. This is the type of attitude I would love 
to see more often in the Clojure community.

OTOH, it would have been awesome to have heard your thoughts WRT the concept of 
isomorphic routing on the Secretary issue tracker.

You said you couldn't find something suitable, why didn't you complain or 
suggest a patch? We would have been happy to have supported your endeavor in 
making that possible and your ideas. In fact, we would have been willing to 
make breaking changes for them! 

Many of us want this!

Originally, several people - myself included - were interested in seeing Clout 
be the library that everyone used both on the client and on the server. 
Unfortunately, James never merged the pull requests (two of them) for 
ClojureScript support. AFAICT it was because he wasn't clear on the role it 
would serve. James is also a busy man. :-)

I'm not trying to call you out; the work you have done is fantastic (there's 
already a few things I'd like to steal!). Rather, I am trying to bring up a 
more important issue within our community WRT this topic: routing. We now have 
at least 4 libraries designed for this task (most of them targeting the server).

We should not burden the community with dozens of choices. Instead we should 
enrich the community by working together to improve it. Fewer, well designed 
choices surely outweigh many "okay" solutions.

So enough talk. Personally, I would love to work together on the issue of an 
isomorphic router. Secretary is a well known choice for the client and I think 
together we could make it better by supporting the server. We have three core 
team members on Secretary, and speaking for the team, I think we would love to 
bring an end to this saturation of routers in the ClojureScript world. Would 
you be interested in joining our team and help us work toward this goal?

I don't mean to put you on the spot publicly but this is, partly, a public NIH 
issue and a tweet won't hold this. 

Email me privately if you desire. :-)

-- 
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: ClojureScript 0.0-2227

[Joel Holdbrooks]

On Thursday, May 22, 2014 8:18:06 AM UTC-7, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2227
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2227"]
> 
> 
> Enhancements
> 
> 
> * optimized case
> * CLJS-802: Add :pseudo-names compiler option
> * CLJS-795: 10X performance enchancement for multimethods
> * CLJS-801: str macro emits unoptimizable js code
> 
> * CLJS-656: search classpath for goog-style JavaScript dependencies
> 
> 
> Fixes
> -
> * CLJS-792: Implement IReduce on PersistentArrayMap
> * CLJS-804: Binding *print-length* breaks str
> 
> * CLJS-775: Fix cljs.reader cljs.reader parses radix form of int literals
> * CLJS-805: add-watch returns map of watch fns instead of watched reference
> * CLJS-787: cljs.reader does not read blank string as nil
> 
> * CLJS-784: Fix *Map.-conj for map-entry seqs, that don't implement INext
> * CLJS-784: make conj on maps behave as it does in Clojure
> * CLJS-793: fix memoize (non-truthy values don't get cached)
> 
> * CLJS-800: PersistentQueueSeq extended to IPrintWithWriter

Awesome! Don't forget to update the README!

-- 
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] core.async (and more) video tutorials

[Joel Holdbrooks]

Zippers might be another good topic. They ship with Clojure and are a bit 
mystical to folks who are curious but don't know how to get started.

On Wednesday, May 21, 2014 3:32:55 PM UTC-7, tbc++ wrote:
>
> From time to time I get asked to do more writing on core.async, and I've 
> come to the realization that try as I might, I'm not a writer. However I 
> recently started a set of video tutorials I'm making available today.
>
> The videos average about 12min in length and focus on a single topic. 
> Currently I have 5 videos on core.async completed and two on logic 
> programming. I plan on expanding both series over time. My plans are to 
> release 2-3 videos a week but that may change over time. 
>
> At any rate, the videos are available here (
> https://tbaldridge.pivotshare.com/). Yes, there is a small charge for the 
> majority of the videos, but think of it as a way to prod me to make more 
> tutorials. 
>
> Thanks! And hopefully this will be useful to some. 
>
> Timothy Baldridge
>

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

[ANN] Garden 1.1.7

[Joel Holdbrooks]

Garden, a library for authoring stylesheets in Clojure and ClojureScript, 
is now 1.1.7.

ADDED: Support for :preamble
IMPROVED: Support for meta data in garden.def/* macros

https://github.com/noprompt/garden

-- 
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: Garden, Thorn - Looking for contributors

[Joel Holdbrooks]

Thanks! I'll be in touch.

On Tuesday, March 25, 2014 1:54:23 PM UTC-7, Alan Moore wrote:
>
> Joel,
>
> Count me in...
>
> You can contact me offline at kahunamoore  coopsource  org
>
> Thanks for this library!
>
> Alan
>
>
> On Tuesday, March 25, 2014 12:33:15 PM UTC-7, Julien wrote:
>>
>> Hi Joel,
>>
>> thanks for your great work on garden! Definitively helping me every day.
>>
>> Can you share what you have in mind regarding CSSOM integration? It 
>> certainly opens cool perspective and I'm curious how you see it fit with 
>> garden. I would be interested in giving you a hand here.
>> Maybe a github issue would help start discussions?
>>
>> Julien
>>
>> Le samedi 22 mars 2014 22:41:04 UTC-3, Joel Holdbrooks a écrit :
>>>
>>> Greetings everyone,
>>>
>>> About a year ago I began working on Garden and in the short time the 
>>> library has been around it's grown a bit. Although many folks seem to be 
>>> interested in it, there's certainly not as much adoption of the library as 
>>> I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be 
>>> the default choices for many people writing web applications in Clojure.
>>>
>>> This is something I'd like to change... but I need *your* help!
>>>
>>> No, no. Put down the phone. Don't look for a KickStarter URL. It's 
>>> nothing like that.
>>>
>>> How you can help Garden
>>>
>>> I'm looking for individuals who are interested in the following:
>>>
>>>
>>>- improving the compiler code
>>>- improving/extending existing API's
>>>- building an interface to the CSSOM
>>>
>>> I'm also open to good 'ol fashioned suggestions, pain points you've 
>>> experienced using the library, or flat out letting me know what it would 
>>> take to get you to choose Garden over the alternatives for your next 
>>> project.
>>>
>>> How you can help Thorn
>>>
>>> Thorn is very young project and has no official release yet. So what is 
>>> it? At the moment it's the beginnings of a Sass Parse Tree transformer; 
>>> something that will take CSS/SCSS/Sass code and give you Garden code. 
>>> There's a lot of fabulous libraries available in Sass and I'm sure it's a 
>>> big factor when choosing how to go about CSS generation.
>>>
>>> I'm looking for individuals who are interested in the following:
>>>
>>>
>>>- accurately transforming CSS/SCSS/Sass to real Clojure code 
>>>targeting Garden
>>>- accurately transforming Less to real Clojure code targeting Garden
>>>
>>> Why?
>>>
>>> I deeply believe that being able to author CSS in Clojure or 
>>> ClojureScript is a key piece to having an extremely compelling story for 
>>> web application development in Clojure. Being able to *program* CSS and 
>>> not just *preprocess* is a big advantage over existing tools. Being 
>>> able to use all of Clojure everywhere has astounding possibilities.
>>>
>>>
>>> If any of this sounds interesting to you please get in contact with me 
>>> or reply here. I will also be in San Francisco tomorrow until Tuesday for 
>>> Clojure/West if you'd like to discuss these items in person.
>>>
>>>
>>> Truly,
>>>
>>> Joel
>>>
>>

-- 
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: Garden, Thorn - Looking for contributors

[Joel Holdbrooks]

I've answered this question numerous times and am convinced I need to write 
a blog post so I can just drop a link.

In general the biggest win is that you can use Clojure and all of the 
facilities therein to write more sophisticated stylesheets. Large CSS 
codebases are notoriously hard to manage and require a lot of discipline to 
get right. If you're not writing a lot of CSS it isn't necessarily a big 
win.

On Tuesday, March 25, 2014 5:42:45 PM UTC-7, Daniel wrote:
>
> I wonder what is so bad about pure CSS. Don't get me wrong - I do 
> appreciate projects like these.

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

Garden, Thorn - Looking for contributors

[Joel Holdbrooks]

Greetings everyone,

About a year ago I began working on Garden and in the short time the 
library has been around it's grown a bit. Although many folks seem to be 
interested in it, there's certainly not as much adoption of the library as 
I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be 
the default choices for many people writing web applications in Clojure.

This is something I'd like to change... but I need *your* help!

No, no. Put down the phone. Don't look for a KickStarter URL. It's nothing 
like that.

How you can help Garden

I'm looking for individuals who are interested in the following:


   - improving the compiler code
   - improving/extending existing API's
   - building an interface to the CSSOM

I'm also open to good 'ol fashioned suggestions, pain points you've 
experienced using the library, or flat out letting me know what it would 
take to get you to choose Garden over the alternatives for your next 
project.

How you can help Thorn

Thorn is very young project and has no official release yet. So what is it? 
At the moment it's the beginnings of a Sass Parse Tree transformer; 
something that will take CSS/SCSS/Sass code and give you Garden code. 
There's a lot of fabulous libraries available in Sass and I'm sure it's a 
big factor when choosing how to go about CSS generation.

I'm looking for individuals who are interested in the following:


   - accurately transforming CSS/SCSS/Sass to real Clojure code targeting 
   Garden
   - accurately transforming Less to real Clojure code targeting Garden

Why?

I deeply believe that being able to author CSS in Clojure or ClojureScript 
is a key piece to having an extremely compelling story for web application 
development in Clojure. Being able to *program* CSS and not just 
*preprocess* is a big advantage over existing tools. Being able to use all 
of Clojure everywhere has astounding possibilities.


If any of this sounds interesting to you please get in contact with me or 
reply here. I will also be in San Francisco tomorrow until Tuesday for 
Clojure/West if you'd like to discuss these items in person.


Truly,

Joel

-- 
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: CLJS Advanced Compilation & JS Libraries lacking externs

[Joel Holdbrooks]

I notice you mention:

> For some JavaScript libraries there is an acceptable workaround

Under what circumstances would this not be acceptable?

On Friday, March 14, 2014 5:39:06 PM UTC-7, David Nolen wrote:
>
> I've written up an explanation how to make this work 
> http://swannodette.github.io/2014/03/14/externs-got-you-down/
>
> David
>

-- 
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: CLJS Advanced Compilation & JS Libraries lacking externs

[Joel Holdbrooks]

This is brilliant. Thanks for sharing!

On Friday, March 14, 2014 5:39:06 PM UTC-7, David Nolen wrote:
>
> I've written up an explanation how to make this work 
> http://swannodette.github.io/2014/03/14/externs-got-you-down/
>
> David
>

-- 
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: lein-garden 0.1.6

[Joel Holdbrooks]

lein-garden the plugin for automatically compiling Garden stylesheets has 
been updated to version 0.1.6.

https://github.com/noprompt/lein-garden

This release fixes a bug where an unnecessary exception would be thrown for 
valid identifiers.

-- 
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: ankha (Om data inspector)

[Joel Holdbrooks]

Ankha is a generic data inspector for use with Om. You can use it to 
interactively view your application's state or any other supported data 
structure (see README).

Learn more here: https://github.com/noprompt/ankha

Comments, suggestions, and patches welcome. Expect more features to come.

-- 
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: pretty-exception middleware for ring

[Joel Holdbrooks]

This is another fantastic idea. I'd definitely love to expand on this 
technique.

Great work!

On Thursday, February 13, 2014 8:39:58 AM UTC-8, bob wrote:
>
> Hey,
>
> a simple exception middle-ware for ring, maybe useful for some,maybe none. 
> it catch exceptions and print, meanwhile the source code produced the 
> exception will be print as well.
>
> - The demo will stay here (click me)
>  . 
> - The source code is 
> here
>  .
>

-- 
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: hooks on "namespace required/loaded"

[Joel Holdbrooks]

I know we talked a bit about this in IRC but this is a hack you could use 
to slurp the file's contents into a string in that file:

(ns foo.core
  (:refer-clojure :exclude [slurp]))
 
(defmacro slurp [file]
  (clojure.core/slurp file))
 
;; In CLJS
 
(ns bar.core
  (:require [foo.core :include-macros true :refer [slurp]]))
 
;; This is possible because we can evaluate *Clojure* code at compile time.
(def project-clj 
  (slurp "project.clj"))


>From there you could then use read-string, or what have you, and examine 
the contents.

Here's a link to the gist for 
reference: https://gist.github.com/noprompt/9086232.

On Tuesday, February 18, 2014 8:32:05 PM UTC-8, t x wrote:
>
> Hi, 
>
>   Although solutions not involving cljx are perfectly fine, I'm using 
> cljx -- so solutions that involves hooking into cljx are perfectly 
> fine too. 
>
>   I have my own "poor-man's lint / type checker" (with different 
> objectives from core.typed). I want a certain function (call it 
> CHECKER) to be called every time a namespace has been "required / 
> loaded / reloaded" 
>
>   Every time I require/load/reload a namespace, I want the following to 
> happen: 
>
> (CHECKER ... source code of the namesapce) 
>
> i.e. something like 
>
> (CHECKER (read-string "namesapce-just-loaded.clj")) 
>
> Then, if CHECKER throws an exception, it should be a compile error. If 
> CHECKER prints stuff out, it should go into the "lein repl" stdout, 
> and if CHECKER doesn't do anything, it's assumed that the namespace 
> passed the check. 
>
>   Is there a minimal example somewhere of how this works? (i.e. 
> something as stupid as: "this example calls a function, which just 
> prints out the name of all functions defined" would be extremely 
> helpful). 
>
> Thanks! 
>

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

Re: [ANN] Clojure 1.6.0-beta1

[Joel Holdbrooks]

As an addendum to my last comment, *not-nil?* would also be a good 
candidate. That really doesn't leave room for doubt.

This:
  
(some? false) ;; => true 

Would confuse me. On the other hand this:
  
(not-nil? false) ;; => true 

Would not.

There's really no need to complicate the naming story here. It's also easy 
to remember!

On Friday, February 14, 2014 3:25:36 PM UTC-8, Alex Miller wrote:
>
>
>
> On Friday, February 14, 2014 2:27:49 PM UTC-6, DomKM wrote:
>>
>> Great changes! I have a question about #5.
>>  
>>
>>> 5) New "some" operations 
>>> Many conditional functions rely on logical truth (where "falsey"
>>> values are nil or false). Sometimes it is useful to have functions
>>> that rely on "not nilness" instead. These functions have been added to
>>> support these cases [CLJ-1343]:
>>> * some? - same as (not (nil? x))
>>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>>
>>
>> It seems inconsistent to have "some" mean two very different things 
>> within the same namespace, especially since the prior uses of "some" 
>> (`some`, `some-fn`, etc.) are more in keeping with its primary definition 
>> of having to do with amount (and operate on seqs or variadic arguments) 
>> while the new functions have to do with existence (and operate on any 
>> single value). Why not call these new functions `not-nil?`, `if-not-nil`, 
>> and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about 
>> "exists" (`exists?`, `if-exists`, `when-exists`)?
>>
>> Are these names up for discussion?
>>
>
> Hey Dom et al,
>
> The names of these functions were chosen by Rich. There was already some 
> name overloading of "some" even before these new functions with some 
> (truthy) and some->/some->> (not nil). The new functions keep with the 
> latter meaning. Many other names were considered, including everything I've 
> seen someone mention (-not-nil, exists, nnil, etc). As far as I know these 
> names are final, however, I will relay all of the feedback I've seen here, 
> on #clojure, and on Twitter to Rich for consideration.
>
> Alex
>  
>

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

Re: ANN: Om 0.4.0

[Joel Holdbrooks]

On Friday, February 14, 2014 5:00:10 AM UTC-8, Tatu Tarvainen wrote:
> Btw, I seem to get the following compiler errors after upgrading om from 
> 0.3.6 to 0.4.0
> 
> 
> (clojurescript version is 0.0-2138)
> 
> 
> WARNING: Use of undeclared Var om.core/specify! at line 570 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/_ at line 572 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/tx-data at line 572 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/root-cursor at line 572 
> out\om\core.cljs
> WARNING: Use of undeclared Var om.core/tx-data at line 574 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/root-cursor at line 574 
> out\om\core.cljs
> WARNING: Wrong number of args (2) passed to om.core/-notify at line 572 
> out\om\core.cljs

You might want to try running "lein cljsbuild clean." Normally, those sorts of 
messages appear whenever I forget to clean and rebuild after upgrading 
dependencies.

-- 
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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

[Joel Holdbrooks]

Oh, hey, thanks. I didn't catch that. Great copy/paste fail, eh. Maybe next 
time post an issue to the Github. :-)

On Feb 5, 2014, at 8:29 PM, Atamert Ölçgen  wrote:

> I posted to the correct thread. Check the project.clj please.
> 
> 
> On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks  
> wrote:
> Wat? I think you may have meant to post this comment somewhere else. That's 
> certainly not the case. But I think I did forget to share the link which is: 
> https://github.com/noprompt/lein-describe
> 
> 
> On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote:
> The project URL is "https://github.com/noprompt/lein-garden";. (Sorry, if this 
> was mentioned before, I joined recently.)
> 
> 
> On Wed, Feb 5, 2014 at 12:28 PM,  wrote:
> Looks cool. I'll be sure to check it out.
> 
> --
> 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.
> 
> 
> 
> -- 
> Kind Regards,
> Atamert Ölçgen
> 
> -+-
> --+
> +++
> 
> www.muhuk.com
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> -- 
> Kind Regards,
> Atamert Ölçgen
> 
> -+-
> --+
> +++
> 
> www.muhuk.com
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/FWeIIO2ToGQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

[Joel Holdbrooks]

Check which project.clj? You posted a link to lien-garden. Am I missing 
something here?

On Wednesday, February 5, 2014 8:29:35 PM UTC-8, Atamert Ölçgen wrote:
>
> I posted to the correct thread. Check the project.clj please.
>
>
> On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks 
> 
> > wrote:
>
>> Wat? I think you may have meant to post this comment somewhere else. 
>> That's certainly not the case. But I think I did forget to share the link 
>> which is: https://github.com/noprompt/lein-describe
>>
>>
>> On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote:
>>
>>> The project URL is "https://github.com/noprompt/lein-garden";. (Sorry, 
>>> if this was mentioned before, I joined recently.)
>>>
>>>
>>> On Wed, Feb 5, 2014 at 12:28 PM,  wrote:
>>>
>>>>  Looks cool. I'll be sure to check it out.
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Kind Regards,
>>> Atamert Ölçgen
>>>
>>> -+-
>>> --+
>>> +++
>>>
>>> www.muhuk.com
>>>  
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.com
>  

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

Re: [ANN] garden-watch

[Joel Holdbrooks]

Clojure.

On Feb 5, 2014, at 8:42 PM, Timothy Washington  wrote:

> Ok, that's fine. Definitely good to have both ways to tackle the problem. But 
> I'm curious. What do you feel is being given up by watching garden files? 
> 
> 
> Thanks 
> 
> Tim Washington 
> Interruptsoftware.com 
> 
> 
> On Wed, Feb 5, 2014 at 11:04 PM, Joel Holdbrooks  
> wrote:
> The idea to watch edn or garden files was a consideration of lein-garden but 
> decided against it because, personally, I felt it was giving up a lot. 
> However, some folks may prefer this approach and, hopefully, it suits them 
> just as well.
> 
> 
> On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote:
> Hey Dave, 
> 
> Thanks for that heads up. I originally wanted auto-compiling for HAML and 
> SCSS. But then thought why, when I could just use edn with Hiccup and Garden. 
> Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. 
> So i) I had to do that work anyways. Then I spent 20 mins replicating the 
> functionality for Garden. Also I think lein-garden tracks edn style 
> definitions, inlined in your existing Clojure code, whereas ii) I wanted a 
> separate directory watcher on edn files (no namespaces needed). 
> 
> But there's nothing that says that functionality in garden-watch couldn't be 
> collapsed into lein-garden. It's pretty straightforward code. 
> 
> 
> Tim Washington 
> Interruptsoftware.com 
> 
> 
> On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann  wrote:
> FYI, I think lein garden does this already. is there a particular difference?
> 
> 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/GyKBpfEFkqg/unsubscribe.
> To unsubscribe from this group and all its topics, 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: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

[Joel Holdbrooks]

Wat? I think you may have meant to post this comment somewhere else. That's 
certainly not the case. But I think I did forget to share the link which 
is: https://github.com/noprompt/lein-describe

On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote:
>
> The project URL is "https://github.com/noprompt/lein-garden";. (Sorry, if 
> this was mentioned before, I joined recently.)
>
>
> On Wed, Feb 5, 2014 at 12:28 PM, >wrote:
>
>> Looks cool. I'll be sure to check it out.
>>
>> --
>> 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.com
>  

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

Re: [ANN] garden-watch

[Joel Holdbrooks]

The idea to watch edn or garden files was a consideration of lein-garden 
but decided against it because, personally, I felt it was giving up a lot. 
However, some folks may prefer this approach and, hopefully, it suits them 
just as well.

On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote:
>
> Hey Dave, 
>
> Thanks for that heads up. I originally wanted auto-compiling for *HAML*and 
> *SCSS*. But then thought why, when I could just use edn with *Hiccup* and 
> *Garden*. Now, a lein-hiccup, or some auto compile tool doesn't exist to 
> my knowledge. So *i)* I had to do that work anyways. Then I spent 20 mins 
> replicating the functionality for Garden. Also I think lein-garden tracks 
> edn style definitions, inlined in your existing Clojure code, whereas 
> *ii)* I wanted a separate directory watcher on edn files (no namespaces 
> needed). 
>
> But there's nothing that says that functionality in garden-watch couldn't 
> be collapsed into lein-garden. It's pretty straightforward code. 
>
>
> Tim Washington 
> Interruptsoftware.com  
>  
>
> On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann 
> > wrote:
>
>> FYI, I think lein garden does this already. is there a particular 
>> difference?
>>
>>
>>  

-- 
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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

[Joel Holdbrooks]

lein-describe

Have you ever be involved in a Clojure project and wondered "how are these 
dependencies used?" or "what do these plugins do?". This plugin can help 
you answer those questions.

lein-describe provides detailed information about Clojure project 
dependencies and plugins. With a single command you can get a glance at 
dependency descriptions, licenses, and more.
Usage

Put [lein-describe "0.1.0"] into the :plugins vector of your :user 
profile
.
Example

$ cd /path/to/clojure/project
$ lein describe
PROJECT DEPENDENCIES:

Dependency: [com.cemerick/piggieback "0.1.2"]
Description: Adding support for running ClojureScript REPLs over nREPL.
URL: http://github.com/cemerick/piggieback
License(s): Eclipse Public License (http://www.eclipse.org/legal/epl-v10.html)
Dependencies: [org.clojure/clojure "1.5.1"]
  [org.clojure/tools.nrepl "0.2.3"]
  [org.clojure/clojurescript "0.0-2014"]
  [clojure-complete "0.2.3"]
...

PLUGIN DEPENDENCIES:

Dependency: [com.cemerick/austin "0.1.3"]
Description: The ClojureScript browser-repl, rebuilt stronger, faster, easier.
URL: http://github.com/cemerick/austin
License(s): Eclipse Public License (http://www.eclipse.org/legal/epl-v10.html)
Dependencies: [org.clojure/clojure "1.5.1"]
  [org.clojure/clojurescript "0.0-2014"]
  [com.cemerick/piggieback "0.1.2"]
  [org.clojure/tools.nrepl "0.2.3"]
  [clojure-complete "0.2.3"]
...

-- 
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] clj-refactor.el 0.10.0

[Joel Holdbrooks]

Slam dunk! Looking forward to trying this 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: [ANN] clj-refactor.el 0.10.0

[Joel Holdbrooks]

Slam dunk! Looking forward to trying this out.

On Thursday, January 30, 2014 5:13:36 AM UTC-8, Magnar Sveen wrote:
>
> clj-refactor.el
> Since the last update, there's been lots of activity for 
> clj-refactor.el
> . Alex Baranosky  and Lars 
> Andersen have 
> joined the team, and here are the new features:
> More let refactorings
>
> Starting with:
>
> (defn handle-request
>   (let [body (find-body abc)]
> {:status 200
>  :body body})) 
>
> With the cursor in front of 200, I do cljr-move-to-let:
>
> (defn handle-request
>   (let [body (find-body abc)
> X 200]
> {:status X
>  :body body}))
>
> Again I have two cursors where the Xes are, so I type out the name, and 
> press enter:
>
> (defn handle-request
>   (let [body (find-body abc)
> status 200]
> {:status status
>  :body body}))
>
> Pretty handy. And it works with if-let and when-let too.
>
> *Thread first all, thread last all, unwind all*
>
> Convenience functions to thread all the way down, or unwind the entire 
> threading macro.
> Cycling Privacy
>
> Given this function:
>
> (defn add [a b]
>   (+ a b))
>
> I do cljr-cycle-privacy:
>
> (defn- add [a b]
>   (+ a b))
>
> I do cljr-cycle-privacy again to return to the original:
>
> (defn add [a b]
>   (+ a b))
>
> Given this def:
>
> (def config
>   "docs"
>   {:env "staging"})
>
> I do cljr-cycle-privacy:
>
> (def ^:private config
>   "docs"
>   {:env "staging"})
>
> I do cljr-cycle-privacy again to return to the original:
>
> (def config
>   "docs"
>   {:env "staging"})
>
> Cycling 
> Collection Type
>
> Given this collection:
>
> (:a 1 :b 2)
>
> I do cljr-cycle-coll to return:
>
> {:a 1 :b 2}
>
> ... and then 3 more times:
>
> [:a 1 :b 2]#{:a 1 :b 2}(:a 1 :b 2)
>
>
> Cycling
>  
> Between Strings and Keywords
>
> Given this string:
>
> "refactor"
>
> I do cljr-cycle-stringlike to return:
>
> :refactor
>
> ... and then 3 more times:
>
> "refactor":refactor"refactor"
>
> Thanks to Jay Fields  and 
> emacs-live for 
> these cycling features. Good idea!
> Destructuring keys
>
> Given this:
>
> (defn- render-recommendation [rec]
>   (list [:h3 (:title rec)]
> [:p (:by rec)]
> [:p (:blurb rec) " "
>  (render-link (:link rec))]))
>
> I place the cursor on rec inside [rec] and do cljr-destructure-keys:
>
> (defn- render-recommendation [{:keys [title by blurb link]}]
>   (list [:h3 title]
> [:p by]
> [:p blurb " "
>  (render-link link)]))
>
> If rec had still been in use, it would have added an :as clause.
>
> For now this feature is limited to top-level symbols in a let form. PR 
> welcome.
> Stop referring
>
> Given this:
>
> (ns cljr.core
>   (:require [my.lib :as lib :refer [a b]]))
> (+ (a 1) (b 2))
>
> I place cursor on my.lib and do cljr-stop-referring:
>
> (ns cljr.core
>   (:require [my.lib :as lib]))
> (+ (lib/a 1) (lib/b 2))
>
> Even more
> There's also 
>
>-  cljr-sort-ns to sort the namespace
>-  cljr-replace-use to replace old :use statements with new :refer 
>:all statements.
>-  cljr-add-declaration to declare the defn you're in.
>
> So, clj-refactor.el still knows nothing about your code. At some point we 
> want to piggyback on an nrepl-connection to do the tricky parts of 
> refactoring, but for now we're happy to make life a little easier.
>
> Hope you enjoy!
>
>
>

-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Joel Holdbrooks]

As a suffix to my last reply; if Hy were capable of delivering acceptable 
truthy semantics and persistent data structures, I might recommend it.

On Saturday, January 4, 2014 9:44:08 AM UTC-8, g vim wrote:
>
> On 04/01/2014 17:28, gaz jones wrote: 
> > Why not just use Ruby or (my preference) Python? Both are great for 
> > quick CLI apps / scripts. Best tool for the job, and all that? 
> > 
>
> A Clojure layer on top of Ruby means less context switching which works 
> better for me as the Lisp mindset is very different from Ruby or Python. 
> However, I just looked at the Rouge docs and very little seems to have 
> been implemented so maybe it's dying. If so, I'll go with Hy which looks 
> much more mature. 
>
> gvim 
>

-- 
-- 
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: Contributors needed for Rouge (Clojure on Ruby)

[Joel Holdbrooks]

As one of the original contributors to Rouge I will definitely agree that 
it does need a lot of work. That being said, if there's interest and pull 
requests are submitted the original author or myself typically chime in. 
Both of us have been busy with other projects/life and haven't done much 
work on it in quite some time.

While Rouge itself is not 100% compatible with Clojure or complete, I 
certainly would recommend it over Hy for simple tasks and for the 
maintainers understanding of both Clojure and Lisp idioms. As far as I can 
tell, the Hy team seems more or less interested in a Pythonic Lisp. There 
was a huge debate, for instance, over whether or not 0, [], {}, (), and "" 
should be considered truthy in Hy which. If you ask me, that alone is a 
reason not to consider it unless, of course, you are looking for that.

Beside the topic, there is a Ruby 
librarythat includes implementations of 
various persistent data structures. Since 
I head about it I thought it would be nice to use those instead of the 
`freeze`ing of Ruby's data structures you see in Rouge currently. It would 
definitely be worth the effort/discussion and I'm sure Rouge would be open 
to that.

On Saturday, January 4, 2014 9:44:08 AM UTC-8, g vim wrote:
>
> On 04/01/2014 17:28, gaz jones wrote: 
> > Why not just use Ruby or (my preference) Python? Both are great for 
> > quick CLI apps / scripts. Best tool for the job, and all that? 
> > 
>
> A Clojure layer on top of Ruby means less context switching which works 
> better for me as the Lisp mindset is very different from Ruby or Python. 
> However, I just looked at the Rouge docs and very little seems to have 
> been implemented so maybe it's dying. If so, I'll go with Hy which looks 
> much more mature. 
>
> gvim 
>

-- 
-- 
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: AnNN: ClojureScript 0.0-2120

[Joel Holdbrooks]

Woohoo! Yes! Thank you!

On Friday, December 13, 2013 7:15:40 AM UTC-8, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-2120
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2120"]
>
> Enhancements:
> * inline source map information available to REPLs, enabled in browser REPL
> * #js data literal support added
> * :include-macros true and :refer-macros [syms ...] allowed in :require
> * make-array now inlined into dense array, much faster PHM perf
> * CLJS-673: support *print-level*
> * expose Google Closure Compiler defines under :closure-defines
> * expose Google Closure Compiler warnings configuration under 
> :closure-warnings
>
> Changes:
> * latest Closure Compiler dependency
> * CLJS-690: add sequence & sorted
> * CLJS-709: optimize cljs->js for sequential collection to array
> * CLJS-699: letfn fns not optimized
>
> Bug fixes:
> * CLJS-724: Range -first bug
> * CLJS-725: fix broken optimizations around IndexedSeq
> * fix broken behavior of #uuid and #inst data literals
> * CLJS-697: top-level symbol reference doesn't get an automatically 
> inserted ns-name
> * CLJS-692: cannot access properties on imported GClosure constructors
> * CLJS-480: reader/*data-readers* bound inconsistently
>

-- 
-- 
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: Import dbpedia data into neo4j using clojure

[Joel Holdbrooks]

I'm not certain where the Transient error is coming from but as far as 
Neo4J is concerned have you considered using the neocons library to help 
you with your import? It provides a decent wrapper for working with Neo4J 
and perhaps it will spare you some headache. IIRC it does batch inserts. 
Have a look: https://github.com/michaelklishin/neocons

On Monday, December 2, 2013 2:11:53 AM UTC-8, Himakshi Mangal wrote:
>
> Hi...
>
>
> I am using clojure to import dbpedia data into neo4j.
>
> Here's the code:
> (ns opal.dbpedia
>   (:use [clojure.tools.logging :only [log]])
>   (:require [clojure.java.io :as io])
>   (:import [uk.ac.manchester.cs.owl.owlapi.turtle.parser TurtleParser]
>[org.neo4j.unsafe.batchinsert BatchInserters]
>[org.neo4j.graphdb DynamicRelationshipType]))
>
> ;; PARSING METHODS
>
> (defn get-next-tuple
>   [parser]
>   (let [last-item (atom nil)
> tuple (atom [])]
> (while (and (not= "." @last-item)
> (not= "" @last-item))
>   (reset! last-item
>   (-> parser
> (.getNextToken)
> (.toString)))
>   (swap! tuple conj @last-item))
> (when-not (empty? (first @tuple)) ; .getNextToken returns "" once you 
> are out of data
>   @tuple)))
>
> (defn seq-of-parser
>   [parser]
>   (if-let [next-tuple (get-next-tuple parser)]
> (lazy-cat [next-tuple]
>   (seq-of-parser parser
>
> (defn parse-file
>   [filename]
>   (seq-of-parser
> (TurtleParser.
>   (io/input-stream filename
>
> ;; BATCH UPSERT METHODS
>
> (def id-map (atom nil))
> (defn insert-resource-node!
>   [inserter res]
>   (if-let [id (get @id-map res)]
> ; If the resource has aleady been added, just return the id.
> id
> ; Otherwise, add the node for the node, and remember its id for later.
> (let [id (.createNode inserter {"resource" res})]
>   (swap! id-map #(assoc! % res id))
>   id)))
>
> (defn connect-resource-nodes!
>   [inserter node1 node2 label]
>   (let [relationship (DynamicRelationshipType/withName label)]
> (.createRelationship inserter node1 node2 relationship nil)))
>
> (defn insert-tuple!
>   [inserter tuple]
>   ; Get the resource and label names out of the tuple.
>   (let [[resource-1 label resource-2 & _ ] tuple
> ; Upsert the resource nodes.
> node-1 (insert-resource-node! inserter resource-1)
> node-2 (insert-resource-node! inserter resource-2)]
> ; Connect the nodes with an edge.
> (connect-resource-nodes! inserter node-1 node-2 label)))
>
> (defn -main [graph-path & files]
>   (let [inserter (BatchInserters/inserter graph-path)]
> (doseq [file files]
>   (log :debug (str "Loading file: " file))
>   (let [c (atom 0)]
> (doseq [tuple (parse-file file)]
>   (if (= (mod @c 1) 0)
> (log :debug (str file ": " @c)))
>   (swap! c inc)
>   (insert-tuple! inserter tuple
> (log :debug "Loading complete.")
> (log :debug "Shutting down.")
> (.shutdown inserter)
> (log :debug "Shutdown complete!")))
>
> I am getting the following errors:
>
> IllegalAccessError Transient used by non-owner thread 
>  clojure.lang.PersistentArrayMap$TransientArrayMap.ensureEditable 
> (PersistentArrayMap.java:449) 
>
> &&
>
>
> IllegalArgumentException No matching method found: createNode for class 
> org.neo4j.unsafe.batchinsert.BatchInserterImpl 
>  clojure.lang.Reflector.invokeMatchingMethod
>
>
> Can anyone please help me in this.. Am doing something wrong or am i 
> missing something.. I am completely new to clojure. Is there a working 
> example for this?
>
>
> Please help..
>
> 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.

Releasing Caribou today: Open Source Clojure Web Ecosystem

[Joel Holdbrooks]

This exactly the sort of project I've been hoping for to get others to take a 
serious look at using Clojure. While its unfortunate some developers will not 
look at a language until it has a comfortable entry point, it's a real barrier 
for  adoption. Caribou looks like it has the potential to speak to these 
developers with familiar workflow tools. I look forward to sharing this with 
others whom I've tried to convince in the past.

By the way the documentation is great. You guys nailed it! Bonus points for 
having a philosophy! :-)

-- 
-- 
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] Garden 1.0.0 released

[Joel Holdbrooks]

Thanks James! The only thing I think is missing now are solid libraries (or 
ports of).

With ClojureScript support there are some interesting 
applications/possibilities on the client side that I'm just beginning to 
explore. I would definitely be interested to see what people discover in that 
space.

Unfortunately, I think it will be a while before others (Sass/Less users) see 
the benefits and potential of this approach to stylesheet programming. For that 
it would likely need some mentions from CSS thought leaders and, again, 
librarie.

FWIW, team Simonides used Garden for our app in the Clojure Cup. We didn't do 
anything advanced but it spared us one less language!

Joel

On Oct 4, 2013, at 9:39, james borden  wrote:

> Nice Joel! Thanks for making css a function.  
> 
> I suggest that others check this library out. It is a very compelling clojure 
> alternative to SASS/LESS. 
> 
> 
> On Thursday, September 26, 2013 8:39:05 PM UTC-5, Joel Holdbrooks wrote:
>> 
>> After nearly a month and a half of work, I'm extremely excited to finally 
>> announce the release of Garden 1.0.0! 
>> 
>> This new release contains several important bug fixes, new features, and of 
>> course breaking changes. Please be sure to see the ChangeLog for what has 
>> changed since the last release. This is critical for people who want to 
>> upgrade as there are some syntax changes and namespaces which are no longer 
>> included.
>> 
>> In a nutshell the new version has:
>> 
>> full ClojureScript support
>> built-in @keyframes support
>> the garden.core/css function (previously was a macro)
>> the garden.core/style function for inline styling of HTML
>> new compiler settings
>> configurable automatic vendor prefixing
>> 
>> A huge thank you goes out to Julien Eluard for making ClojureScript support 
>> a success. Also, I want to thank Rob Jens for spotting bugs and writing 
>> stylesheets with Garden against the development version. Without this kind 
>> of support, I don't think I'd be as happy as I am today.
>> 
>> As always, I'm interested in hearing new ideas and getting feedback from the 
>> community.
>> 
>> Sincerely,
>> 
>> Joel
> 
> -- 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/hedoVJ1Ep88/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

[ANN] Garden 1.0.0 released

[Joel Holdbrooks]

After nearly a month and a half of work, I'm extremely excited to finally 
announce the release of Garden 1.0.0 ! 

This new release contains several important bug fixes, new features, and of 
course breaking changes. Please be sure to see the 
ChangeLogfor
 what has changed since the last release. This is critical for people 
who want to upgrade as there are some syntax changes and namespaces which 
are no longer included.

In a nutshell the new version has:


   - full ClojureScript support
   - built-in @keyframes support
   - the garden.core/css *function* (previously was a macro)
   - the garden.core/style function for inline styling of HTML
   - new compiler settings
   - configurable automatic vendor prefixing


A huge thank you goes out to Julien Eluard for making ClojureScript support 
a success. Also, I want to thank Rob Jens for spotting bugs and writing 
stylesheets with Garden against the development version. Without this kind 
of support, I don't think I'd be as happy as I am today.

As always, I'm interested in hearing new ideas and getting feedback from 
the community.

Sincerely,

Joel

-- 
-- 
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: Emacs font and theme for clojure

[Joel Holdbrooks]

I've been using the noctilux-theme  
with 
Oxygen Mono  or Liberation 
Mono . 

On Thursday, September 26, 2013 7:51:44 AM UTC-7, Murtaza Husain wrote:
>
> Hi,
>
> I was just cycling through the different themes in emacs. I was wondering 
> what font and theme combination others are using ? Any recommendations for 
> mac pro retina ? 
>
> I like the solarized-dark theme, however the default font doesnt seem very 
> good with it. 
>
> Thanks,
> Murtaza 
>

-- 
-- 
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] clojure-sql 0.1.0: relational algebra in clojure

[Joel Holdbrooks]

This looks really nice Carlo! It'd be even better if it were on GitHub so I 
could star it :). But I'm definitely going to take a look at this when I'm 
in the SQL world again.

On Wednesday, July 3, 2013 1:48:07 AM UTC-7, Carlo wrote:
>
> Hey guys!
>
> I've been working on a small library to make writing SQL queries a little 
> bit easier. It's along the same lines as ClojureQL, but takes a different 
> approach and compiles into quite different SQL in the end.
>
> At the moment it's quite immature, but it should be able to support any 
> queries which can be expressed in relational algebra. There will be some 
> SQL queries which can't be expressed in clojure-sql, but hopefully there 
> won't be too many of those. A greater limitation is that at the moment the 
> SQL generation is specific to the PostgresSQL database (although any 
> contributions for other databases are welcome!).
>
> Dependency vector: [clojure-sql "0.1.0"]
> Repository: https://bitbucket.org/czan/clojure-sql
> Clojars link: https://clojars.org/clojure-sql
>
> Let me know what you think!
>
> Carlo
>

-- 
-- 
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] Ayler - A simple namespace/documentation browser

[Joel Holdbrooks]

This is really cool! Nice work!

On Wednesday, September 11, 2013 8:35:31 AM UTC-7, babysnakes wrote:
>
> Hi
>
> As a clojure noob I constantly find myself browsing through various API 
> docs to see what's available in a library. While this data is available in 
> a REPL it's not easy to look for it if you don't know what you're looking 
> for. I first saw a namespace browser concept in Relevance's 
> labrepl and  
> I really liked the idea. I decided to create one as a learning project. So 
> now I present to you Ayler . 
> It's a web based namespace browser that is external to your project and has 
> the following features:
>
>
>- Requires minimal (or no) dependencies in your project. It operates 
>by connecting to a running nrepl
>. 
>- Displays all loaded namespaces.
>- Displays all public member for a selected namespace.
>- Displays docstring for selected namespace.
>- Displays the docstring and source of selected var.
>- Allows you to search and load any namespace from a list of all 
>namespaces in your classpath (provided you've added required 
> dependencies). 
>
> I also have to point out the 
> clj-ns-browser project. 
> I borrowed a few features from it, but it's still much more advanced then 
> Ayler.
>
> Since this is a learning project for me (both clojure and javascript) 
> I'll appreciate some feedback.
>
> https://github.com/babysnakes/ayler/wiki
>
> Thanks
> -- 
> Haim 
>

-- 
-- 
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] Shodan: ClojureScript console API wrapper

[Joel Holdbrooks]

Hi everyone,

I put together a small library for wrapping the JavaScript console API 
available here: https://github.com/noprompt/shodan.

This is nothing incredible but I decided to put it out there because I'm 
tired of copy/paste/writing the same console wrappers every time I do 
something in CLJS.

Not everyone knows there is more to the console API than just *log*. There 
are methods for warning, message grouping, profiling and more. Shodan wraps 
all of these and provides a few macros around some things like message 
grouping and timing.

Shodan works with both the browser and NodeJS.

Thanks,

Joel

-- 
-- 
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: Emacs Clojure mode : No syntax highlighting for #_

[Joel Holdbrooks]

Definitely. I would agree a choice would be nice or even another font-lock
group. There have been times where I forgot about a #_ somewhere in my code
and spent a moment in confusion. Highlighting definitely would have been
valuable. It would be cool if code following #_ were semi-transparent or
something nifty like that. I think that's possible in the gui version of
Emacs.


On Thu, Aug 29, 2013 at 1:58 AM, Laurent PETIT wrote:

> 2013/8/29 Joel Holdbrooks :
> > I would imagine it is intended since #_ is a reader macro. #_ is not
> > intended for commenting. Rather, it instructs the Clojure Reader to
> ignore
> > entirely the subsequent form. This is much different from the comment
> macro
> > (which simply takes any number of arguments and returns nil) or the ;
> > comment syntax.
> >
> > It might be a bit involved to have #_ and the subsequent form appear
> > commented through clojure-mode's syntax highlighting. However, it would
> also
> > incorrectly express the semantics of #_ which, arguably, is counter to
> the
> > goal of syntax highlighting.
>
> Yet it is certainly better, given a dual choice, to present it as
> commented code.
> Counterclockwise does this since more than a year, and so far, nobody
> has complained.
>
> Cheers,
>
> --
> Laurent
>
> >
> >
> > On Wednesday, August 28, 2013 3:09:11 PM UTC-7, JvJ wrote:
> >>
> >> Although semicolons cause the text color to change in order to look
> >> "commented-out", the #_ reader macro doesn't cause any such change.  Is
> this
> >> intended, or is it a bug?
> >
> > --
> > --
> > 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/b5ETVbGG8G8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 

Joel

-- 
-- 
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: Emacs Clojure mode : No syntax highlighting for #_

[Joel Holdbrooks]

I would imagine it is intended since *#_* is a reader macro. *#_* is not 
intended for commenting. Rather, it instructs the Clojure Reader to ignore 
entirely the subsequent form. This is much different from the *comment*macro 
(which simply takes any number of arguments and returns nil) or the 
*;* comment syntax. 

It might be a bit involved to have *#_* and the subsequent form appear 
commented through clojure-mode's syntax highlighting. However, it would 
also incorrectly express the semantics of *#_* which, arguably, is counter 
to the goal of syntax highlighting.

On Wednesday, August 28, 2013 3:09:11 PM UTC-7, JvJ wrote:
>
> Although semicolons cause the text color to change in order to look 
> "commented-out", the #_ reader macro doesn't cause any such change.  Is 
> this intended, or is it a bug?
>

-- 
-- 
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: Searching for Regular Expressions in a file

[Joel Holdbrooks]

You could use *line-seq* which, if I'm not mistaken, is lazy. Then do your 
regex search line by line lazily.

On Monday, August 12, 2013 4:25:15 PM UTC-7, JvJ wrote:
>
> Is there a way to do a regex search over an entire file without loading 
> the file into memory?
>

-- 
-- 
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: Invalid token exception on a / operator

[Joel Holdbrooks]

I've been stung by this too. One work around I use is *(:refer-clojure 
:exclude [/])* and *(:require [some.ns :refer [/])* in my *ns* form. Then 
refer to *clojure.core//* directly if needed. It's good to hear this will 
be fixed in 1.6.

On Tuesday, July 30, 2013 5:26:23 AM UTC-7, Maik Schünemann wrote:
>
> Is / a valid clojure function name (valid, but not recommended)?
> I tought so because of clojure.core//
> in the repl there is also no problem with clojure.core//:
> clojure.core//
> ;=>#
> but if / is in another namespace, for example in core.matrix:
> clojure.core.matrix.operators//
> RuntimeException Invalid token: clojure.core.matrix.operators// 
>  clojure.lang.Util.runtimeException (Util.java:219)
>
> clearly this is an edge case, because / also separates namespaces but I 
> think
> if clojure.core// is valid clojure.core.matrix.operators// should also be 
> a valid token?!
>
> regards
> Maik Schünemann
>

-- 
-- 
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: YA regular expression tool

[Joel Holdbrooks]

Thanks. This tool was really more or less for fun but I'd been thinking 
about it for a while. According to some benchmarks it appears the generated 
patterns are pretty fast. When I get some more time, I definitely want to 
see if converting the word trie to a DAWG and then to a regular expression 
will produce even better patterns. Of course, this means pattern 
construction will be slower.

More or less I'd like some input on ways to improve the efficiency of the 
whole thing.

On Tuesday, July 30, 2013 3:49:49 AM UTC-7, Mikera wrote:
>
> On Monday, 29 July 2013 21:20:49 UTC+1, Joel Holdbrooks wrote:
>>
>> I spent some time this weekend writing a little tool for generating 
>> regular expressions *from known inputs*. My goal is to produce regular 
>> expressions that backtrack as few times as possible along with a complete 
>> and total disregard for readability. :)
>>
>> The code for the tool is here <https://github.com/noprompt/frak>. 
>> Suggestions/ideas would be greatly appreciated.
>>
>
> Nice - I like the fact that it has a very simple API that focuses on doing 
> just one thing well! 
>

-- 
-- 
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: changing a value in a vector of maps

[Joel Holdbrooks]

This probably won't help with your garbage collection worries, but it's a 
bit more flexible.

*(defn find-assoc-in [pred coll k v & kvs]*
*  (let [f #(if (pred %) (apply assoc % k v kvs) %)]*
*(into (empty coll) (map f coll*


On Tuesday, July 30, 2013 10:53:48 AM UTC-7, cej38 wrote:
>
> Suppose I have a vector of maps (this could also be a vector of records)
>
> (def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
>
> and I want to go in an change the value of associated with :c when :a has 
> a value of 50, so that the final col of maps looks like
>
> [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
>
>
>
> I came up with a function that does this:
>
> (defn find-assoc-in
>   [k v  mv]
>   (let [f #(if (= ((first k) %) (first v))
>  (assoc % (second k) (second v))
>  %)]
>  (map f mv)))
>
>
> (find-assoc-in [:a :c] [50 3] aa)
>
>
> The problem with this function is that it potentially does a lot 
> of unnecessary copying of elements that aren't changed, and thus has a lot 
> of garbage collection.  I would like help coming up with something that 
> does much less garbage collection.
>
>
> Will someone please point out a better way of doing this?
>
>

-- 
-- 
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: T-shirts?

[Joel Holdbrooks]

+1. I'd love this.

On Sunday, July 28, 2013 3:22:21 PM UTC-7, Isaac Wagner wrote:
>
> There was a discussion a while ago about stickers which led to 
> http://clojure.org/swag. Could we get some sanctioned T-shirts as well? 
> There are a few Clojure shirts on Zazzle, but what I would be interested in 
> is some black, grey, and white shirts with nothing but a big Clojure logo 
> on the front and I would love to buy them in a way that supports Clojure.
>
> Isaac
>

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

YA regular expression tool

[Joel Holdbrooks]

I spent some time this weekend writing a little tool for generating regular 
expressions *from known inputs*. My goal is to produce regular expressions 
that backtrack as few times as possible along with a complete and total 
disregard for readability. :)

The code for the tool is here . 
Suggestions/ideas would be greatly appreciated.

-- 
-- 
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: New CSS library - Garden

[Joel Holdbrooks]

Cool. I'm glad you like the library. Thanks for sharing your kind words and 
thoughts. :)

"I admit it's weird that it just vector-izes its arguments, and does nothing 
else."

In that case I don't think you need a macro, just alias rule to vector and 
you'll achieve the same end.

"I think it should be part of the garden lib..."

I don't think there would be any harm in adding this as an alias;  I tend to do 
a similar thing aliasing styles to list. 

"And abstracting really feels like it shouldn't be used to solve the problem of 
indentation."

That's definitely not the only reason why defrule was added but it could be 
used to address that problem which is why I brought it up. The beautiful thing 
about programming stylesheets in Clojure is that we can come up with whatever 
abstractions/techniques we like without being tied down by syntax. There's a 
lot of potential there for some interesting ideas.

"I've been experimenting with some ways of integrating it with compojure for 
some Rails4-like "asset-pipelining"..."

Some people are definitely looking for this. If you come up with something, 
even a simple gist, please share it. I'm still loading/compiling stylesheets 
manually. :P

Oh, I don't know if you saw this gist but there's also some interest in ideas 
surrounding grid systems.

Thanks,

Joel

On Jul 6, 2013, at 7:41 PM, Steven Degutis  wrote:

> Right, I understand how defrule works. But I actually do have 27 [i.e. O(n)] 
> distinct rules, so it's not a feasible solution.
> 
> Because when I write CSS, I only style domain-specific class names (.cart, 
> .license), never mentioning the elements they just so happen to use at the 
> moment (h1, p, a). This lets me change the implementation quickly and easily. 
> And it makes it easier to write for other devices/sizes.
> 
> So really I only use defrule for the pseudo-selectors you just linked to 
> (hover, active, nth-child). Besides that I really have no use for it.
> 
> And abstracting really feels like it shouldn't be used to solve the problem 
> of indentation. Besides, like Dan Neumann mentioned in that Github Issue, 
> abstracting anything in my stylesheet too early can lead to wrong 
> abstractions that are difficult to revert. So right now I define an entire 
> section (header, footer, cart) as one big nested vector, nothing extracted. 
> Sure, I'll probably clean it up later, but only after I have more pages and 
> can see more patterns emerging clearly.
> 
> Although, I have abstracted one thing which I hope will turn out useful:
> (def clearfix
>   [:&
>[:&:after {:clear "both"}]
>[:&:before
> :&:after {:display "table" :content "''"}]])
> Then you can embed it as a rule anywhere that you need to clear some floats:
> [:.some-container-with-floats clearfix]
> But as for indentation, so far I'm liking the "rule" macro more and more. I 
> admit it's weird that it just vector-izes its arguments, and does nothing 
> else. But the fact that it's a function call fixes the indentation problem 
> wonderfully.
> 
> I think it should be part of the garden lib, really. Although lately I've 
> renamed it to "%" so my eyes aren't drawn to the wrong thing when I'm 
> skimming my rules. It was "!" for a while but that was weirder thanks to it 
> being right after a long skinny parenthese. But either way, these all make 
> nested rules much easier to visually scan.
> 
> Anyway I really love using Garden. Thanks for writing it!
> 
> I've been experimenting with some ways of integrating it with compojure for 
> some Rails4-like "asset-pipelining" (whatever that means), and it works 
> really well but the API is still a little raw. But if I come up with anything 
> good I'll try to share it.
> 
> -Steven
> 
> 
> On Sat, Jul 6, 2013 at 8:52 PM, Joel Holdbrooks  
> wrote:
> Hi Steven,
> 
> I know that readability is a bit of an issue for some people. Unfortunately 
> there isn't much I can do other than point folks to the defrule macro and 
> some of the other suggestions I've made. As I work with the Garden I see 
> problem areas too and am working to find solutions that will make using the 
> library more palatable.
> 
> Speaking of defrule, and correct me if I'm missing something, but I think you 
> might be a bit confused about it's nature. You should think of defrule as a 
> way to create selector functions. I'll admit this was bad naming on my part 
> and I'll probably make an alias called defselector. Those "selectors"  can be 
> as generic or precise as

Re: New CSS library - Garden

[Joel Holdbrooks]

Hi Steven,

I know that readability is a bit of an issue for some people. Unfortunately 
there isn't much I can do other than point folks to the defrule macro and some 
of the other suggestions I've made. As I work with the Garden I see problem 
areas too and am working to find solutions that will make using the library 
more palatable.

Speaking of defrule, and correct me if I'm missing something, but I think you 
might be a bit confused about it's nature. You should think of defrule as a way 
to create selector functions. I'll admit this was bad naming on my part and 
I'll probably make an alias called defselector. Those "selectors"  can be as 
generic or precise as you like and possess the same semantics as normal vector 
based Garden code but are more flexible (since they are functions). Also, they 
should give you the indentation you are looking for.

(defrule a :a)
(defrule footer :footer)

(footer {:color "red"
 :background-color "blue"}
(a {:color "green"}))

"But if I have 3 elements with 3 children each, and each child has 3 children, 
that's already 27 defrules I have to stick above it. That'll get pretty unruly 
quick."

Only if you have 27 distinct elements that you have no intention of ever 
reusing. Observe:

;; These forms are all semantically equivalent.

(footer {:color "red"
 :background-color "blue"}
(a {:color "green"}))

[:footer {:color "red"
  :background-color "blue"}
 (a {:color "green"})]

(footer {:color "red"
 :background-color "blue"}
[:a {:color "green"}])

;; This works too.  

(defrule h1 :h1)
(defrule hover "&:hover")

(footer
 (h1 {:font-weight "normal"}
 (hover {:font-weight "bold"}))
 (a {:text-decoration "none"}
(hover {:text-decoration "underline"})))


To make life easier I will add all known HTML selectors (via defrule) and make 
some tweaks to it's behavior today. As of this moment most of the pseudo 
classes have been implemented here.

I hope this helps clear things up. Again, if I'm not understanding you 
correctly, please let me know.

Thanks,

Joel

On Jul 6, 2013, at 6:58 AM, Steven Degutis  wrote:

> So far, I really like Garden.
> 
> There's one thing though that's making it difficult. It's hard to see that 
> nested rules are nested.
> ;; hard to see nesting
> [:footer {:color "red"
>   :background-color "blue"}
>  [:a {:color "green"}]]
> 
> ;; much easier
> (:footer {:color "red"
>   :background-color "blue"}
>  [:a {:color "green"}])
> (That's a bad example because it's so short. In the real world, much longer 
> and deeper-nested rules show it clearer.)
> 
> Technically I'm using emacs with clojure-mode.el, which indents vectors by 
> only 1 char. But I don't think that's the problem. Normally it's good to 
> indent them by only 1 char, but there's no way to differentiate between 
> [:some [:random :data]], which should be indented like that, and a vector of 
> garden-rules which should be indented more obviously. So I don't think this 
> is something that changing our editors/plugins will fix.
> 
> One solution is to use defrule more often. But if I have 3 elements with 3 
> children each, and each child has 3 children, that's already 27 defrules I 
> have to stick above it. That'll get pretty unruly quick.
> 
> So I was thinking of just using a dummy macro like this:
> (defmacro rule [& body] `[~@body])
> 
> (def footer
>   (rule :footer {:color "red"
>  :background-color "blue"}
> (rule :a {:color "green"})))
> But you can imagine my discomfort at writing/using a macro just to make 
> indentation easier.
> 
> Are there any better solutions to this?
> 
> -Steven
> 
> 
> On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks  
> wrote:
> Nobel Clojurians,
> 
> I am pleased to announce the alpha version of Garden, a new library for 
> writing CSS in Clojure.
> 
> The project weds the best ideas from Hiccup, gaka, and cssgen and aims to 
> provide a clean and conventional way to author stylesheets without being too 
> simple or too complex.
> 
> Currently the list of notable features include:
> Nestable rules
> Nestable declarations (this my change)
> A builtin set of tools for working with CSS unit values
> Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
> Output formatting options
> What's planned for the near future:
> The ability to use 

Re: New CSS library - Garden

[Joel Holdbrooks]

Rob,

Sorry for the late reply. I've been a bit distracted the past few days.
I'll try to address your thoughts as best I can.

*There could even be a grid protocol and fluid, responsive, fixed, mobile,
etc be implementations of it, or multi-methods, or maybe its an overkill.*

I don't think this is overkill. At the very least it's probably worth
exploring. While I was "translating" the semantic grid SCSS code to
Clojure, protocols did cross my mind. As I noted in the code comments there
are a handful of "core" functions you see in virtually every grid system;
well, in virtually every grid system I've ever seen. My instincts lead me
to believe experimenting with protocols would be a step in the right
direction.

*... image overlay ... that could be really nice since a lot of designers
still hand in photoshop illustrations that developers need to fit in*

We have the JVM at our disposal. I'm fairly certain this could be a simple
task although I'm not certain where one would start (probably Google).

*Do you plan on incorporating a grid framework/concept in Garden?
*

Yes, but I'm waiting until Garden is no longer in beta (which should only
be for another month or so). If you, or anyone reading this, would like to
share gists/concepts for a grid framework that would definitely help keep
the ball rolling. My main focus right now is making sure I've covered the
most important topics (ie. color, units, comments, compilation) so people
can feel confident and productive - especially if they're coming from Sass
or another alt-css language.

*...the pound signs are causing reader errors...
*

That's because I was using *data_readers.clj*. Have a look
*here*<https://github.com/noprompt/garden/blob/master/dev/data_readers.clj>.
I would definitely encourage anyone using Garden to employee this approach.

Regarding the new CSS grid spec and not holding my breath. I won't. It'll
probably be at least a year or two before we see something solidified and
even longer before it's a viable option. It's a good idea but it still
needs a ton of work.

Anyhow, thanks for sharing your ideas! I look forward to hearing more from
you.

Joel


On Thu, Jun 27, 2013 at 11:09 AM, Rob Jens  wrote:

> P.p.s. the pound signs are causing reader errors (e.g. #px) in LightTable
> so I changed those plus additionally added a little Jetty
>
> https://gist.github.com/clojens/5878804
>
> Cheers
>
>
>
> Op dinsdag 9 april 2013 21:58:50 UTC+2 schreef Joel Holdbrooks het
> volgende:
>>
>> Nobel Clojurians,
>>
>> I am pleased to announce the alpha version of 
>> *Garden*<https://github.com/noprompt/garden>,
>> a new library for writing CSS in Clojure.
>>
>> The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
>> provide a clean and conventional way to author stylesheets without being
>> too simple or too complex.
>>
>> Currently the list of notable features include:
>>
>>- Nestable rules
>>- Nestable declarations (this my change)
>>- A builtin set of tools for working with CSS unit values
>>- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
>>- Output formatting options
>>
>> What's planned for the near future:
>>
>>- The ability to use Clojure meta as a media query
>>- A builtin set of tools for working with CSS color values
>>- & selector syntax for nested rules
>>
>> For those of you who are interested in this sort of thing, please have a
>> look at the *project's repository* <https://github.com/noprompt/garden>.
>> There is still quite a bit of ground to do cover and any
>> help/criticism/contribution would be greatly appreciated.
>>
>> Please feel free to offer suggestions, ask questions, open issues, or
>> send pull requests. I would love nothing more than to see this library
>> succeed where other's have not.
>>
>>
>> Truly,
>>
>> Joel Holdbrooks (aka noprompt)
>>
>>  --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/xbFU2prTxlY/unsubscribe.
>

Re: New CSS library - Garden

[Joel Holdbrooks]

Cool. I haven't seen this one before. Since it was fairly simple I 
reimplemented it in Clojure with Garden. *Here's the 
gist.*<https://gist.github.com/noprompt/5873715>

I took a functional approach using higher order functions. It could be a 
little cleaner but then again *the arithmetic isn't all on one 168 
character line 
either*<https://github.com/twigkit/semantic.gs/blob/master/stylesheets/scss/grid.scss#L63>.
 
There are a few refactorings and nearly all of it is documented in a 
literate programming style.

On Wednesday, June 26, 2013 5:41:56 AM UTC-7, Rob Jens wrote:
>
> Hey Jeremy,
>
> You might be interested, in case you hadn't heard of it yet, of the 
> Semantic Grid (http://semantic.gs) probably in particular their Stylus 
> version 
> https://github.com/twigkit/semantic.gs/blob/master/stylesheets/styl/grid.styl 
> but 
> depending on your taste/clarity might also wish to check out their grid in 
> Sass/SCSS. 
>
> Its math is quite elegant and simple.
>
> Cheers,
> Rob
>
> Op woensdag 19 juni 2013 13:14:03 UTC+2 schreef JeremyS het volgende:
>>
>> Hi Joel,
>>
>> Thank for the interest ! You can also take a look at some code have done 
>> around css unit types there <https://github.com/JeremS/units>. It's got 
>> arithmetic for 
>> units and a namespace dedicated to colors. In it you'll find conversions 
>> between rgb en hsl (that I have taken from the color 
>> library<https://github.com/jolby/colors>
>> )
>> and the implementation of SASS color helpers. May be you could adapt my 
>> library to garden. From what I have seen Garden uses
>> protocols to compile different types into css and every unit (including 
>> colors) I define is a record. So you might be able to extend my library 
>> with Garden protocols and use it in garden without much effort. I'd be glad 
>> to see that !
>>
>> About higher order function I have thought about that and went back, my 
>> first approach made for to complicated function (complected even). With the 
>> actual implementation I can just define stuff like:
>>
>> (def grid {}) ; grid spec with column, gutter...
>>
>> (def width (partial grid/witdh grid))
>> (def push (partial grid/push grid))
>>
>>
>> and then :
>>
>> (def side-style [:#side (width 4) 
>> (push 1)])
>>
>> for a side element spanning onto 4 columns and pushed off 1.
>>
>>
>> Regarding more advanced systems like Foundation I haven't spent much time 
>> trying to implement them with my DSL.
>> To do so I need to up my CSS game because I am not yet well versed into 
>> the art of responsive design and it will take me
>> a bit of time wrapping my head around the media queries involved. If I 
>> try to got responsive, I might probably study 
>> the Unsemantic <http://unsemantic.com> system from the creator of the 
>> 960 one I think.
>>
>> Good luck with your work and don't hesitate on browsing my github, right 
>> now most of the projects are oriented around CSS and there 
>> might be some ideas there who knows ! 
>>
>> On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:
>>>
>>> Jeremy,
>>>
>>> Looks good. I've been tinkering with grid systems on and off for the 
>>> past month or so. Have you thought of trying your hand at porting something 
>>> like the Foundation or Gumby grid system?
>>>
>>> One thing I've discovered, and you might try this with your 960 
>>> implementation, is that using higher order functions can be very handy for 
>>> building them out. For example, a *make-grid* function which accepts a 
>>> map of configuration options and returns a function which takes a column 
>>> number and optional parameters for, say, push and pull. It's a nice way to 
>>> package things up.
>>>
>>> I'm close to wrapping up a small colors framework for Garden which will 
>>> be available in the next beta (hopefully it won't be in beta much longer). 
>>> When I take it out of beta it'll probably include a Clojure flavored 
>>> implementation of either the grid system that ships with Bootstrap or 
>>> Foundation (including the mobile parts).
>>>
>>> On the side I've been taking of advantage of Clojure to create a new 
>>> concept for a *layout* system. It's based on the font-size/line-height 
>>> ratio and allows for the construction of stylesheets such that the grid 
>>> system and 

Re: New CSS library - Garden

[Joel Holdbrooks]

Garden 0.1.0-beta5 is now available! The newest version includes functions 
for working with *color* <https://github.com/noprompt/garden#color> and 
performing generic 
*arithmetic*<https://github.com/noprompt/garden#arithemetic>(ie. operators for 
transparently adding numbers and units or numbers and 
colors). All of the familiar Sass color functions have been added to the 
library along with some new functions for generating triads, tetrads, and 
other sets of colors. Essentially (almost) anything you can do with Sass 
colors you can do in Garden just as conveniently. There are a few small 
tweaks that need to be addressed around color transparency which will be 
addressed in the near future. Check out the updated README at the project *home 
page <https://github.com/noprompt/garden>* for more information.

The library is getting closer to being a viable alternative to other CSS 
preprocessors (at least in my opinion). It's a slow burn but eventually 
it'll get there!

Thanks to everyone for remaining interested in the project and please 
continue to give me feedback.

On Tuesday, April 9, 2013 12:58:50 PM UTC-7, Joel Holdbrooks wrote:
>
> Nobel Clojurians,
>
> I am pleased to announce the alpha version of 
> *Garden*<https://github.com/noprompt/garden>, 
> a new library for writing CSS in Clojure.
>
> The project weds the best ideas from Hiccup, gaka, and cssgen and aims to 
> provide a clean and conventional way to author stylesheets without being 
> too simple or too complex.
>
> Currently the list of notable features include:
>
>- Nestable rules
>- Nestable declarations (this my change)
>- A builtin set of tools for working with CSS unit values
>- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
>- Output formatting options
>
> What's planned for the near future:
>
>- The ability to use Clojure meta as a media query
>- A builtin set of tools for working with CSS color values
>- & selector syntax for nested rules 
>
> For those of you who are interested in this sort of thing, please have a 
> look at the *project's repository* <https://github.com/noprompt/garden>. 
> There is still quite a bit of ground to do cover and any 
> help/criticism/contribution would be greatly appreciated.
>
> Please feel free to offer suggestions, ask questions, open issues, or send 
> pull requests. I would love nothing more than to see this library succeed 
> where other's have not. 
>
>
> Truly,
>
> Joel Holdbrooks (aka noprompt)
>
>

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

Packaging data_readers.clj with a Clojar

[Joel Holdbrooks]

Tagged literals are really neat. The other day I discovered what seems to 
be a fairly good use case for them (see discussion 
here). 
At the time I wasn't sure if data_readers.clj could be packaged with a 
Clojar but it appears it can. 

While part of me finds this attractive, I wonder, is this a good idea?

-- 
-- 
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: New CSS library - Garden

[Joel Holdbrooks]

Jeremy,

Looks good. I've been tinkering with grid systems on and off for the past month 
or so. Have you thought of trying your hand at porting something like the 
Foundation or Gumby grid system?

One thing I've discovered, and you might try this with your 960 implementation, 
is that using higher order functions can be very handy for building them out. 
For example, a make-grid function which accepts a map of configuration options 
and returns a function which takes a column number and optional parameters for, 
say, push and pull. It's a nice way to package things up.

I'm close to wrapping up a small colors framework for Garden which will be 
available in the next beta (hopefully it won't be in beta much longer). When I 
take it out of beta it'll probably include a Clojure flavored implementation of 
either the grid system that ships with Bootstrap or Foundation (including the 
mobile parts).

On the side I've been taking of advantage of Clojure to create a new concept 
for a layout system. It's based on the font-size/line-height ratio and allows 
for the construction of stylesheets such that the grid system and typography 
are harmonious. IOW it's a fat pain in the ass, but I don't think I could even 
fathom the idea of doing it in Sass.

TL;DR you have Clojure at your disposal! Though we're SOL on some very nice 
Sass libraries, we can potentially do more and at a higher level!

Thanks for sharing! It's inspiring.

On Jun 18, 2013, at 4:41 AM, JeremyS  wrote:

> Hi Joel,
> 
> I have a quick and dirty implementation of a 960-ish grid system using a DSL 
> similar to garden If you want to take a look.
> 
> 
> 
> On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:
> It's funny you should bring that up! I've actually been working on extracting 
> the grid system from Bootstrap and modular scale from Foundation. But it's 
> mostly been tinkering.
> 
>   I am sorely tempted to give this a try.
> 
> Please do! If I come up with something I'll be sure to share a Gist.
> 
> 
> On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach  
> wrote:
> One interesting thing you could do, given both Garden and
> ClojureScript, is package CSS frameworks like Twitter Bootstrap or
> Zurb Foundation as a Clojure library. I am sorely tempted to give this
> a try.
> 
> On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks  wrote:
> > Murtaza,
> >
> > Thanks for having a look at the library. I'll try to answer you questions as
> > best as I can.
> >
> >
> > How does Garden compare to other pre processors such as sass and less?
> >
> > There are some similarities with Garden and other CSS preprocessors. I've
> > tried to bring over the ones I found most useful when using them. Nested
> > selectors and declarations, parent selector references, and unit arithmetic
> > are all currently available to stylesheet authors.
> >
> > The big difference and, in my opinion, the big win is you can build your
> > stylesheets with regular Clojure. This gives you a lot of power and freedom
> > you won't find anywhere else (AFAIK). To name just a few benefits:
> >
> > There's no file parsing or interpretation step. It's just data
> > transformation.
> > There's no need for any sort of special @mixin syntax or macros, you can use
> > Clojure function.
> > There's no need for an @include directive thanks to clojure namespaces. This
> > can help you organize your stylesheet in ways (I think) are much cleaner and
> > less surprising than SASS and other preprocessors.
> > Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which,
> > if you look closely, can be pretty random in some places.
> >
> > WIth regard to the third point, if you've ever tried using the SMACSS
> > approach to stylesheet authoring with a preprocessor like SASS, you can end
> > up with an explosion of files and tons of @include directives. It's not fun,
> > it's hard to manage, and it's difficult to see where code is coming from -
> > especially when using 3rd-party libraries.
> >
> > Also can I use it in my clojurescript projects ? I mean does it have any
> > java lib dependencies that would prevent it?
> >
> > It does have one small dependency on java.net.URI but I need some time to
> > think about whether or not it would be worth dropping. As far as using it
> > from a ClojureScript project, what sort of use case are you considering?
> >
> > What is the workflow when using Garden?
> >
> > My experience using Garden is probably close to others at this point. It's
> > kind of fun

Re: New CSS library - Garden

[Joel Holdbrooks]

It's funny you should bring that up! I've actually been working on
extracting the grid system from Bootstrap and modular scale from
Foundation. But it's mostly been tinkering.

*  I am sorely tempted to give this a try.*

Please do! If I come up with something I'll be sure to share a Gist.


On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:

> One interesting thing you could do, given both Garden and
> ClojureScript, is package CSS frameworks like Twitter Bootstrap or
> Zurb Foundation as a Clojure library. I am sorely tempted to give this
> a try.
>
> On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks 
> wrote:
> > Murtaza,
> >
> > Thanks for having a look at the library. I'll try to answer you
> questions as
> > best as I can.
> >
> >
> > How does Garden compare to other pre processors such as sass and less?
> >
> > There are some similarities with Garden and other CSS preprocessors. I've
> > tried to bring over the ones I found most useful when using them. Nested
> > selectors and declarations, parent selector references, and unit
> arithmetic
> > are all currently available to stylesheet authors.
> >
> > The big difference and, in my opinion, the big win is you can build your
> > stylesheets with regular Clojure. This gives you a lot of power and
> freedom
> > you won't find anywhere else (AFAIK). To name just a few benefits:
> >
> > There's no file parsing or interpretation step. It's just data
> > transformation.
> > There's no need for any sort of special @mixin syntax or macros, you can
> use
> > Clojure function.
> > There's no need for an @include directive thanks to clojure namespaces.
> This
> > can help you organize your stylesheet in ways (I think) are much cleaner
> and
> > less surprising than SASS and other preprocessors.
> > Thanks to Clojure, Garden (potentially) has clearer syntax than CSS
> which,
> > if you look closely, can be pretty random in some places.
> >
> > WIth regard to the third point, if you've ever tried using the SMACSS
> > approach to stylesheet authoring with a preprocessor like SASS, you can
> end
> > up with an explosion of files and tons of @include directives. It's not
> fun,
> > it's hard to manage, and it's difficult to see where code is coming from
> -
> > especially when using 3rd-party libraries.
> >
> > Also can I use it in my clojurescript projects ? I mean does it have any
> > java lib dependencies that would prevent it?
> >
> > It does have one small dependency on java.net.URI but I need some time to
> > think about whether or not it would be worth dropping. As far as using it
> > from a ClojureScript project, what sort of use case are you considering?
> >
> > What is the workflow when using Garden?
> >
> > My experience using Garden is probably close to others at this point.
> It's
> > kind of funny in that regard. I'm building a tool and at the same time am
> > learning how to use it. Personally, I create a namespace for my "core"
> > stylesheets and separate namespaces for things like utilities and so
> forth
> > (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a
> call
> > to function that compiles and saves the stylesheet at the bottom of the
> > "core" stylesheets. Since I develop with Emacs and nREPL this means all I
> > have to do is reload the file and the CSS is "refreshed".
> >
> > It isn't the best approach, but Garden is still very young and I haven't
> > thought about how a standardize the build process. But I would
> definitely be
> > open to any thoughts regarding that. A Leiningen plugin would be awesome!
> >
> >
> > I hope these answers are helpful. Please continue to experiment with the
> > library and express your thoughts!
> >
> > Thanks,
> >
> > Joel
> >
> >
> > On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
> >  wrote:
> >>
> >> Joel,
> >>
> >> Thanks for the lib. Its great and I plan to use it in my projects.
> >>
> >> How does Garden compare to other pre processors such as sass and less ?
> >>
> >> Also can I use it in my clojurescript projects ? I mean does it have any
> >> java lib dependencies that would prevent it?
> >>
> >> What is the workflow when using Garden ? If I am using Sass, I would
> >> create a .scss file, and the sass daemon would watch over any changes
> to the
> >> file and compile it to 

Re: New CSS library - Garden

[Joel Holdbrooks]

Murtaza,

Thanks for having a look at the library. I'll try to answer you questions
as best as I can.


*How does Garden compare to other pre processors such as sass and less?*
*
*
There are some similarities with Garden and other CSS preprocessors. I've
tried to bring over the ones I found most useful when using them. Nested
selectors and declarations, parent selector references, and unit arithmetic
are all currently available to stylesheet authors.

The big difference and, in my opinion, the big win is you can build your
stylesheets with regular Clojure. This gives you a lot of power and freedom
you won't find anywhere else (AFAIK). To name just a few benefits:

   - There's no file parsing or interpretation step. It's just data
   transformation.
   - There's no need for any sort of special *@mixin* syntax or macros, you
   can use Clojure function.
   - There's no need for an *@include* directive thanks to clojure
   namespaces. This can help you organize your stylesheet in ways (I think)
   are much cleaner and less surprising than SASS and other preprocessors.
   - Thanks to Clojure, Garden (potentially) has clearer syntax than CSS
   which, if you look closely, can be pretty random in some places.

WIth regard to the third point, if you've ever tried using the SMACSS
approach to stylesheet authoring with a preprocessor like SASS, you can end
up with an explosion of files and tons of *@include* directives. It's not
fun, it's hard to manage, and it's difficult to see where code is coming
from - especially when using 3rd-party libraries.

*Also can I use it in my clojurescript projects ? I mean does it have any
java lib dependencies that would prevent it?*
*
*
It does have one small dependency on java.net.URI but I need some time to
think about whether or not it would be worth dropping. As far as using it
from a ClojureScript project, what sort of use case are you considering?

*What is the workflow when using Garden?*
*
*
My experience using Garden is probably close to others at this point. It's
kind of funny in that regard. I'm building a tool and at the same time am
learning how to use it. Personally, I create a namespace for my "core"
stylesheets and separate namespaces for things like utilities and so forth
(ie. *(ns me.css (:require [me.css.button :as button])*) . Then I have a
call to function that compiles and saves the stylesheet at the bottom of
the "core" stylesheets. Since I develop with Emacs and nREPL this means all
I have to do is reload the file and the CSS is "refreshed".

It isn't the best approach, but Garden is still very young and I haven't
thought about how a standardize the build process. But I would definitely
be open to any thoughts regarding that. A Leiningen plugin would be awesome!


I hope these answers are helpful. Please continue to experiment with the
library and express your thoughts!

Thanks,

Joel


On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain <
murtaza.hus...@sevenolives.com> wrote:

> Joel,
>
> Thanks for the lib. Its great and I plan to use it in my projects.
>
> How does Garden compare to other pre processors such as sass and less ?
>
> Also can I use it in my clojurescript projects ? I mean does it have any
> java lib dependencies that would prevent it?
>
> What is the workflow when using Garden ? If I am using Sass, I would
> create a .scss file, and the sass daemon would watch over any changes to
> the file and compile it to .css.
>
> As I understand garden is generating css when called with the fn/macro
> (css [...]). Would it make sense to have a similar workflow like above;
> where a leiningen plugin watches for any .garden files and compiles them to
> .css files ? Or is there a better workflow that I am missing?
>
> Thanks,
> Murtaza
>
>
> On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:
>>
>> As of today, Garden is officially out of alpha and in to beta!
>>
>> The library now sports media 
>> queries<https://github.com/noprompt/garden#media-queries> (via
>> meta data) and parent selector 
>> references<https://github.com/noprompt/garden#parent-selector-references> 
>> (ie.
>> "&hover"). With these new features it is now possible to build more
>> sophisticated stylesheets bringing us a step closer to having a viable CSS
>> alternative in Clojure.
>>
>> Over the course of the next few weeks, I plan to continue improving the
>> library by adding "missing" features and functions to make the library as
>> powerful as possible when it's release as 0.1.0 stable.
>>
>> Now more than ever, I would like to encourage others in the community to
>> reach out with suggestions and code review. This my first "real&q

Re: New CSS library - Garden

[Joel Holdbrooks]

As of today, Garden is officially out of alpha and in to beta!

The library now sports media 
queries (via 
meta data) and parent selector 
references (ie. 
"&hover"). With these new features it is now possible to build more 
sophisticated stylesheets bringing us a step closer to having a viable CSS 
alternative in Clojure.

Over the course of the next few weeks, I plan to continue improving the 
library by adding "missing" features and functions to make the library as 
powerful as possible when it's release as 0.1.0 stable.

Now more than ever, I would like to encourage others in the community to 
reach out with suggestions and code review. This my first "real" Clojure 
library and after only six months with the language I'm sure it could 
benefit greatly from both of these things.

-- 
-- 
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: New CSS library - Garden

[Joel Holdbrooks]

As of today, Garden is officially out of alpha and in to beta!

The library now sports media 
queries<https://github.com/noprompt/garden#media-queries>(via meta data) and 
parent 
selector 
references<https://github.com/noprompt/garden#parent-selector-references>(ie. 
"&hover"). With these new features it is now possible to build more 
sophisticated stylesheets bringing us a step closer to having a viable CSS 
alternative in Clojure.

Over the course of the next few weeks, I plan to continue improving the 
library by adding "missing" features and functions to make the library as 
powerful as possible when it's release as 0.1.0 stable.

Now more than ever, I would like to encourage others in the community to 
reach out with suggestions and code review. This my first "real" Clojure 
library and after only six months with the language I'm sure it could 
benefit greatly from both of these things.


On Tuesday, April 9, 2013 12:58:50 PM UTC-7, Joel Holdbrooks wrote:
>
> Nobel Clojurians,
>
> I am pleased to announce the alpha version of 
> *Garden*<https://github.com/noprompt/garden>, 
> a new library for writing CSS in Clojure.
>
> The project weds the best ideas from Hiccup, gaka, and cssgen and aims to 
> provide a clean and conventional way to author stylesheets without being 
> too simple or too complex.
>
> Currently the list of notable features include:
>
>- Nestable rules
>- Nestable declarations (this my change)
>- A builtin set of tools for working with CSS unit values
>- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
>- Output formatting options
>
> What's planned for the near future:
>
>- The ability to use Clojure meta as a media query
>- A builtin set of tools for working with CSS color values
>- & selector syntax for nested rules 
>
> For those of you who are interested in this sort of thing, please have a 
> look at the *project's repository* <https://github.com/noprompt/garden>. 
> There is still quite a bit of ground to do cover and any 
> help/criticism/contribution would be greatly appreciated.
>
> Please feel free to offer suggestions, ask questions, open issues, or send 
> pull requests. I would love nothing more than to see this library succeed 
> where other's have not. 
>
>
> Truly,
>
> Joel Holdbrooks (aka noprompt)
>
>

-- 
-- 
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: New CSS library - Garden

[Joel Holdbrooks]

Awesome. Yes, please do!

Also, feel free to suggest ideas for features. I'm focusing on media 
queries and "&" prefixed selectors this week, but I'd love to see if anyone 
has good ideas surrounding attribute and child selectors. Right now the 
best we can do is "input[type=\"text\"]" and "ul > li" which is, well, 
pretty nasty.

Thanks for trying it out!

On Wednesday, April 10, 2013 12:37:49 PM UTC-7, Dan Neumann wrote:
>
> Good stuff! 
>
> I'm using it in my hobby apps while I continue to cut my teeth on 
> Clojure's web development toolkit. 
>
> I'll definitely communicate any problems/improvements I spot as I try to 
> scratch my own itch.
>
>
>

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

New CSS library - Garden

[Joel Holdbrooks]

Nobel Clojurians,

I am pleased to announce the alpha version of 
*Garden*<https://github.com/noprompt/garden>, 
a new library for writing CSS in Clojure.

The project weds the best ideas from Hiccup, gaka, and cssgen and aims to 
provide a clean and conventional way to author stylesheets without being 
too simple or too complex.

Currently the list of notable features include:

   - Nestable rules
   - Nestable declarations (this my change)
   - A builtin set of tools for working with CSS unit values
   - Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
   - Output formatting options

What's planned for the near future:

   - The ability to use Clojure meta as a media query
   - A builtin set of tools for working with CSS color values
   - & selector syntax for nested rules 

For those of you who are interested in this sort of thing, please have a 
look at the *project's repository* <https://github.com/noprompt/garden>. 
There is still quite a bit of ground to do cover and any 
help/criticism/contribution would be greatly appreciated.

Please feel free to offer suggestions, ask questions, open issues, or send 
pull requests. I would love nothing more than to see this library succeed 
where other's have not. 


Truly,

Joel Holdbrooks (aka noprompt)

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