Re: Meta-eX - The Music of Code

[Islon Scherer]

Overtone is amazing, I'm planning on doing some experiments with it as soon 
as I finish the supercollider book and improve my music theory skills.

On Friday, April 11, 2014 4:44:22 PM UTC+2, Sam Aaron wrote:
>
>
> On 10 Apr 2014, at 03:18, Earl Jenkins > 
> wrote: 
>
> > Good stuff, all the hard work you've done in the field of live coding, 
> yet no mention of Meta-ex nor clojure in the Computer Music Journal which 
> has a whole issue dedicated to this subject  ;( 
>
> To be honest, Overtone was never targeted at academics. It was built for 
> Clojure hackers to be able to use their programming skills to realise their 
> musical ideas. As such, it's gained a lot of traction with progressional 
> programmers. 
>
> I'm continuously amazed with what people are doing with Overtone - 
> stretching it in incredible ways. However, I feel that the best is still 
> yet to come. Now is a fantastic time to get involved... 
>
> Sam 
>
> --- 
> http://sam.aaron.name

-- 
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: Annotations on gen-class :state

[Colin Fleming]

gen-class really isn't suitable for doing complicated interop like
annotating fields. It's heavily oriented towards a single means of managing
state, which is a single field generally containing an atom, which in turn
contains your actual state in a map or similar. If you really need multiple
fields you can use deftype/defrecord, but they come with different
restrictions - no inheritance, don't require their namespace on class init
which is required for many use cases where you might want field
annotations. I'm also not sure if their fields can be annotated.

In general when you start needing that level of interop, the easiest thing
is just to write a Java class and call into Clojure from there as required.


On 14 April 2014 14:28, Jon Seltzer  wrote:

> There are many Java APIs that expect client APIs to annotate fields but
> Clojure does not support annotations on fields.  Is there any plan to add
> support?
>
> And one tangential question:  Is there any consideration of adding
> gen-class support for multiple fields instead of just one?
>
> jbs
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: cljs, websocket, autoreconnect

[Gary Trakhman]

Oh good. I don't think I'd stop using jetty for the sake of websockets.  If
sente has a backend impl that can be made compatible with it, then is
consider that, but the jetty-websockets-async lib is relatively
straightforward. This reconnecting closure websocket fixes my last major
issue.

On Monday, April 14, 2014, Johann Bestowrous 
wrote:

> Google Closure implements an auto-reconnecting websocket.
>
> You can read docs on it 
> here
>  and
> see an example of it being imported 
> here
>  and
> used 
> here
>
> On Sunday, April 13, 2014 6:16:08 PM UTC-7, t x wrote:
>>
>> Hi,
>>
>>   For building robust cljs web apps, I'd like to have a "uber
>> websocket" which does the following:
>>
>>   * when disconnected, it auto reconnects
>>   * and re-sends any messages that were not received
>>
>>   Before I hand-roll my own hacks, I was wondering -- is there any
>> existing cljs library which already does this?
>>
>> 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.
>

-- 
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: [Video] Game development in Clojure (with play-clj)

[halitolali]

Great video, thanks!

On Monday, April 14, 2014 5:41:45 AM UTC+3, Kashyap CK wrote:
>
> +1 nice video
>
>
> On Mon, Apr 14, 2014 at 3:45 AM, Kris Calabio 
> > wrote:
>
>> Oh great! I guess I must have missed that :P
>>
>>
>> On Sun, Apr 13, 2014 at 3:13 PM, James Trunk 
>> > wrote:
>>
>>> There's a link to a gist of 
>>> core.cljin the video's 
>>> description.
>>>
>>> Cheers, 
>>> James
>>>
>>>
>>> On Monday, April 14, 2014 12:08:16 AM UTC+2, Kris Calabio wrote:
>>>
 Actually, I thought it would be even more helpful if you had the source 
 code available (for searching/skimming). Is that somewhere online?
 -Kris


  On Sun, Apr 13, 2014 at 2:47 PM, James Trunk wrote:

>  Hi Kris,
>
> Thanks for your comment, and I'm very glad that you found the video 
> helpful.
>
> I started doing screencasts because I realised that I learn a new 
> concept fastest by watching someone else doing/explaining it - and I 
> figured I might not be the only one. Saying that, I know screencasts 
> aren't 
> for everyone, and they have a few drawbacks compared to text (harder to 
> search, skim, or repeat sections). So positive comment like yours remind 
> me 
> that I'm not the only auditory/visual learner around here, and inspire me 
> to keep going. Thanks!
>
> James
>
>
> On Saturday, April 12, 2014 11:28:29 PM UTC+2, Kris Calabio wrote:
>>
>> Great video! I've looked through Zach's examples, and even started 
>> coding a game myself. But your screencast helped me have a better 
>> understanding of some of the concepts and code that I was having trouble 
>> understanding just by looking at the example games. Thanks!
>> -Kris
>>
>> On Thursday, March 27, 2014 10:07:21 AM UTC-7, James Trunk wrote:
>>>
>>> Hi everyone,
>>>
>>> I thought some of you might be interested to watch my screencast 
>>> about game development in Clojure with 
>>> play-clj
>>> .
>>>
>>> Cheers,
>>> James
>>>
>>  -- 
> 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 a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/mR1IBJ_OomY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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 a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/mR1IBJ_OomY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> clojure+u...@googlegroups.com .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@g

[ANN] Lambda Jam CFP - looking for Clojure talks

[Alex Miller]

Lambda Jam (http://www.lambdajam.com) is a conference about applied 
functional programming, focusing on Clojure, Scala, Erlang, Haskell, and F# 
with a significant hands-on component. This year the conference will return 
to Chicago July 22-23rd. Rich Hickey will be doing a keynote.

The Call for Presentations ends today (although we are considering pushing 
that back a week). I would love to see some more Clojure submissions! 

http://www.lambdajam.com/cfp.html

Thanks,
Alex 

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

Re: Uberjar woes

[Tom Connors]

Thanks for that tip, James - I'll look through the jars of my dependencies 
for spurious classes and post back here if I find anything that might be of 
value to future reader of this thread.

On Thursday, February 27, 2014 2:49:38 PM UTC-5, Tom Connors wrote:
>
> Hi Everyone,
> I've been having trouble creating an uberjar of a project and I'm hoping 
> someone here can point me toward a solution.
> After cleaning out the target directory (with "lein clean") and 
> preprocessing my cljx, I can run the project with no trouble using lein 
> repl and lein run. I can package up the project (lein with-profile prd 
> uberjar) and get the resultant jar files. After that, the trouble starts. 
> Running the jar (java -jar my-standalone.jar) fails with a 
> NoClassDefFoundError error, pointing at a protocol defined in 
> weaverjester's clout - 
> clout/core/Route. 
> I highly doubt clout actually has anything to do with the problem. After 
> creating the uberjar, I can no longer run the project with lein run or lein 
> repl - I get the same error, and I can't do anything with lein without 
> getting that error until I remove the target directory. 
> I've inspected the jar and can see that it contains clout, but just 
> clout/core.clj - no .class files. I edited clout's project.clj to include 
> :aot :all, packaged it into a jar, replaced the clout jar in my local maven 
> repo with that new jar, and re-packaged my project. At this point, when I 
> ran the jar, I got another NoClassDefFoundError, this time pointing at 
> another protocol, but this one from clojure.core: clojure/lang/ILookupHost.
> I've been having this problem with the latest leiningen (2.3.4) and 2.2.0. 
> I've been futzing with my project.clj for some time, but to no avail. Any 
> help greatly appreciated.
> -Tom
>

-- 
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: Helping newcomers get involved in Clojure projects

[Leif]

Below is a list of the top 1,000 clojure projects (by star count) from 
github with issues with labels that sound somewhat appropriate for 
newcomers.  Don't worry, the final list is way less than 1,000.

Considering the list, we see that:

   1. The community may want to attempt to standardize these labels.
   2. Most of the 1,000 projects had no such labels (or no issues at all).  
   I pessimistically take that to mean that there are lots of issues yet to be 
   found, and a newbie should just find a project in an area they know a lot 
   about, or are interested in, and stress test it.
   3. Some tags may need to be taken with a grain of salt.  E.g. an Om 
   issue tagged as "trivial" may or may not be so to, say, a newbie to clojure 
   who is not a professional UI developer.
   4. Everyone wants docs.  This may interest you less than programming, 
   but trust me, you'll have to do some programming with a library before you 
   can write sensible docs for it.  Also, you may in the process be able to 
   influence the API / usability of a library.
   
(["https://github.com/LightTable/LightTable"; #{"starter"}]
 ["https://github.com/technomancy/leiningen"; #{"usability" "docs" "Newbie"}]
 ["https://github.com/weavejester/compojure"; #{"easy" "trivial"}]
 ["https://github.com/swannodette/om"; #{"trivial" "example" "minor"}]
 ["https://github.com/overtone/overtone"; #{"newbie"}]
 ["https://github.com/nathanmarz/cascalog"; #{"newbies"}]
 ["https://github.com/marick/Midje"; #{"cleanup" "ripe-for-new-contributor" 
"better-error-msgs" "documentation"}]
 ["https://github.com/cemerick/friend"; #{"doc"}]
 ["https://github.com/pallet/pallet"; #{"Documentation" "Newbie"}]
 ["https://github.com/brentonashworth/one"; #{"sample application"}]
 ["https://github.com/clojure-liberator/liberator"; #{"documentation"}]
 ["https://github.com/emezeske/lein-cljsbuild"; #{"Documentation"}]
 ["https://github.com/relevance/labrepl"; #{"documentation"}]
 ["https://github.com/gdeer81/marginalia"; #{"cleanup" "docs"}]
 ["https://github.com/semperos/clj-webdriver"; #{"documentation"}]
 ["https://github.com/michaelklishin/monger"; #{"documentation"}]
 ["https://github.com/xsc/lein-ancient"; #{"better error message"}]
 ["https://github.com/neotyk/http.async.client"; #{"Docs"}]
 ["https://github.com/ato/clojars-web"; #{"cleanup"}]
 ["https://github.com/clojurewerkz/elastisch"; #{"low-hanging fruit" 
"usability" "documentation"}]
 ["https://github.com/michaelklishin/langohr"; #{"documentation"}]
 ["https://github.com/michaelklishin/validateur"; #{"documentation"}]
 ["https://github.com/cemerick/clojurescript.test"; #{"documentation"}]
 ["https://github.com/sonian/carica"; #{"documentation"}]
 ["https://github.com/michaelklishin/neocons"; #{"usability" 
"documentation"}]
 ["https://github.com/michaelklishin/quartzite"; #{"documentation"}]
 ["https://github.com/cfpb/qu"; #{"docs"}]
 ["https://github.com/michaelklishin/welle"; #{"documentation"}]
 ["https://github.com/abedra/accession"; #{"Documentation"}]
 ["https://github.com/Raynes/irclj"; #{"documentation"}]
 ["https://github.com/aaronfeng/trixx"; #{"bitesize"}]
 ["https://github.com/gameclosure/hermes"; #{"documentation"}]
 ["https://github.com/wri/forma-clj"; #{"cleanup"}]
 ["https://github.com/cgmartin/clj-wamp"; #{"docs"}])

--Leif

On Saturday, January 25, 2014 1:54:10 PM UTC-5, Bridget wrote:
>
> OpenHatch has this great 
> initiativefor encouraging newcomers 
> to get involved with open source projects. You 
> tag some issues in your bug tracker as "newcomer" or "easy". This provides 
> a gentle path into contributing. There is some work involved with this. You 
> have to do the tagging, and there needs to be some capacity in your project 
> for some mentoring.
>
> Leiningen is doing this  already with "newbie" 
> tagged issues, which is awesome.
>
> Are there any other Clojure projects that are doing this? Would you like 
> to do this with your project? If so, I can try to help. I have been 
> spending a lot of time thinking about the Clojure newcomer perspective 
> lately, and I'd like to work on some things that help smooth that path.
>
> Bridget
>

-- 
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: Annotations on gen-class :state

[Jon Seltzer]

This is unfortunate.  I certainly can write a Java class and I expected 
that would be the answer.  The question for me is whether, as a group, we 
see any value in having a consistent interface with the JVM.  One could 
argue that Clojure does not need any of the interop features it already 
has.  In fact, one might argue that all interop should occur by invoking 
pure Clojure from Java only but I hope most of us would agree that would 
not a very satisfying outcome.  The Clojure in Clojure work being done 
gives me hope this is going to change.  A Clojure compiler written in 
Clojure would almost certainly need to be full (or more fully) featured.

I like Stuart Sierra's quote (Twitter):  "Using Java libraries is idiomatic 
Clojure", and this is true for a lot of us using Clojure.

jbs

On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote:

> gen-class really isn't suitable for doing complicated interop like 
> annotating fields. It's heavily oriented towards a single means of managing 
> state, which is a single field generally containing an atom, which in turn 
> contains your actual state in a map or similar. If you really need multiple 
> fields you can use deftype/defrecord, but they come with different 
> restrictions - no inheritance, don't require their namespace on class init 
> which is required for many use cases where you might want field 
> annotations. I'm also not sure if their fields can be annotated. 
>
> In general when you start needing that level of interop, the easiest thing 
> is just to write a Java class and call into Clojure from there as required.
>
>
> On 14 April 2014 14:28, Jon Seltzer >wrote:
>
>> There are many Java APIs that expect client APIs to annotate fields but 
>> Clojure does not support annotations on fields.  Is there any plan to add 
>> support?
>>
>> And one tangential question:  Is there any consideration of adding 
>> gen-class support for multiple fields instead of just one?
>>
>> jbs
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Puppet Labs and Trapperkeeper

[Chris Price]

We published a follow-up post this morning, with a lot more detail on the 
Clojure side of things:

https://puppetlabs.com/blog/clojure-nerds-puppet-labs-application-services

On Sunday, April 13, 2014 6:48:10 PM UTC-7, Walter Heck wrote:
>
> As a non-clojure user, but a Puppet expert (ahum ;) ) I wrote a blog post 
> about this announcement that might be interesting for some folks here. I'd 
> also love to see comments on the post itself if I have drawn any wrong 
> conclusions:
> http://www.olindata.com/blog/2014/04/clojure-outsiders-investigation
>
> On Sunday, 13 April 2014 16:24:28 UTC+2, Brendan Younger wrote:
>>
>> I just saw that there's a library called TrapperKeeper 
>> https://github.com/puppetlabs/trapperkeeper from the folks at Puppet 
>> Labs.  It looks to be a more opinionated and complete version of Stuart 
>> Sierra's Component library https://github.com/stuartsierra/component, in 
>> that it explicitly pays attention to things like logging configuration and 
>> JBoss support.
>>
>> Brendan Younger
>>
>

-- 
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: Helping newcomers get involved in Clojure projects

[Marcus Blankenship]

Leif, this is really cool.  Thanks for taking the time to find this.  I wish 
there were wiki page where we could put this for safe keeping, so future n00bs 
could find it.  Or, maybe you could release the script you used to create this, 
which of course would be in Clojure as well... ;-)


On Apr 14, 2014, at 6:51 AM, Leif  wrote:

> Below is a list of the top 1,000 clojure projects (by star count) from github 
> with issues with labels that sound somewhat appropriate for newcomers.  Don't 
> worry, the final list is way less than 1,000.
> 
> Considering the list, we see that:
> The community may want to attempt to standardize these labels.
> Most of the 1,000 projects had no such labels (or no issues at all).  I 
> pessimistically take that to mean that there are lots of issues yet to be 
> found, and a newbie should just find a project in an area they know a lot 
> about, or are interested in, and stress test it.
> Some tags may need to be taken with a grain of salt.  E.g. an Om issue tagged 
> as "trivial" may or may not be so to, say, a newbie to clojure who is not a 
> professional UI developer.
> Everyone wants docs.  This may interest you less than programming, but trust 
> me, you'll have to do some programming with a library before you can write 
> sensible docs for it.  Also, you may in the process be able to influence the 
> API / usability of a library.
> (["https://github.com/LightTable/LightTable"; #{"starter"}]
>  ["https://github.com/technomancy/leiningen"; #{"usability" "docs" "Newbie"}]
>  ["https://github.com/weavejester/compojure"; #{"easy" "trivial"}]
>  ["https://github.com/swannodette/om"; #{"trivial" "example" "minor"}]
>  ["https://github.com/overtone/overtone"; #{"newbie"}]
>  ["https://github.com/nathanmarz/cascalog"; #{"newbies"}]
>  ["https://github.com/marick/Midje"; #{"cleanup" "ripe-for-new-contributor" 
> "better-error-msgs" "documentation"}]
>  ["https://github.com/cemerick/friend"; #{"doc"}]
>  ["https://github.com/pallet/pallet"; #{"Documentation" "Newbie"}]
>  ["https://github.com/brentonashworth/one"; #{"sample application"}]
>  ["https://github.com/clojure-liberator/liberator"; #{"documentation"}]
>  ["https://github.com/emezeske/lein-cljsbuild"; #{"Documentation"}]
>  ["https://github.com/relevance/labrepl"; #{"documentation"}]
>  ["https://github.com/gdeer81/marginalia"; #{"cleanup" "docs"}]
>  ["https://github.com/semperos/clj-webdriver"; #{"documentation"}]
>  ["https://github.com/michaelklishin/monger"; #{"documentation"}]
>  ["https://github.com/xsc/lein-ancient"; #{"better error message"}]
>  ["https://github.com/neotyk/http.async.client"; #{"Docs"}]
>  ["https://github.com/ato/clojars-web"; #{"cleanup"}]
>  ["https://github.com/clojurewerkz/elastisch"; #{"low-hanging fruit" 
> "usability" "documentation"}]
>  ["https://github.com/michaelklishin/langohr"; #{"documentation"}]
>  ["https://github.com/michaelklishin/validateur"; #{"documentation"}]
>  ["https://github.com/cemerick/clojurescript.test"; #{"documentation"}]
>  ["https://github.com/sonian/carica"; #{"documentation"}]
>  ["https://github.com/michaelklishin/neocons"; #{"usability" "documentation"}]
>  ["https://github.com/michaelklishin/quartzite"; #{"documentation"}]
>  ["https://github.com/cfpb/qu"; #{"docs"}]
>  ["https://github.com/michaelklishin/welle"; #{"documentation"}]
>  ["https://github.com/abedra/accession"; #{"Documentation"}]
>  ["https://github.com/Raynes/irclj"; #{"documentation"}]
>  ["https://github.com/aaronfeng/trixx"; #{"bitesize"}]
>  ["https://github.com/gameclosure/hermes"; #{"documentation"}]
>  ["https://github.com/wri/forma-clj"; #{"cleanup"}]
>  ["https://github.com/cgmartin/clj-wamp"; #{"docs"}])
> 
> --Leif
> 
> On Saturday, January 25, 2014 1:54:10 PM UTC-5, Bridget wrote:
> OpenHatch has this great initiative for encouraging newcomers to get involved 
> with open source projects. You tag some issues in your bug tracker as 
> "newcomer" or "easy". This provides a gentle path into contributing. There is 
> some work involved with this. You have to do the tagging, and there needs to 
> be some capacity in your project for some mentoring.
> 
> Leiningen is doing this already with "newbie" tagged issues, which is awesome.
> 
> Are there any other Clojure projects that are doing this? Would you like to 
> do this with your project? If so, I can try to help. I have been spending a 
> lot of time thinking about the Clojure newcomer perspective lately, and I'd 
> like to work on some things that help smooth that path.
> 
> Bridget
> 
> -- 
> 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

Re: auto include a certain line in all *.cljs files

[Tim Visher]

Hi t,

On Sun, Apr 13, 2014 at 3:18 PM, t x  wrote:
> What does 
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L209-L211
> mean ?
>
> In particular, I'm confused about:
>
>>> Forms to prepend to every form that is evaluated inside your project.
>
> I only want to insert it right into the (ns ...) clause.
>
> Thanks!

The ns macro is only one way to require a namespace.

The way :injections works (at least the way it appears to work, I've
never personally used it) is by allowing you to use the alternate
means of requiring another namespace which is programmatically.

In other words you can have a `(:require …)` section in your `ns`
macro, or you could simply have a regular `(require '…)` form in your
source.

So the real question becomes if there is a programmatic call you can
make to `(require-macros …)`, which from brief googling appears not to
be the case.

If the answer to that is no then I would say to look into the
templating features of your editor to facilitate easily adding it in.

As a stylistic note, the more magical you make your source files, the
harder they are to understand going forward. People are used to seeing
all the symbols they might encounter in the source file listed in the
`ns` macro. Violating that might be expedient, but it's probably not
good style. In this instance, I'd swallow the repetition for the sake
of clarity.

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

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

Linked Hash Map/Set

[Frankie Sardo]

I'm on a mission to implement an ordered map and set structure for Clojure. 
Much like LinkedHashMap for Java but as a persistent data structure.
The idea is that instead of saving a simple [k v] MapEntry we can save [k v 
left-node-key right-node-key] plus a global head-node-key to walk through 
the chains of nodes.
Adding a new element creates a new node with a reference on the current 
tail and the head node and updates the tail and head node to reference the 
new key in the middle.
Removing an element dissociates the selected node and associates the newly 
updated nodes at the left and the right of the removed one.

What puzzles me is the overall performance of this data structure. While 
Big-O complexity is the same I knew it would be slower due to extra 
accesses to the inner map, but I expected to be close  to the performance 
of a normal hash-map. Instead insertion is about 5x slower while the 
removal is 2x slower. So I wonder: is assoc-ing multiple keys at a time 
generating multiple persistent maps? Or am I doing something blatantly 
wrong here?

However, if somebody'd like to have a look at it I pushed an initial 
version here https://github.com/frankiesardo/linked. Any help is much 
appreciated as I'm still a Clojure newbie.

-- 
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: Linked Hash Map/Set

[Andy Fingerhut]

I don't have time right now to look at the details of your implementation,
but can answer at least one of your questions.

Clojure's normal PersistentHashMap data structure does create a new object
for every key you remove (with dissoc), add, or modify the value for (with
assoc).  So if a single assoc call is made that adds/changes the values for
5 keys, 5 new PersistentHashMap objects will be created.

That can be avoided if you call transient first, then assoc! N times (each
time on the result returned by the previous assoc!), then persistent.
There the assoc! calls still can create new objects, but they will often
simply edit the existing transient data structure in place.  These are a
bit trickier to implement, so if I were you I would focus on getting the
persistent version correct and as fast as you can before worrying about a
transient version.  Either that, or do not even both creating a transient
version at all.

Andy


On Mon, Apr 14, 2014 at 11:59 AM, Frankie Sardo wrote:

> I'm on a mission to implement an ordered map and set structure for
> Clojure. Much like LinkedHashMap for Java but as a persistent data
> structure.
> The idea is that instead of saving a simple [k v] MapEntry we can save [k
> v left-node-key right-node-key] plus a global head-node-key to walk through
> the chains of nodes.
> Adding a new element creates a new node with a reference on the current
> tail and the head node and updates the tail and head node to reference the
> new key in the middle.
> Removing an element dissociates the selected node and associates the newly
> updated nodes at the left and the right of the removed one.
>
> What puzzles me is the overall performance of this data structure. While
> Big-O complexity is the same I knew it would be slower due to extra
> accesses to the inner map, but I expected to be close  to the performance
> of a normal hash-map. Instead insertion is about 5x slower while the
> removal is 2x slower. So I wonder: is assoc-ing multiple keys at a time
> generating multiple persistent maps? Or am I doing something blatantly
> wrong here?
>
> However, if somebody'd like to have a look at it I pushed an initial
> version here https://github.com/frankiesardo/linked. Any help is much
> appreciated as I'm still a Clojure newbie.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Linked Hash Map/Set

[Andy Fingerhut]

You may also want to take a look at the 'ordered' library, intended to
achieve a similar affect as you describe of remembering elements in the
order they were inserted.  I don't know which of the two Github repos below
is the current latest one, but it should be one of them:

https://github.com/flatland/ordered
https://github.com/amalloy/ordered

Andy


On Mon, Apr 14, 2014 at 12:36 PM, Andy Fingerhut
wrote:

> I don't have time right now to look at the details of your implementation,
> but can answer at least one of your questions.
>
> Clojure's normal PersistentHashMap data structure does create a new object
> for every key you remove (with dissoc), add, or modify the value for (with
> assoc).  So if a single assoc call is made that adds/changes the values for
> 5 keys, 5 new PersistentHashMap objects will be created.
>
> That can be avoided if you call transient first, then assoc! N times (each
> time on the result returned by the previous assoc!), then persistent.
> There the assoc! calls still can create new objects, but they will often
> simply edit the existing transient data structure in place.  These are a
> bit trickier to implement, so if I were you I would focus on getting the
> persistent version correct and as fast as you can before worrying about a
> transient version.  Either that, or do not even both creating a transient
> version at all.
>
> Andy
>
>
> On Mon, Apr 14, 2014 at 11:59 AM, Frankie Sardo wrote:
>
>> I'm on a mission to implement an ordered map and set structure for
>> Clojure. Much like LinkedHashMap for Java but as a persistent data
>> structure.
>> The idea is that instead of saving a simple [k v] MapEntry we can save [k
>> v left-node-key right-node-key] plus a global head-node-key to walk through
>> the chains of nodes.
>> Adding a new element creates a new node with a reference on the current
>> tail and the head node and updates the tail and head node to reference the
>> new key in the middle.
>> Removing an element dissociates the selected node and associates the
>> newly updated nodes at the left and the right of the removed one.
>>
>> What puzzles me is the overall performance of this data structure. While
>> Big-O complexity is the same I knew it would be slower due to extra
>> accesses to the inner map, but I expected to be close  to the performance
>> of a normal hash-map. Instead insertion is about 5x slower while the
>> removal is 2x slower. So I wonder: is assoc-ing multiple keys at a time
>> generating multiple persistent maps? Or am I doing something blatantly
>> wrong here?
>>
>> However, if somebody'd like to have a look at it I pushed an initial
>> version here https://github.com/frankiesardo/linked. Any help is much
>> appreciated as I'm still a Clojure newbie.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[ANN] brute 0.1.1 - A lightweight Entity Component System library for writing games

[Mark Mandel]

Heya!

First real Clojure library release, so exciting/scary stuff, but feedback
would very much be appreciated.

Brute is a a simple and lightweight Entity Component System library for
writing games with Clojure.

The aim of this project was to use basic Clojure building blocks to form an
Entity System architecture, and get out of the author's way when deciding
exactly what approach would best fit their game when integrating with this
library.

To that end:

   - Entities are UUIDs.
   - The Component type system can be easily extended through a multimethod
   get-component-type, but defaults to using the component's instance class as
   its type.
   - Components can therefore be defrecords or deftypes by default, but
   could easily be maps or just about anything else.
   - Systems are simply references to functions of the format (fn [delta]).

Project can be found on Github at:
https://github.com/markmandel/brute

Sample Pong Game can be found on Github as well:
https://github.com/markmandel/brute-play-pong

Blog post on the initial release:
http://www.compoundtheory.com/brute-entity-component-system-library-for-clojure/


-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

Re: Helping newcomers get involved in Clojure projects

[Bridget]

Wow, Leif. This is great. Thanks so much for doing this. 

For #1 - Proposing a label for issues appropriate to newcomers seems like 
something very doable to get this kickstarted. I propose "bite-sized," to 
keep in line with what OpenHatch does. 
Does anyone have other suggestions?

#3 I saw as an issue, also. The tag could be meaningless if there is huge 
variance. Maybe publish some sort of definition?

Working on this is on my active Todo list, but other things have taken 
precedence (called ClojureBridge :). I should have some more time in a 
couple of weeks. Anyone available to team up?  I think Marcus' suggestion 
to put up a web page/wiki to start the ball rolling would be great.

Bridget

On Monday, April 14, 2014 9:51:36 AM UTC-4, Leif wrote:
>
> Below is a list of the top 1,000 clojure projects (by star count) from 
> github with issues with labels that sound somewhat appropriate for 
> newcomers.  Don't worry, the final list is way less than 1,000.
>
> Considering the list, we see that:
>
>1. The community may want to attempt to standardize these labels.
>2. Most of the 1,000 projects had no such labels (or no issues at 
>all).  I pessimistically take that to mean that there are lots of issues 
>yet to be found, and a newbie should just find a project in an area they 
>know a lot about, or are interested in, and stress test it.
>3. Some tags may need to be taken with a grain of salt.  E.g. an Om 
>issue tagged as "trivial" may or may not be so to, say, a newbie to 
> clojure 
>who is not a professional UI developer.
>4. Everyone wants docs.  This may interest you less than programming, 
>but trust me, you'll have to do some programming with a library before you 
>can write sensible docs for it.  Also, you may in the process be able to 
>influence the API / usability of a library.
>
> (["https://github.com/LightTable/LightTable"; #{"starter"}]
>  ["https://github.com/technomancy/leiningen"; #{"usability" "docs" 
> "Newbie"}]
>  ["https://github.com/weavejester/compojure"; #{"easy" "trivial"}]
>  ["https://github.com/swannodette/om"; #{"trivial" "example" "minor"}]
>  ["https://github.com/overtone/overtone"; #{"newbie"}]
>  ["https://github.com/nathanmarz/cascalog"; #{"newbies"}]
>  ["https://github.com/marick/Midje"; #{"cleanup" 
> "ripe-for-new-contributor" "better-error-msgs" "documentation"}]
>  ["https://github.com/cemerick/friend"; #{"doc"}]
>  ["https://github.com/pallet/pallet"; #{"Documentation" "Newbie"}]
>  ["https://github.com/brentonashworth/one"; #{"sample application"}]
>  ["https://github.com/clojure-liberator/liberator"; #{"documentation"}]
>  ["https://github.com/emezeske/lein-cljsbuild"; #{"Documentation"}]
>  ["https://github.com/relevance/labrepl"; #{"documentation"}]
>  ["https://github.com/gdeer81/marginalia"; #{"cleanup" "docs"}]
>  ["https://github.com/semperos/clj-webdriver"; #{"documentation"}]
>  ["https://github.com/michaelklishin/monger"; #{"documentation"}]
>  ["https://github.com/xsc/lein-ancient"; #{"better error message"}]
>  ["https://github.com/neotyk/http.async.client"; #{"Docs"}]
>  ["https://github.com/ato/clojars-web"; #{"cleanup"}]
>  ["https://github.com/clojurewerkz/elastisch"; #{"low-hanging fruit" 
> "usability" "documentation"}]
>  ["https://github.com/michaelklishin/langohr"; #{"documentation"}]
>  ["https://github.com/michaelklishin/validateur"; #{"documentation"}]
>  ["https://github.com/cemerick/clojurescript.test"; #{"documentation"}]
>  ["https://github.com/sonian/carica"; #{"documentation"}]
>  ["https://github.com/michaelklishin/neocons"; #{"usability" 
> "documentation"}]
>  ["https://github.com/michaelklishin/quartzite"; #{"documentation"}]
>  ["https://github.com/cfpb/qu"; #{"docs"}]
>  ["https://github.com/michaelklishin/welle"; #{"documentation"}]
>  ["https://github.com/abedra/accession"; #{"Documentation"}]
>  ["https://github.com/Raynes/irclj"; #{"documentation"}]
>  ["https://github.com/aaronfeng/trixx"; #{"bitesize"}]
>  ["https://github.com/gameclosure/hermes"; #{"documentation"}]
>  ["https://github.com/wri/forma-clj"; #{"cleanup"}]
>  ["https://github.com/cgmartin/clj-wamp"; #{"docs"}])
>
> --Leif
>
> On Saturday, January 25, 2014 1:54:10 PM UTC-5, Bridget wrote:
>>
>> OpenHatch has this great 
>> initiativefor encouraging newcomers 
>> to get involved with open source projects. You 
>> tag some issues in your bug tracker as "newcomer" or "easy". This provides 
>> a gentle path into contributing. There is some work involved with this. You 
>> have to do the tagging, and there needs to be some capacity in your project 
>> for some mentoring.
>>
>> Leiningen is doing this  already with "newbie" 
>> tagged issues, which is awesome.
>>
>> Are there any other Clojure projects that are doing this? Would you like 
>> to do this with your project? If so, I can try to help. I have bee

Re: [ANN] brute 0.1.1 - A lightweight Entity Component System library for writing games

[Reid McKenzie]

Cool project! I just hammered out my own CES in the last few weeks for a 
private project, I'll be interested to see how they compare and whether 
there's anything I can add :D

Reid

On Monday, April 14, 2014 6:32:06 PM UTC-5, Mark Mandel wrote:
>
> Heya!
>
> First real Clojure library release, so exciting/scary stuff, but feedback 
> would very much be appreciated.
>
> Brute is a a simple and lightweight Entity Component System library for 
> writing games with Clojure.
>
> The aim of this project was to use basic Clojure building blocks to form 
> an Entity System architecture, and get out of the author's way when 
> deciding exactly what approach would best fit their game when integrating 
> with this library.
>
> To that end:
>
>- Entities are UUIDs.
>- The Component type system can be easily extended through a 
>multimethod get-component-type, but defaults to using the component's 
>instance class as its type.
>- Components can therefore be defrecords or deftypes by default, but 
>could easily be maps or just about anything else.
>- Systems are simply references to functions of the format (fn 
>[delta]).
>
> Project can be found on Github at:
> https://github.com/markmandel/brute
>
> Sample Pong Game can be found on Github as well:
> https://github.com/markmandel/brute-play-pong
>
> Blog post on the initial release:
>
> http://www.compoundtheory.com/brute-entity-component-system-library-for-clojure/
>
>
> -- 
> E: mark@gmail.com 
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>  

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

Re: [ANN] brute 0.1.1 - A lightweight Entity Component System library for writing games

[Mark Mandel]

Great! Would love to have contributions!

Mark

On Tue, Apr 15, 2014 at 9:45 AM, Reid McKenzie wrote:

> Cool project! I just hammered out my own CES in the last few weeks for a
> private project, I'll be interested to see how they compare and whether
> there's anything I can add :D
>
> Reid
>




-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

Extending a data model

[Andrew Chambers]

Hi everyone, 

I'm new to clojure and in order to learn I'm working on making some 
compiler tools which converts a lightweight IR code into assembly.

My data model for an IR function is along the lines of
(def code
{
:entry
[[:loadaddr :x "global_label"]
 [:loadconst 1 :y]
 [:add :x :y :z] 
 [:jmp :exit]]
:exit
[[:ret :z]]
})

This, when translated to assembly and after register allocation would turn 
into something like (ignoring calling conventions etc):
(def assembly-code
{
:entry
[[:x86.lea :eax "global_label"]
 [:x86.loadimm 1, :eax]
 [:x86.add32 :ebx :eax] 
 [:jmp :exit]]
:exit
[[:ret]]
})

The problem arises when I have to query the IR code for things like 
accesses-memory? or get-output-vars in an
extensible way so that multiple target architectures can be supported.
e.g.  (get-output-vars [:add :a :b :c]) -> :c
(get-output-vars [:x86.add :a :b]) -> :b ;; the input and output 
positions are opcode specific
(get-output-vars [:x86.add :a :b]) -> :b
(get-output-vars [:divmod :a :b :c :d]) -> :c :d
(accesses-memory? :x86.add) -> false
(accesses-memory? :x86.load) -> true
(accesses-memory? :loadconst) ->false
I have to be able to write these functions in a way that knows about the 
format of the basic IR opcodes, but can also be extended
to handle opcodes of architectures that don't exist in my code yet, the 
extensions would exist within the namespaces of that specific architecture 
and shouldn't need to modify the code for the built in opcodes.

What is the most seamless and efficient way to achieve this sort of 
function extension in clojure? Also, how would I allow sharing
of implementations where instructions have similar layouts.

e.g.
(get-output-vars [:add :a :b :c]) -> :c
(get-output-vars [:sub :a :b :c]) -> :c



-- 
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: Extending a data model

[Reid McKenzie]

Hey Andrew, I actually built something very much along these lines a few 
months ago if you care to cheat off of it:

http://github.com/arrdem/toothpick is an assembler generator system that 
works more or less along these lines. Label support is still a problem I 
haven't completely solved and I never did build a compiler backed targeting 
Toothpick, but the idea is there.

One approach, and the one that I took, is to make everything in your API 
parametric on some representation of the target architecture. In Toothpick, 
I build a monolithic map representing the target, and all the utility 
functions are built in terms of operating on an arbitrary instruction 
sequence in conjunction with this target description. This is probably the 
easiest thing to do, as in your (accesses-memory?) you can simply enquire 
of the target description structure rather than relying on the user to have 
provided a multimethod implementation or anything else.

Hope this helps,
Reid

On Monday, April 14, 2014 6:52:36 PM UTC-5, Andrew Chambers wrote:
>
> Hi everyone, 
>
> I'm new to clojure and in order to learn I'm working on making some 
> compiler tools which converts a lightweight IR code into assembly.
>
> My data model for an IR function is along the lines of
> (def code
> {
> :entry
> [[:loadaddr :x "global_label"]
>  [:loadconst 1 :y]
>  [:add :x :y :z] 
>  [:jmp :exit]]
> :exit
> [[:ret :z]]
> })
>
> This, when translated to assembly and after register allocation would turn 
> into something like (ignoring calling conventions etc):
> (def assembly-code
> {
> :entry
> [[:x86.lea :eax "global_label"]
>  [:x86.loadimm 1, :eax]
>  [:x86.add32 :ebx :eax] 
>  [:jmp :exit]]
> :exit
> [[:ret]]
> })
>
> The problem arises when I have to query the IR code for things like 
> accesses-memory? or get-output-vars in an
> extensible way so that multiple target architectures can be supported.
> e.g.  (get-output-vars [:add :a :b :c]) -> :c
> (get-output-vars [:x86.add :a :b]) -> :b ;; the input and output 
> positions are opcode specific
> (get-output-vars [:x86.add :a :b]) -> :b
> (get-output-vars [:divmod :a :b :c :d]) -> :c :d
> (accesses-memory? :x86.add) -> false
> (accesses-memory? :x86.load) -> true
> (accesses-memory? :loadconst) ->false
> I have to be able to write these functions in a way that knows about the 
> format of the basic IR opcodes, but can also be extended
> to handle opcodes of architectures that don't exist in my code yet, the 
> extensions would exist within the namespaces of that specific architecture 
> and shouldn't need to modify the code for the built in opcodes.
>
> What is the most seamless and efficient way to achieve this sort of 
> function extension in clojure? Also, how would I allow sharing
> of implementations where instructions have similar layouts.
>
> e.g.
> (get-output-vars [:add :a :b :c]) -> :c
> (get-output-vars [:sub :a :b :c]) -> :c
>
>
>
>

-- 
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: Potential Intro clojure projects - libraries and ideas with wow factor

[Andrew Chambers]

Clojure logic programming with core.logic (something akin to a sudoku 
solver https://gist.github.com/swannodette/3217582 is a good example) or 
using datomic to have a database with a time machine and datalog for 
queries might be cool (perhaps visualizing the data in the database at 
arbitrary times in the past). Both don't really have equivalents in other 
languages. Other things that are hard to achieve in other languages would 
involve the immutable data structures, concurrency, and macros.


On Monday, April 14, 2014 9:15:31 AM UTC+12, utel wrote:
>
> A handful of developers at the organisation I work at, want to encourage 
> interest in Clojure with the aim of using it in production amongst the 
> organisation's wider developer community (hundreds of developers). We 
> ourselves are Clojure hobbyists.
>
> We wanted to do this through a basic project (with few moving parts), so I 
> wanted to get feedback on a couple of aspects:
> 1. Examples of basic project ideas that would be compelling to fellow 
> developers not familiar with Clojure (e.g. something useful that you can do 
> easily with Clojure that's harder to do in more established languages such 
> as Java)
> 2. Particular libraries that again had a wow factor towards an objective 
> not easily achievable in more established languages (perhaps related to 
> data analysis, visualisation, or taking advantage of the benefit of lazy 
> evaluation in a novel way as examples).
>
> I realise these questions are somewhat open-ended, but just wanted to 
> spark off some ideas for us through bouncing these questions off the google 
> group's members.
>
> Thanks for any leads!
>
>

-- 
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: Helping newcomers get involved in Clojure projects

[Marcus Blankenship]

For now we can use a github repo:  
https://github.com/marcuscreo/clojure-learning-resources

Send me a pull request, or let me know if you want access to edit directly.  

I also put Leif's excellent list in the wiki portion of the repo as well.
https://github.com/marcuscreo/clojure-learning-resources/wiki/Clojure-Projects-with-novice-tags




On Apr 14, 2014, at 4:39 PM, Bridget  wrote:

> Wow, Leif. This is great. Thanks so much for doing this. 
> 
> For #1 - Proposing a label for issues appropriate to newcomers seems like 
> something very doable to get this kickstarted. I propose "bite-sized," to 
> keep in line with what OpenHatch does. Does anyone have other suggestions?
> 
> #3 I saw as an issue, also. The tag could be meaningless if there is huge 
> variance. Maybe publish some sort of definition?
> 
> Working on this is on my active Todo list, but other things have taken 
> precedence (called ClojureBridge :). I should have some more time in a couple 
> of weeks. Anyone available to team up?  I think Marcus' suggestion to put up 
> a web page/wiki to start the ball rolling would be great.
> 
> Bridget
> 
> On Monday, April 14, 2014 9:51:36 AM UTC-4, Leif wrote:
> Below is a list of the top 1,000 clojure projects (by star count) from github 
> with issues with labels that sound somewhat appropriate for newcomers.  Don't 
> worry, the final list is way less than 1,000.
> 
> Considering the list, we see that:
> The community may want to attempt to standardize these labels.
> Most of the 1,000 projects had no such labels (or no issues at all).  I 
> pessimistically take that to mean that there are lots of issues yet to be 
> found, and a newbie should just find a project in an area they know a lot 
> about, or are interested in, and stress test it.
> Some tags may need to be taken with a grain of salt.  E.g. an Om issue tagged 
> as "trivial" may or may not be so to, say, a newbie to clojure who is not a 
> professional UI developer.
> Everyone wants docs.  This may interest you less than programming, but trust 
> me, you'll have to do some programming with a library before you can write 
> sensible docs for it.  Also, you may in the process be able to influence the 
> API / usability of a library.
> (["https://github.com/LightTable/LightTable"; #{"starter"}]
>  ["https://github.com/technomancy/leiningen"; #{"usability" "docs" "Newbie"}]
>  ["https://github.com/weavejester/compojure"; #{"easy" "trivial"}]
>  ["https://github.com/swannodette/om"; #{"trivial" "example" "minor"}]
>  ["https://github.com/overtone/overtone"; #{"newbie"}]
>  ["https://github.com/nathanmarz/cascalog"; #{"newbies"}]
>  ["https://github.com/marick/Midje"; #{"cleanup" "ripe-for-new-contributor" 
> "better-error-msgs" "documentation"}]
>  ["https://github.com/cemerick/friend"; #{"doc"}]
>  ["https://github.com/pallet/pallet"; #{"Documentation" "Newbie"}]
>  ["https://github.com/brentonashworth/one"; #{"sample application"}]
>  ["https://github.com/clojure-liberator/liberator"; #{"documentation"}]
>  ["https://github.com/emezeske/lein-cljsbuild"; #{"Documentation"}]
>  ["https://github.com/relevance/labrepl"; #{"documentation"}]
>  ["https://github.com/gdeer81/marginalia"; #{"cleanup" "docs"}]
>  ["https://github.com/semperos/clj-webdriver"; #{"documentation"}]
>  ["https://github.com/michaelklishin/monger"; #{"documentation"}]
>  ["https://github.com/xsc/lein-ancient"; #{"better error message"}]
>  ["https://github.com/neotyk/http.async.client"; #{"Docs"}]
>  ["https://github.com/ato/clojars-web"; #{"cleanup"}]
>  ["https://github.com/clojurewerkz/elastisch"; #{"low-hanging fruit" 
> "usability" "documentation"}]
>  ["https://github.com/michaelklishin/langohr"; #{"documentation"}]
>  ["https://github.com/michaelklishin/validateur"; #{"documentation"}]
>  ["https://github.com/cemerick/clojurescript.test"; #{"documentation"}]
>  ["https://github.com/sonian/carica"; #{"documentation"}]
>  ["https://github.com/michaelklishin/neocons"; #{"usability" "documentation"}]
>  ["https://github.com/michaelklishin/quartzite"; #{"documentation"}]
>  ["https://github.com/cfpb/qu"; #{"docs"}]
>  ["https://github.com/michaelklishin/welle"; #{"documentation"}]
>  ["https://github.com/abedra/accession"; #{"Documentation"}]
>  ["https://github.com/Raynes/irclj"; #{"documentation"}]
>  ["https://github.com/aaronfeng/trixx"; #{"bitesize"}]
>  ["https://github.com/gameclosure/hermes"; #{"documentation"}]
>  ["https://github.com/wri/forma-clj"; #{"cleanup"}]
>  ["https://github.com/cgmartin/clj-wamp"; #{"docs"}])
> 
> --Leif
> 
> On Saturday, January 25, 2014 1:54:10 PM UTC-5, Bridget wrote:
> OpenHatch has this great initiative for encouraging newcomers to get involved 
> with open source projects. You tag some issues in your bug tracker as 
> "newcomer" or "easy". This provides a gentle path into contributing. There is 
> some work involved with this. You have to do the tagging, and there needs to 
> be some capacity in your project for some mentorin

Re: Annotations on gen-class :state

[Colin Fleming]

Well, I'm a bit torn on this one. On the one hand, I'd love to have
something that meets my particular use case (of course!) which I wrote
about here: https://groups.google.com/d/topic/clojure/MznBwxZt4cY/discussion.
I think that case can be met while still keeping the API fairly simple. But
once you start down the path of being able to do everything that you can in
Java (multiple constructors, classes or members with non-standard
visibility, annotations etc) the API becomes much more complicated, and I'm
not sure where the right trade-off is there. My gut feeling is that much
more than an extend-type as discussed in that thread should probably be
done in Java, but again, maybe I just want what I personally need!


On 15 April 2014 02:31, Jon Seltzer  wrote:

> This is unfortunate.  I certainly can write a Java class and I expected
> that would be the answer.  The question for me is whether, as a group, we
> see any value in having a consistent interface with the JVM.  One could
> argue that Clojure does not need any of the interop features it already
> has.  In fact, one might argue that all interop should occur by invoking
> pure Clojure from Java only but I hope most of us would agree that would
> not a very satisfying outcome.  The Clojure in Clojure work being done
> gives me hope this is going to change.  A Clojure compiler written in
> Clojure would almost certainly need to be full (or more fully) featured.
>
> I like Stuart Sierra's quote (Twitter):  "Using Java libraries is
> idiomatic Clojure", and this is true for a lot of us using Clojure.
>
> jbs
>
>
> On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote:
>
>> gen-class really isn't suitable for doing complicated interop like
>> annotating fields. It's heavily oriented towards a single means of managing
>> state, which is a single field generally containing an atom, which in turn
>> contains your actual state in a map or similar. If you really need multiple
>> fields you can use deftype/defrecord, but they come with different
>> restrictions - no inheritance, don't require their namespace on class init
>> which is required for many use cases where you might want field
>> annotations. I'm also not sure if their fields can be annotated.
>>
>> In general when you start needing that level of interop, the easiest
>> thing is just to write a Java class and call into Clojure from there as
>> required.
>>
>>
>> On 14 April 2014 14:28, Jon Seltzer  wrote:
>>
>>>  There are many Java APIs that expect client APIs to annotate fields
>>> but Clojure does not support annotations on fields.  Is there any plan to
>>> add support?
>>>
>>> And one tangential question:  Is there any consideration of adding
>>> gen-class support for multiple fields instead of just one?
>>>
>>> jbs
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Extending a data model

[Andrew Chambers]

Thanks for the tip, I think multimethods may be what i need in this case 
(perhaps which checks the current architecture in the dispatch function so 
i can disable some). I want to avoid having to pass an object around and 
extract methods (simply because it clutters my code). Dynamically binding 
methods may be another solution.

On Tuesday, April 15, 2014 11:59:17 AM UTC+12, Reid McKenzie wrote:
>
> Hey Andrew, I actually built something very much along these lines a few 
> months ago if you care to cheat off of it:
>
> http://github.com/arrdem/toothpick is an assembler generator system that 
> works more or less along these lines. Label support is still a problem I 
> haven't completely solved and I never did build a compiler backed targeting 
> Toothpick, but the idea is there.
>
> One approach, and the one that I took, is to make everything in your API 
> parametric on some representation of the target architecture. In Toothpick, 
> I build a monolithic map representing the target, and all the utility 
> functions are built in terms of operating on an arbitrary instruction 
> sequence in conjunction with this target description. This is probably the 
> easiest thing to do, as in your (accesses-memory?) you can simply enquire 
> of the target description structure rather than relying on the user to have 
> provided a multimethod implementation or anything else.
>
> Hope this helps,
> Reid
>
> On Monday, April 14, 2014 6:52:36 PM UTC-5, Andrew Chambers wrote:
>>
>> Hi everyone, 
>>
>> I'm new to clojure and in order to learn I'm working on making some 
>> compiler tools which converts a lightweight IR code into assembly.
>>
>> My data model for an IR function is along the lines of
>> (def code
>> {
>> :entry
>> [[:loadaddr :x "global_label"]
>>  [:loadconst 1 :y]
>>  [:add :x :y :z] 
>>  [:jmp :exit]]
>> :exit
>> [[:ret :z]]
>> })
>>
>> This, when translated to assembly and after register allocation would 
>> turn into something like (ignoring calling conventions etc):
>> (def assembly-code
>> {
>> :entry
>> [[:x86.lea :eax "global_label"]
>>  [:x86.loadimm 1, :eax]
>>  [:x86.add32 :ebx :eax] 
>>  [:jmp :exit]]
>> :exit
>> [[:ret]]
>> })
>>
>> The problem arises when I have to query the IR code for things like 
>> accesses-memory? or get-output-vars in an
>> extensible way so that multiple target architectures can be supported.
>> e.g.  (get-output-vars [:add :a :b :c]) -> :c
>> (get-output-vars [:x86.add :a :b]) -> :b ;; the input and output 
>> positions are opcode specific
>> (get-output-vars [:x86.add :a :b]) -> :b
>> (get-output-vars [:divmod :a :b :c :d]) -> :c :d
>> (accesses-memory? :x86.add) -> false
>> (accesses-memory? :x86.load) -> true
>> (accesses-memory? :loadconst) ->false
>> I have to be able to write these functions in a way that knows about the 
>> format of the basic IR opcodes, but can also be extended
>> to handle opcodes of architectures that don't exist in my code yet, the 
>> extensions would exist within the namespaces of that specific architecture 
>> and shouldn't need to modify the code for the built in opcodes.
>>
>> What is the most seamless and efficient way to achieve this sort of 
>> function extension in clojure? Also, how would I allow sharing
>> of implementations where instructions have similar layouts.
>>
>> e.g.
>> (get-output-vars [:add :a :b :c]) -> :c
>> (get-output-vars [:sub :a :b :c]) -> :c
>>
>>
>>
>>

-- 
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: Extending a data model

[Andrew Chambers]

An update, I read about protocols and multimethods. I think multimethods 
are a decent way to go (cant use protocols without a defrecord) provided 
they work across namespaces. 

On Tuesday, April 15, 2014 11:52:36 AM UTC+12, Andrew Chambers wrote:
>
> Hi everyone, 
>
> I'm new to clojure and in order to learn I'm working on making some 
> compiler tools which converts a lightweight IR code into assembly.
>
> My data model for an IR function is along the lines of
> (def code
> {
> :entry
> [[:loadaddr :x "global_label"]
>  [:loadconst 1 :y]
>  [:add :x :y :z] 
>  [:jmp :exit]]
> :exit
> [[:ret :z]]
> })
>
> This, when translated to assembly and after register allocation would turn 
> into something like (ignoring calling conventions etc):
> (def assembly-code
> {
> :entry
> [[:x86.lea :eax "global_label"]
>  [:x86.loadimm 1, :eax]
>  [:x86.add32 :ebx :eax] 
>  [:jmp :exit]]
> :exit
> [[:ret]]
> })
>
> The problem arises when I have to query the IR code for things like 
> accesses-memory? or get-output-vars in an
> extensible way so that multiple target architectures can be supported.
> e.g.  (get-output-vars [:add :a :b :c]) -> :c
> (get-output-vars [:x86.add :a :b]) -> :b ;; the input and output 
> positions are opcode specific
> (get-output-vars [:x86.add :a :b]) -> :b
> (get-output-vars [:divmod :a :b :c :d]) -> :c :d
> (accesses-memory? :x86.add) -> false
> (accesses-memory? :x86.load) -> true
> (accesses-memory? :loadconst) ->false
> I have to be able to write these functions in a way that knows about the 
> format of the basic IR opcodes, but can also be extended
> to handle opcodes of architectures that don't exist in my code yet, the 
> extensions would exist within the namespaces of that specific architecture 
> and shouldn't need to modify the code for the built in opcodes.
>
> What is the most seamless and efficient way to achieve this sort of 
> function extension in clojure? Also, how would I allow sharing
> of implementations where instructions have similar layouts.
>
> e.g.
> (get-output-vars [:add :a :b :c]) -> :c
> (get-output-vars [:sub :a :b :c]) -> :c
>
>
>
>

-- 
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] Gorilla REPL 0.2.0 - all new extensible renderer

[SteveSuehs]

Pretty neat!  I'm playing with it now at the Austin Clojure meetup.

I had to add tools.nrepl to the project dependencies or it couldn't find an 
nrepl server class.

On Wednesday, March 19, 2014 3:22:57 PM UTC-5, Jony Hudson wrote:
>
> Hi all,
>
>  I'm happy to announce a new release of Gorilla REPL. The number one 
> comment I got from people on the original release was that it looked good, 
> but they'd like to see it extended to some library or other. Jeff Rose hit 
> the nail on the head with:
>
> "Being able to render values of different types is important, and I think 
> it deserves a lot of attention in both the design and documentation."
>
> So with that in mind, on to the changes:
>
> - All new renderer. This is the main change. The new renderer is simple 
> and predictable, _very_ flexible, supports first-class pluggable custom 
> rendering, and really respects the structure of Clojure values. In 
> particular it renders aggregates of values as you might hope, so you can 
> draw lists of tables, tables of plots, associatives of tables of tables of 
> plots etc. I've made a couple of videos walking through its features, and 
> how easy it is to extend. I'm really pleased with how it's come out :-)
>
> https://vimeo.com/89529751
> https://vimeo.com/89532785
>
> As per the request, there's also documentation on it. Enough to choke a 
> horse!
>
> http://gorilla-repl.org/renderer.html
>
> - You can open multiple tabs on the same REPL. This works really nicely - 
> they each get they own session, but share the REPL.
>
> - Runs a real nREPL server now, so should work together with things like 
> vim-fireplace that make their own connection to the REPL server. (I haven't 
> tested this though!)
>
> - As you might have guessed from the above, there's now a website. 
> http://gorilla-repl.org 
>
> - Numerous small bug-fixes and feature requests.
>
> There are some minor breaking changes, hence the version bump:
>
> - Old worksheets will need to be re-run to regenerate their output.
>
> - Code that dabbled with the internals of gorilla-plot might need to be 
> adjusted.
>
> It's on clojars now, with coordinates [gorilla-repl "0.2.0"] .
>
> The new renderer lays the foundation for adding rendering for other 
> libraries. I'd love to see support for core.matrix and Incanter, so I think 
> this will be the immediate focus of development. If you maintain a library 
> and would like to see it supported, then please do get in touch.
>
> As always, all comments and criticism gratefully received.
>
> [Proof-reading this email, I realise I sound rather pleased with myself. 
> My apologies for that, but in truth I think I _am_ rather pleased with how 
> this version has came together!]
>
> Yours,
>
>
> Jony
>
>

-- 
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: Annotations on gen-class :state

[Alex Miller]

It is a non-goal for gen-class (and reify, proxy, etc)to support the 
construction of any possible Java class or to fully support every possible 
Java feature. That said, particular extensions to existing features might 
be useful in reasonable use cases.


On Monday, April 14, 2014 7:56:21 PM UTC-5, Colin Fleming wrote:
>
> Well, I'm a bit torn on this one. On the one hand, I'd love to have 
> something that meets my particular use case (of course!) which I wrote 
> about here: 
> https://groups.google.com/d/topic/clojure/MznBwxZt4cY/discussion. I think 
> that case can be met while still keeping the API fairly simple. But once 
> you start down the path of being able to do everything that you can in Java 
> (multiple constructors, classes or members with non-standard visibility, 
> annotations etc) the API becomes much more complicated, and I'm not sure 
> where the right trade-off is there. My gut feeling is that much more than 
> an extend-type as discussed in that thread should probably be done in Java, 
> but again, maybe I just want what I personally need!
>
>
> On 15 April 2014 02:31, Jon Seltzer >wrote:
>
>> This is unfortunate.  I certainly can write a Java class and I expected 
>> that would be the answer.  The question for me is whether, as a group, we 
>> see any value in having a consistent interface with the JVM.  One could 
>> argue that Clojure does not need any of the interop features it already 
>> has.  In fact, one might argue that all interop should occur by invoking 
>> pure Clojure from Java only but I hope most of us would agree that would 
>> not a very satisfying outcome.  The Clojure in Clojure work being done 
>> gives me hope this is going to change.  A Clojure compiler written in 
>> Clojure would almost certainly need to be full (or more fully) featured.
>>
>> I like Stuart Sierra's quote (Twitter):  "Using Java libraries is 
>> idiomatic Clojure", and this is true for a lot of us using Clojure.
>>
>> jbs
>>
>>
>> On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote:
>>
>>> gen-class really isn't suitable for doing complicated interop like 
>>> annotating fields. It's heavily oriented towards a single means of managing 
>>> state, which is a single field generally containing an atom, which in turn 
>>> contains your actual state in a map or similar. If you really need multiple 
>>> fields you can use deftype/defrecord, but they come with different 
>>> restrictions - no inheritance, don't require their namespace on class init 
>>> which is required for many use cases where you might want field 
>>> annotations. I'm also not sure if their fields can be annotated. 
>>>
>>> In general when you start needing that level of interop, the easiest 
>>> thing is just to write a Java class and call into Clojure from there as 
>>> required.
>>>
>>>
>>> On 14 April 2014 14:28, Jon Seltzer  wrote:
>>>
  There are many Java APIs that expect client APIs to annotate fields 
 but Clojure does not support annotations on fields.  Is there any plan to 
 add support?

 And one tangential question:  Is there any consideration of adding 
 gen-class support for multiple fields instead of just one?

 jbs

 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe fro

Re: Annotations on gen-class :state

[Colin Fleming]

Alex, what's your feeling about how a reify-like form and a deftype-like
form that supported concrete class extension (as detailed in the other
thread) would be received? If you think there might be interest I can start
a proposal and possibly write the patch as well.


On 15 April 2014 14:32, Alex Miller  wrote:

> It is a non-goal for gen-class (and reify, proxy, etc)to support the
> construction of any possible Java class or to fully support every possible
> Java feature. That said, particular extensions to existing features might
> be useful in reasonable use cases.
>
>
> On Monday, April 14, 2014 7:56:21 PM UTC-5, Colin Fleming wrote:
>
>> Well, I'm a bit torn on this one. On the one hand, I'd love to have
>> something that meets my particular use case (of course!) which I wrote
>> about here: https://groups.google.com/d/topic/clojure/MznBwxZt4cY/
>> discussion. I think that case can be met while still keeping the API
>> fairly simple. But once you start down the path of being able to do
>> everything that you can in Java (multiple constructors, classes or members
>> with non-standard visibility, annotations etc) the API becomes much more
>> complicated, and I'm not sure where the right trade-off is there. My gut
>> feeling is that much more than an extend-type as discussed in that thread
>> should probably be done in Java, but again, maybe I just want what I
>> personally need!
>>
>>
>> On 15 April 2014 02:31, Jon Seltzer  wrote:
>>
>>> This is unfortunate.  I certainly can write a Java class and I expected
>>> that would be the answer.  The question for me is whether, as a group, we
>>> see any value in having a consistent interface with the JVM.  One could
>>> argue that Clojure does not need any of the interop features it already
>>> has.  In fact, one might argue that all interop should occur by invoking
>>> pure Clojure from Java only but I hope most of us would agree that would
>>> not a very satisfying outcome.  The Clojure in Clojure work being done
>>> gives me hope this is going to change.  A Clojure compiler written in
>>> Clojure would almost certainly need to be full (or more fully) featured.
>>>
>>> I like Stuart Sierra's quote (Twitter):  "Using Java libraries is
>>> idiomatic Clojure", and this is true for a lot of us using Clojure.
>>>
>>> jbs
>>>
>>>
>>> On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote:
>>>
 gen-class really isn't suitable for doing complicated interop like
 annotating fields. It's heavily oriented towards a single means of managing
 state, which is a single field generally containing an atom, which in turn
 contains your actual state in a map or similar. If you really need multiple
 fields you can use deftype/defrecord, but they come with different
 restrictions - no inheritance, don't require their namespace on class init
 which is required for many use cases where you might want field
 annotations. I'm also not sure if their fields can be annotated.

 In general when you start needing that level of interop, the easiest
 thing is just to write a Java class and call into Clojure from there as
 required.


 On 14 April 2014 14:28, Jon Seltzer  wrote:

>  There are many Java APIs that expect client APIs to annotate fields
> but Clojure does not support annotations on fields.  Is there any plan to
> add support?
>
> And one tangential question:  Is there any consideration of adding
> gen-class support for multiple fields instead of just one?
>
> jbs
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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 

Re: Puppet Labs and Trapperkeeper

[Mike Haney]

Great timing on the new blog post.  I'm ramping up on my first "real" clojure 
app, and have been planning to use Component for this piece.  I read the first 
blog post yesterday and it sounded interesting, but I've pretty much locked 
down the stack I'm going to use (you can evaluate libraries forever, but at 
some point you just have to stop looking and pick one to go with).

But after reading the new post, I think it's worth taking a look at 
Trapperkeeper.  Even if I don't switch now, if all goes well I would like to 
turn this app into a larger SaS offering, possibly multi-tenant, and I could 
see something like Trapperkeeper helping there.

I get the distinct impression you have some former OSGI users on your team?  
This reminds me a lot of the service registry in OSGI.  And I don't mean that 
as an insult - the service registry was the best part, it was all the other 
crap that made it painful to use (particularly anything from eclipse, which 
ruined OSGI in my opinion, but that's another rant).

Anyway, this looks like something that could be useful in many cases, and thank 
you for open-sourcing it.

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

Clojure compiletime vs runtime

[Andrew Chambers]

Is there an explanation of how clojure deals with scoping and its static 
checking. It seems to be a hybrid of a static language and a dynamic 
language when it comes to compilation. I'll elaborate.

The following code wont compile:
(defn x [] nil)
(defn y[]) ((x))

however this code will compile:

(defn foo[] (defn x[] nil))
(defn y[]) ((x))

but calling y before foo fails with a runtime exception.

Also, the following code:

(println "hello")
(defn -main [args] 
  (println "world"))

prints "hello" at compile time
and also 
"hello
world" at runtime.

My conclusions from this is that the static symbol checker is actually 
fairly stupid and is just there to provide some simple sanity, and that all 
toplevel code in a namespace
is executed at compile time AND at runtime. Is this correct?

-- 
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: Clojure compiletime vs runtime

[Andrew Chambers]

Forgive me, the first example was meant to be 
The following code wont compile:
(defn y[]) ((x))
(defn x [] nil)


On Tuesday, April 15, 2014 4:39:59 PM UTC+12, Andrew Chambers wrote:
>
> Is there an explanation of how clojure deals with scoping and its static 
> checking. It seems to be a hybrid of a static language and a dynamic 
> language when it comes to compilation. I'll elaborate.
>
> The following code wont compile:
> (defn x [] nil)
> (defn y[]) ((x))
>
> however this code will compile:
>
> (defn foo[] (defn x[] nil))
> (defn y[]) ((x))
>
> but calling y before foo fails with a runtime exception.
>
> Also, the following code:
>
> (println "hello")
> (defn -main [args] 
>   (println "world"))
>
> prints "hello" at compile time
> and also 
> "hello
> world" at runtime.
>
> My conclusions from this is that the static symbol checker is actually 
> fairly stupid and is just there to provide some simple sanity, and that all 
> toplevel code in a namespace
> is executed at compile time AND at runtime. Is this correct?
>

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