is there a way I can learn clojure with a lot of exercises

[Roelof Wobben]

Hello, 

I like to try clojure.
I have little or none programming background but I know I learn the best by 
reading a piece of text
and then do exercises about it so I can check if I really understand it.

What is then the best way to proceed ?

Roelof

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

[utel]

Thanks Mikera and Andrew for the ideas. Some interesting suggestions there. 
I'll discuss these with my fellow devs. Much appreciated.


On Tuesday, April 15, 2014 1:14:11 AM UTC+1, Andrew Chambers wrote:
>
> 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: [ANN] Gorilla REPL 0.2.0 - all new extensible renderer

[Andrew Chambers]

Is there a way to rerun the whole notebook top to bottom with a hotkey?


On Wed, Apr 16, 2014 at 3:59 PM, SteveSuehs  wrote:

> I'm running Leiningen 2.1.2 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit
> Server VM
>
> Upgrading now...version 2.3.4
> Removed tools.nrepl from project.clj
> $ lein gorilla
> Gorilla-REPL.
> Started nREPL server on port 50235
> Running at http://localhost:8990/worksheet.html .
> Ctrl+C to exit.
>
> Looking good!
>
> On Tuesday, April 15, 2014 10:03:33 AM UTC-5, Jony Hudson wrote:
>>
>> Thanks for the kind words chaps - glad you like it!
>>
>> @Steve Are you sure your Leiningen is up to date? I've only seen this
>> problem when accidentally trying to run Gorilla with Lein 1.7 (as Debian
>> seems to have that version as its default install).
>>
>> @Andrew Probably not what you're looking for, but there should be a
>> renderer for Loom graphs soon, which shells out to GraphViz to do the heavy
>> lifting. Take a look at this PR: https://github.com/aysylu/loom/pull/20. 
>> Even if your data doesn't fit with loom then it might be useful for an
>> idea.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/a1FsteQXhrQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Gorilla REPL 0.2.0 - all new extensible renderer

[SteveSuehs]

I'm running Leiningen 2.1.2 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server 
VM

Upgrading now...version 2.3.4
Removed tools.nrepl from project.clj
$ lein gorilla
Gorilla-REPL.
Started nREPL server on port 50235
Running at http://localhost:8990/worksheet.html .
Ctrl+C to exit.

Looking good!

On Tuesday, April 15, 2014 10:03:33 AM UTC-5, Jony Hudson wrote:
>
> Thanks for the kind words chaps - glad you like it!
>
> @Steve Are you sure your Leiningen is up to date? I've only seen this 
> problem when accidentally trying to run Gorilla with Lein 1.7 (as Debian 
> seems to have that version as its default install).
>
> @Andrew Probably not what you're looking for, but there should be a 
> renderer for Loom graphs soon, which shells out to GraphViz to do the heavy 
> lifting. Take a look at this PR: https://github.com/aysylu/loom/pull/20 . 
> Even if your data doesn't fit with loom then it might be useful for an idea.
>

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

multiple browsers, live.js -> repl

[t x]

Hi,

  Okay. I think I have finally reached the limits of live.js, and now
want an interactive browser repl + being able to push portions of code
(rather than reloading the entire page).

  I have a simple question though:

  * I'm developing a _distribued_ app

  * So I can't test it unless I have 2+ browsers running.

  * With brepl, when I modify my *.cljs files, is it possible to push
the changes to _two_ browsers simultaneojsly?

Thanks!

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

Re: Helping newcomers get involved in Clojure projects

[Colin Fleming]

That's interesting. I think such a database of common errors would be an
extremely useful resource, not only for learning but also for development
of linting tools (I think this is more or less what Dynalint does right
now) and other tools. For example, I'd love to be able to flag these types
of errors and provide suggestions to the user within Cursive about what
might be the problem and how they might approach it - currently
incomprehensible error messages is one of Clojure's huge weak points IMO.


On 16 April 2014 13:23, Leif  wrote:

> Re: tagging issues, we should probably just ask clojure library authors to
> add their projects to OpenHatch's issue indexers.  They have them for
> Github issues and JIRA, which covers clojure/core (JIRA) and *most* current
> open source libs (Github).  That way, each individual project maintainer
> could choose the tags they want to signify "newcomer" (if I'm reading
> OpenHatch's docs correctly).
>
> Re: CodeAcademy-type sites, I think this might take a little work:
> CodeAcademy translates exceptions *or incorrect answers* into
> beginner-readable suggestions.  Considering they do this even for non-"code
> blows up" errors, they must make a list of common mistakes and the output
> generated by those mistakes (which to do correctly would require lots of
> user testing).
>
>
> --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.
>

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

[Marcus Blankenship]

Leif, thanks for the great session today.  Not only did I get a jump start on 
my next 4Clojure problems, but I learned some emacs as well!  Very enjoyable, 
and I look forward to next week's session.  THANK YOU!

All, if you're trying to get a jumpstart on Clojure, I highly recommend Leif's 
office hours.

-Marcus

On Apr 15, 2014, at 6:50 PM, Leif  wrote:

> @Jakub: Thanks for your kind words.  I'm definitely no "industry hero," but I 
> hope Clojure devs of all levels start having more pair programming fun.
> 
> @Tim: Clojurescript UI programming being way out of my comfort zone, I 
> learned quite a lot from you yesterday.  So thank you.
> 
> @Everyone:  To clarify / reiterate:  You do not need a plan, a project, or a 
> specific problem.  If you want to work through Project Euler, 4clojure, 
> clojure-koans, the ClojureBridge materials, some other clojure tutorial, or 
> just play it by ear, I am happy to try it out.
> 
> --Leif
> 
> On Tuesday, April 15, 2014 8:00:17 AM UTC-4, frye wrote:
> I just came from an office hours session, yesterday with Leif. 
> 
> This is good stuff guys, and a great way to learn and meet with other 
> developers. Highly recommended. 
> 
> 
> Thanks Leif 
> 
> Tim Washington 
> Interruptsoftware.com 
> 
> 
> On Tue, Apr 15, 2014 at 5:12 AM, Jakub Holy  wrote:
> Hi Leif,
> 
> This is a great activity, thank you for contributing to the community this 
> way!
> 
> Do not be surprise and discouraged by the fact that the interest seems low. I 
> have a similar experience - in my company we can consult with an "industry 
> hero" yet people use the opportunity seldom, presumably because of multiple 
> factors: they (wrongly) don't feel that they do not have something 
> important/interesting enough to bother him, they are little scared of talking 
> to and exposing themselves and their work to this experienced guy, and might 
> find it difficult to explain their challenge to an outsider and get an advice 
> within the limited time scope. On the other hand, those who dare to use the 
> opportunity benefit from it greatly.
> 
> Good luck, Jakub 
> 
> 
> On Friday, April 11, 2014 4:13:18 AM UTC+2, Leif wrote:
> Hmm... less interest than I'd expected, given recent posts.  Maybe I should 
> rename the thread to "Free Clojure Consulting / Tutoring."  Tht's not 
> spammy.
> 
> FYI, all bookings are automatically confirmed, so don't fret if I don't 
> instantly respond.
> 
> @Tim: Sounds good!  Of course, now I'll have to take some time this weekend 
> and try to actually understand Om. :)  (or maybe ?o_0? )
> 
> --Leif
> 
> On Thursday, April 10, 2014 9:56:37 AM UTC-4, frye wrote:
> Sounds great. I just sent a request. 
> 
> Tim Washington 
> Interruptsoftware.com 
> 
> 
> On Thu, Apr 10, 2014 at 9:43 AM, Colin Fleming  wrote:
> Hi Leif,
> 
> This sounds like a very interesting project, please report back and let us 
> know how it went! I'd be very interested to know.
> 
> Cheers,
> Colin
> 
> 
> On 11 April 2014 00:53, Leif  wrote:
> Hi, everybody.  Inspired by the SF Bay Area clojure group, ClojureBridge, and 
> the great talks on community education from Clojure/West on youtube, I've 
> decided to try holding my own personal Clojure office hours (online).
> 
> I am personally of the opinion that face-to-face interaction is superior, so 
> you may want to get your local user group to follow the Bay Area's lead.  But 
> if you don't agree, or you don't live near such a user group, then read on.
> 
> Borrowed from the Bay Area's posting:
> "This is a [2-person] meetup for anyone who is working on a Clojure project 
> and wants to talk over their code or approach with an experienced Clojure 
> developer.
> 
> Projects of all levels and complexity are welcome, anyone just getting 
> started in Clojure is encouraged to come in and talk through their first 
> Euler or 4Clojure problems."
> 
> Disclaimer: This community being what it is, there may be projects of too 
> high a complexity for me, but I'll give it a shot.
> 
> I'm going to try a test run of this for two weeks, and then I'll have to see 
> what state I'm in (mentally and geographically).  If interested, you can book 
> at this link:
> 
> https://leifpoorman.youcanbook.me/
> 
> Note: all the times are evening, US Eastern.  That pretty much limits it to 
> the western hemisphere and any east asian friends that want to do some 
> morning hacking.  Eastern hemisphere friends, make noise on this thread, and 
> maybe some brave European/Asian clojure developer will try something similar.
> 
> Cheers,
> Leif
> 
> 
> 
> -- 
> 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/clo

Re: Clojure Office Hours

[Leif]

@Jakub: Thanks for your kind words.  I'm definitely no "industry hero," but 
I hope Clojure devs of all levels start having more pair programming fun.

@Tim: Clojurescript UI programming being *way* out of my comfort zone, I 
learned quite a lot from you yesterday.  So thank *you*.

@Everyone:  To clarify / reiterate:  You do *not* need a plan, a project, 
or a specific problem.  If you want to work through Project Euler, 
4clojure, clojure-koans, the ClojureBridge materials, some other clojure 
tutorial, or just play it by ear, I am happy to try it out.

--Leif

On Tuesday, April 15, 2014 8:00:17 AM UTC-4, frye wrote:
>
> I just came from an office hours session, yesterday with Leif. 
>
> This is good stuff guys, and a great way to learn and meet with other 
> developers. Highly recommended. 
>
>
> Thanks Leif 
>
> Tim Washington 
> Interruptsoftware.com  
>
>
> On Tue, Apr 15, 2014 at 5:12 AM, Jakub Holy 
> > wrote:
>
>> Hi Leif,
>>
>> This is a great activity, thank you for contributing to the community 
>> this way!
>>
>> Do not be surprise and discouraged by the fact that the interest seems 
>> low. I have a similar experience - in my company we can consult with an 
>> "industry hero" yet people use the opportunity seldom, presumably because 
>> of multiple factors: they (wrongly) don't feel that they do not have 
>> something important/interesting enough to bother him, they are little 
>> scared of talking to and exposing themselves and their work to this 
>> experienced guy, and might find it difficult to explain their challenge to 
>> an outsider and get an advice within the limited time scope. On the other 
>> hand, those who dare to use the opportunity benefit from it greatly.
>>
>> Good luck, Jakub 
>>
>>
>> On Friday, April 11, 2014 4:13:18 AM UTC+2, Leif wrote:
>>>
>>> Hmm... less interest than I'd expected, given recent posts.  Maybe I 
>>> should rename the thread to "Free Clojure Consulting / Tutoring."  
>>> Tht's not spammy.
>>>
>>> FYI, all bookings are automatically confirmed, so don't fret if I don't 
>>> instantly respond.
>>>
>>> @Tim: Sounds good!  Of course, now I'll have to take some time this 
>>> weekend and try to actually understand Om. :)  (or maybe ?o_0? )
>>>
>>> --Leif
>>>
>>> On Thursday, April 10, 2014 9:56:37 AM UTC-4, frye wrote:

 Sounds great. I just sent a request. 

 Tim Washington 
  Interruptsoftware.com  


 On Thu, Apr 10, 2014 at 9:43 AM, Colin Fleming 
 wrote:

> Hi Leif,
>
> This sounds like a very interesting project, please report back and 
> let us know how it went! I'd be very interested to know.
>
> Cheers,
> Colin
>
>
> On 11 April 2014 00:53, Leif  wrote:
>
>> Hi, everybody.  Inspired by the SF Bay Area clojure group, 
>> ClojureBridge, and the great talks on community education from 
>> Clojure/West 
>> on youtube, I've decided to try holding my own personal Clojure office 
>> hours (online).
>>
>> I am personally of the opinion that face-to-face interaction is 
>> superior, so you may want to get your local user group to follow the Bay 
>> Area's lead.  But if you don't agree, or you don't live near such a user 
>> group, then read on.
>>
>> Borrowed from the Bay Area's posting:
>>
>> "This is a [2-person] meetup for anyone who is working on a Clojure 
>> project and wants to talk over their code or approach with an 
>> experienced 
>> Clojure developer.
>>
>> Projects of all levels and complexity are welcome, anyone just 
>> getting started in Clojure is encouraged to come in and talk through 
>> their 
>> first Euler or 4Clojure problems."
>> Disclaimer: This community being what it is, there may be projects of 
>> too high a complexity for me, but I'll give it a shot.
>>
>> I'm going to try a test run of this for two weeks, and then I'll have 
>> to see what state I'm in (mentally and geographically).  If interested, 
>> you 
>> can book at this link:
>>
>> https://leifpoorman.youcanbook.me/
>>
>> Note: all the times are evening, US Eastern.  That pretty much limits 
>> it to the western hemisphere and any east asian friends that want to do 
>> some morning hacking.  Eastern hemisphere friends, make noise on this 
>> thread, and maybe some brave European/Asian clojure developer will try 
>> something similar.
>>
>> Cheers,
>> Leif
>>
>>
>

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

Re: Helping newcomers get involved in Clojure projects

[Leif]

Re: tagging issues, we should probably just ask clojure library authors to 
add their projects to OpenHatch's issue indexers.  They have them for 
Github issues and JIRA, which covers clojure/core (JIRA) and *most* current 
open source libs (Github).  That way, each individual project maintainer 
could choose the tags they want to signify "newcomer" (if I'm reading 
OpenHatch's docs correctly).

Re: CodeAcademy-type sites, I think this might take a little work: 
CodeAcademy translates exceptions *or incorrect answers* into 
beginner-readable suggestions.  Considering they do this even for non-"code 
blows up" errors, they must make a list of common mistakes and the output 
generated by those mistakes (which to do correctly would require lots of 
user testing).

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

[Kris Calabio]

Thanks, Colin! I wasn't aware of mapv.


On Tue, Apr 15, 2014 at 6:08 PM, Colin Fleming
wrote:

> Note that you could use mapv, to perform the map but return a vector
> (filterv was also added at the same time).
>
>
> On 16 April 2014 11:46, Kris Calabio  wrote:
>
>> I'm not exactly sure, but I think it's the use of 'conj'. My entities get
>> out of order if they are not vectors.
>>
>> All this might not matter though, because I've started rewriting my game
>> from scratch since I'm using way too many mutable atoms than is necessary.
>> James' screencast cleared a lot of things up for me, and I have a better
>> understanding about how play-clj works.
>>
>> But just to clarify, when exactly does play-clj convert the entities back
>> into a vector? Is it when the callback functions of the screen return?
>>
>>
>>  On Tue, Apr 15, 2014 at 4:37 PM, Zach Oakes  wrote:
>>
>>>  I see. If your code requires a vector, I think you will have to coerce
>>> the list each time as you are doing. Out of curiosity, what are you doing
>>> that makes this necessary? Are you using something like get-in?
>>>
>>>
>>> On Tuesday, April 15, 2014 7:11:56 PM UTC-4, Kris Calabio wrote:
>>>
 In one of the callback functions in the defscreen I have a pipeline of
 functions that do something to the entities vector and return the resulting
 entities. I do something like this:

 (->> entities
   (process-entities01)
   (process-entities02)
   (map (fn [entity]
   (->> entity
  (process-entity01)
  (process-entity02)))
   (process-entities03))

 And that does not work, because each of the 'process-entities'
 functions are written in a way that expect a vector as input. Likewise,
 they each output a LazySeq unless I convert them back to a vector before
 returning. But I can't do that for the map function in the pipeline. But
 this does work:

 (->> entities
   (process-entities01)
   vec
   (process-entities02)
vec
   (map (fn [entity]
   (->> entity
  (process-entity01)
  (process-entity02)))
   vec
   (process-entities03)
   vec)




 On Tue, Apr 15, 2014 at 3:34 PM, Zach Oakes  wrote:

> Kris, the entities are automatically converted back into a vector by
> play-clj after being returned by a given function. Can you elaborate on
> what problem you believe is occurring when you don't change it back to a
> vector?
>
>
> On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:
>
>> James, I have a question. I see this pattern a lot in the sample code
>> and in your code as well, for example:
>>
>>
>>
>>
>> (defn- move-player [entities]
>>   (->> entities
>>
>>(map (fn [entity]
>>   (->> entity
>>
>>(update-player-position)
>>(update-hit-box
>>
>>
>>
>>
>>(remove-touched-apples)))
>>
>>
>> When the entities vector gets threaded through the map function, it
>> comes out as a LazySeq. But don't we want to keep the entities as a 
>> vector?
>> This seems to be causing problems in my own code, and the only way to 
>> keep
>> it working is to change it back to a vector every time I do this, which
>> seems inelegant. Just wondering if I'm missing something.
>> -Kris
>>
>>
>> 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:
>>
>>

Re: [Video] Game development in Clojure (with play-clj)

[Colin Fleming]

Note that you could use mapv, to perform the map but return a vector
(filterv was also added at the same time).


On 16 April 2014 11:46, Kris Calabio  wrote:

> I'm not exactly sure, but I think it's the use of 'conj'. My entities get
> out of order if they are not vectors.
>
> All this might not matter though, because I've started rewriting my game
> from scratch since I'm using way too many mutable atoms than is necessary.
> James' screencast cleared a lot of things up for me, and I have a better
> understanding about how play-clj works.
>
> But just to clarify, when exactly does play-clj convert the entities back
> into a vector? Is it when the callback functions of the screen return?
>
>
>  On Tue, Apr 15, 2014 at 4:37 PM, Zach Oakes  wrote:
>
>>  I see. If your code requires a vector, I think you will have to coerce
>> the list each time as you are doing. Out of curiosity, what are you doing
>> that makes this necessary? Are you using something like get-in?
>>
>>
>> On Tuesday, April 15, 2014 7:11:56 PM UTC-4, Kris Calabio wrote:
>>
>>> In one of the callback functions in the defscreen I have a pipeline of
>>> functions that do something to the entities vector and return the resulting
>>> entities. I do something like this:
>>>
>>> (->> entities
>>>   (process-entities01)
>>>   (process-entities02)
>>>   (map (fn [entity]
>>>   (->> entity
>>>  (process-entity01)
>>>  (process-entity02)))
>>>   (process-entities03))
>>>
>>> And that does not work, because each of the 'process-entities' functions
>>> are written in a way that expect a vector as input. Likewise, they each
>>> output a LazySeq unless I convert them back to a vector before returning.
>>> But I can't do that for the map function in the pipeline. But this does
>>> work:
>>>
>>> (->> entities
>>>   (process-entities01)
>>>   vec
>>>   (process-entities02)
>>>vec
>>>   (map (fn [entity]
>>>   (->> entity
>>>  (process-entity01)
>>>  (process-entity02)))
>>>   vec
>>>   (process-entities03)
>>>   vec)
>>>
>>>
>>>
>>>
>>> On Tue, Apr 15, 2014 at 3:34 PM, Zach Oakes  wrote:
>>>
 Kris, the entities are automatically converted back into a vector by
 play-clj after being returned by a given function. Can you elaborate on
 what problem you believe is occurring when you don't change it back to a
 vector?


 On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:

> James, I have a question. I see this pattern a lot in the sample code
> and in your code as well, for example:
>
>
>
> (defn- move-player [entities]
>   (->> entities
>
>(map (fn [entity]
>   (->> entity
>
>(update-player-position)
>(update-hit-box
>
>
>
>(remove-touched-apples)))
>
>
> When the entities vector gets threaded through the map function, it
> comes out as a LazySeq. But don't we want to keep the entities as a 
> vector?
> This seems to be causing problems in my own code, and the only way to keep
> it working is to change it back to a vector every time I do this, which
> seems inelegant. Just wondering if I'm missing something.
> -Kris
>
>
> 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 lookin

Re: Annotations on gen-class :state

[Colin Fleming]

That was what I figured. However Clojure currently makes certain kinds of
interop extremely painful, which makes it hard to integrate into existing
frameworks. I'm not proposing anything that would encourage concrete
derivation in pure Clojure programs, but I think that facilitating that
interop is a worthwhile goal, especially since it's an explicit design goal
of Clojure to expose the host where it's pragmatic to do so.

Don't make me maintain a fork :-)


On 16 April 2014 00:48, Alex Miller  wrote:

> I think not too favorably. :)  See http://clojure.org/datatypes where
> Rich says "concrete derivation is bad." I do not think he would be
> interested in adding anything to Clojure that included concrete derivation.
>
> --
> 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: Unexpected core.async timeout behaviour

[Ghadi Shayban]

Dredging this back up, you've read the scenario properly.  Timers are 
coalesced a particular resolution.

Use cases needing more than 1024 active handles on a channel can use a 
mult.  For example, if you had to timeout every request at a same time 
exactly 5 minutes in the future, (mult (timeout 30)) and then give 
every request a fresh tap of that.

The fixed 100 case I think you're getting lucky, whereas the random window 
you're getting unfavorable coalescing, which seems counterintuitive.


On Friday, March 28, 2014 9:52:47 AM UTC-4, Peter Taoussanis wrote:
>
> One thing I'm not clear on: if I've understood your explanation correctly, 
> I would expect the 100ms timeout to produce this error _more_ (not less) 
> often.
>
> So can I just confirm some things here?
>
> 1. `async/timeout` calls can (always?) get "cached" to the nearest 
> TIMEOUT_RESOLUTION_MS.
> 2. In this tight loop example, that means that ` called against the same (cached) timeout channel.
> 3. It's happening sufficiently often (do to the high loop count+speed) to 
> overflow the [unbuffered] timeout channel's implicit take buffer.
>
> Is that all right?
>
> If so, why isn't the fixed `(async/timeout 100)` channel producing the 
> same (or worse) behaviour? Is something preventing it from being cached in 
> the same way?
>

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

[Kris Calabio]

I'm not exactly sure, but I think it's the use of 'conj'. My entities get
out of order if they are not vectors.

All this might not matter though, because I've started rewriting my game
from scratch since I'm using way too many mutable atoms than is necessary.
James' screencast cleared a lot of things up for me, and I have a better
understanding about how play-clj works.

But just to clarify, when exactly does play-clj convert the entities back
into a vector? Is it when the callback functions of the screen return?


On Tue, Apr 15, 2014 at 4:37 PM, Zach Oakes  wrote:

> I see. If your code requires a vector, I think you will have to coerce the
> list each time as you are doing. Out of curiosity, what are you doing that
> makes this necessary? Are you using something like get-in?
>
>
> On Tuesday, April 15, 2014 7:11:56 PM UTC-4, Kris Calabio wrote:
>
>> In one of the callback functions in the defscreen I have a pipeline of
>> functions that do something to the entities vector and return the resulting
>> entities. I do something like this:
>>
>> (->> entities
>>   (process-entities01)
>>   (process-entities02)
>>   (map (fn [entity]
>>   (->> entity
>>  (process-entity01)
>>  (process-entity02)))
>>   (process-entities03))
>>
>> And that does not work, because each of the 'process-entities' functions
>> are written in a way that expect a vector as input. Likewise, they each
>> output a LazySeq unless I convert them back to a vector before returning.
>> But I can't do that for the map function in the pipeline. But this does
>> work:
>>
>> (->> entities
>>   (process-entities01)
>>   vec
>>   (process-entities02)
>>vec
>>   (map (fn [entity]
>>   (->> entity
>>  (process-entity01)
>>  (process-entity02)))
>>   vec
>>   (process-entities03)
>>   vec)
>>
>>
>>
>>
>> On Tue, Apr 15, 2014 at 3:34 PM, Zach Oakes  wrote:
>>
>>> Kris, the entities are automatically converted back into a vector by
>>> play-clj after being returned by a given function. Can you elaborate on
>>> what problem you believe is occurring when you don't change it back to a
>>> vector?
>>>
>>>
>>> On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:
>>>
 James, I have a question. I see this pattern a lot in the sample code
 and in your code as well, for example:

 (defn- move-player [entities]
   (->> entities

(map (fn [entity]
   (->> entity

(update-player-position)
(update-hit-box

(remove-touched-apples)))


 When the entities vector gets threaded through the map function, it
 comes out as a LazySeq. But don't we want to keep the entities as a vector?
 This seems to be causing problems in my own code, and the only way to keep
 it working is to change it back to a vector every time I do this, which
 seems inelegant. Just wondering if I'm missing something.
 -Kris


 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

Re: [Video] Game development in Clojure (with play-clj)

[Zach Oakes]

I see. If your code requires a vector, I think you will have to coerce the 
list each time as you are doing. Out of curiosity, what are you doing that 
makes this necessary? Are you using something like get-in?

On Tuesday, April 15, 2014 7:11:56 PM UTC-4, Kris Calabio wrote:
>
> In one of the callback functions in the defscreen I have a pipeline of 
> functions that do something to the entities vector and return the resulting 
> entities. I do something like this:
>
> (->> entities
>   (process-entities01)
>   (process-entities02)
>   (map (fn [entity]
>   (->> entity
>  (process-entity01)
>  (process-entity02)))
>   (process-entities03))
>
> And that does not work, because each of the 'process-entities' functions 
> are written in a way that expect a vector as input. Likewise, they each 
> output a LazySeq unless I convert them back to a vector before returning. 
> But I can't do that for the map function in the pipeline. But this does 
> work:
>
> (->> entities
>   (process-entities01)
>   vec
>   (process-entities02)
>vec
>   (map (fn [entity]
>   (->> entity
>  (process-entity01)
>  (process-entity02)))
>   vec
>   (process-entities03)
>   vec)
>
>   
>
>
> On Tue, Apr 15, 2014 at 3:34 PM, Zach Oakes 
> > wrote:
>
>> Kris, the entities are automatically converted back into a vector by 
>> play-clj after being returned by a given function. Can you elaborate on 
>> what problem you believe is occurring when you don't change it back to a 
>> vector?
>>
>>
>> On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:
>>
>>> James, I have a question. I see this pattern a lot in the sample code 
>>> and in your code as well, for example:
>>>
>>> (defn- move-player [entities]
>>>   (->> entities
>>>
>>>(map (fn [entity]
>>>   (->> entity
>>>
>>>(update-player-position)
>>>(update-hit-box
>>>
>>>(remove-touched-apples)))
>>>
>>>
>>> When the entities vector gets threaded through the map function, it 
>>> comes out as a LazySeq. But don't we want to keep the entities as a vector? 
>>> This seems to be causing problems in my own code, and the only way to keep 
>>> it working is to change it back to a vector every time I do this, which 
>>> seems inelegant. Just wondering if I'm missing something.
>>> -Kris
>>>
>>>
>>> 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 Goo

Re: [Video] Game development in Clojure (with play-clj)

[Kris Calabio]

In one of the callback functions in the defscreen I have a pipeline of
functions that do something to the entities vector and return the resulting
entities. I do something like this:

(->> entities
  (process-entities01)
  (process-entities02)
  (map (fn [entity]
  (->> entity
 (process-entity01)
 (process-entity02)))
  (process-entities03))

And that does not work, because each of the 'process-entities' functions
are written in a way that expect a vector as input. Likewise, they each
output a LazySeq unless I convert them back to a vector before returning.
But I can't do that for the map function in the pipeline. But this does
work:

(->> entities
  (process-entities01)
  vec
  (process-entities02)
   vec
  (map (fn [entity]
  (->> entity
 (process-entity01)
 (process-entity02)))
  vec
  (process-entities03)
  vec)




On Tue, Apr 15, 2014 at 3:34 PM, Zach Oakes  wrote:

> Kris, the entities are automatically converted back into a vector by
> play-clj after being returned by a given function. Can you elaborate on
> what problem you believe is occurring when you don't change it back to a
> vector?
>
>
> On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:
>
>> James, I have a question. I see this pattern a lot in the sample code and
>> in your code as well, for example:
>>
>> (defn- move-player [entities]
>>   (->> entities
>>
>>(map (fn [entity]
>>   (->> entity
>>
>>(update-player-position)
>>(update-hit-box
>>(remove-touched-apples)))
>>
>>
>> When the entities vector gets threaded through the map function, it comes
>> out as a LazySeq. But don't we want to keep the entities as a vector? This
>> seems to be causing problems in my own code, and the only way to keep it
>> working is to change it back to a vector every time I do this, which seems
>> inelegant. Just wondering if I'm missing something.
>> -Kris
>>
>>
>> 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/to
> pic/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...@googlegrou

Re: [Video] Game development in Clojure (with play-clj)

[Zach Oakes]

Kris, the entities are automatically converted back into a vector by 
play-clj after being returned by a given function. Can you elaborate on 
what problem you believe is occurring when you don't change it back to a 
vector?

On Tuesday, April 15, 2014 5:26:07 PM UTC-4, Kris Calabio wrote:
>
> James, I have a question. I see this pattern a lot in the sample code and 
> in your code as well, for example:
>
> (defn- move-player [entities]
>   (->> entities
>
>(map (fn [entity]
>   (->> entity
>
>(update-player-position)
>(update-hit-box
>(remove-touched-apples)))
>
>
> When the entities vector gets threaded through the map function, it comes 
> out as a LazySeq. But don't we want to keep the entities as a vector? This 
> seems to be causing problems in my own code, and the only way to keep it 
> working is to change it back to a vector every time I do this, which seems 
> inelegant. Just wondering if I'm missing something.
> -Kris
>
>
> 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 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 t

Re: [Video] Game development in Clojure (with play-clj)

[Kris Calabio]

James, I have a question. I see this pattern a lot in the sample code and
in your code as well, for example:

(defn- move-player [entities]
  (->> entities
   (map (fn [entity]
  (->> entity
   (update-player-position)
   (update-hit-box
   (remove-touched-apples)))


When the entities vector gets threaded through the map function, it comes
out as a LazySeq. But don't we want to keep the entities as a vector? This
seems to be causing problems in my own code, and the only way to keep it
working is to change it back to a vector every time I do this, which seems
inelegant. Just wondering if I'm missing something.
-Kris


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

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

Re: [ANN] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[Sam Ritchie]

I think the two granularities I'd be interested in are channels and 
individual users.


If we exposed a global list of uids, and a list of UIDs per channel, I 
think we'd have enough to build up a nice set of broadcast operations. 
For example:


- Broadcast to this channel for users that pass this predicate
- hit these multiple channels except for these users
- re-broadcast this user's message to everyone in the channel except 
this user


So yeah, I think that exposing a list will get us pretty far. The 
missing piece, then, would be the ability for a a client to send a 
connection request for a specific channel.



Peter Taoussanis 
April 15, 2014 10:18 AM
Hey Sam!

it doesn't look like the list of all connected users is available
in the API.


Yeah, that's right. Have been punting on this...

For the moment have left it up to applications to decide who they're 
interested in broadcasting to. This might be everyone that's 
connected, everyone that's connected with certain credentials, 
everyone subscribed to certain topics, etc.


Basically the application's expected to keep an appropriate index of 
event-types -> user-ids.


Haven't thought much about what kind of help the core API could offer. 
Probably a good starting point would be a simple set of all currently 
connected uids. Then folks could intersect that against their own 
subscriptions, etc.


Would that be helpful in your case? Otherwise, like I say - haven't 
thought much about this so ideas would be very welcome.


Cheers! :-)
--
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.
Sam Ritchie 
April 15, 2014 9:05 AM
Hey Peter,

I like the UUID feature, but it doesn't look like the list of all 
connected users is available in the API. How would you do a global 
broadcast to all connected clients using Sente? I'm having trouble 
figuring out how to write a chat demo using Sente.


Thanks for your work!

On Wednesday, February 26, 2014 6:57:24 AM UTC-7, Peter Taoussanis wrote:
--
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.
Peter Taoussanis 
February 26, 2014 6:57 AM
Hi folks,

Quick post to announce a new lib release: 
https://github.com/ptaoussanis/sente


From the README:
*Sente* is small client+server library that makes it easy to build 
*reliable, high-performance realtime web applications with Clojure*.


* *Bidirectional a/sync comms*over 
both*WebSockets*and*Ajax*(auto-selecting).

* *Robust*: auto keep-alives, buffering, mode fallback, reconnects.
* ednrocks. So*send edn, get edn*: no json here.
* *Tiny, simple API*:|make-channel-socket!|and you're good to go.
* Automatic, sensible support for users connected with*multiple 
clients*and/or devices simultaneously.

* *Flexible model*: use it anywhere you'd use WebSockets or Ajax.
* *Fully documented, with examples*(more forthcoming).
* Small:*less than 600 lines of code*for the entire client+server 
implementation.

* *Supported servers*: currently onlyhttp-kit, but easily extended.

---
Have been using something like this in production since a little after 
core.async came out, and wouldn't want to go back. Note that I tweaked 
a few things for the public release so there may be some rough edges 
initially.


An example project's included (new as of today) and there's a 
Leiningen alias configured to handle all the fiddly bits like getting 
the Cljx and Cljs to compile: just download, `lein start-dev` at a 
terminal, and you're good to go.


Any questions/problems/whatever, you can reach me here or on GitHub.

That's it! Happy hacking, cheer

One app, multiple mains \ processes -- heroku style architecture

[Jarrod Swart]

I've been reading about Heroku's process model and their approach to web 
app architecture.

I'm curious how you could recreate something like this:

https://devcenter.heroku.com/articles/getting-started-with-clojure#one-off-scripts

Using an uberjar in environments other than heroku.

Would it make sense to uberjar with multiple profiles and separate mains 
for each type of process.  An "app", "worker", "scheduler", etc.

I imagine in that case you spin up each version of your app on the full JVM 
and that could get troublesome.

Much of this stems from wanting to separate my scheduled tasks from the 
same process as my web app.  I haven't found a good way to do this and this 
approach seems like a move in the right direction at least.

Any thoughts? 

-- 
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] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[Peter Taoussanis]

Hey Sam!

it doesn't look like the list of all connected users is available in the
> API.
>

Yeah, that's right. Have been punting on this...

For the moment have left it up to applications to decide who they're
interested in broadcasting to. This might be everyone that's connected,
everyone that's connected with certain credentials, everyone subscribed to
certain topics, etc.

Basically the application's expected to keep an appropriate index of
event-types -> user-ids.

Haven't thought much about what kind of help the core API could offer.
Probably a good starting point would be a simple set of all currently
connected uids. Then folks could intersect that against their own
subscriptions, etc.

Would that be helpful in your case? Otherwise, like I say - haven't thought
much about this so ideas would be very welcome.

Cheers! :-)

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

Yep, you've pretty much nailed it... the design was heavily inspired by the
OSGi service registry, but we didn't really have a need for most of the
other functionality that OSGi offers.  So we basically just came up with a
way to describe services via Clojure protocols, and then we wire them
together with Prismatic graph (thanks, Prismatic!).  Hope folks find it
useful!


On Mon, Apr 14, 2014 at 9:24 PM, Mike Haney  wrote:

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

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

[Gary Trakhman]

Is there a generalized framework we can use for such 'codeacademy' sites?
The closest thing that already exists I think is 4clojure, perhaps adding a
tracks-navigation sort of thing would address that specific need?

Though, I think my criticism with these things, is the best way to learn
really depends on how much time you have and your level of experience.  If
you have a ton of time, ie a full-time job, then you're going to learn
compojure much 'deeper' and faster in the long run by simply reading the
compojure library code, following trails, and implementing what you need.

Learning the syntax doesn't tell you much about ring-handlers, middleware,
the weird destructuring, etc..

If you build on lower abstractions (ring) first, it might address that
particular issue, at the expense of people feeling like they're doing
irrelevant stuff.

Honestly, I felt the same way about the compojure tutorials :-).  But, I'm
not sure how I'd make them better.  M-. is my best friend.

I think 4clojure itself does the right thing, using the most
base/general/accessible abstractions and making it fun (in my opinion),
building muscle memory.

All that said, I'd be happy to contribute problems/solutions to such a
thing if it existed.


On Tue, Apr 15, 2014 at 3:10 AM, kurofune  wrote:

> For what it's worth, I would like to see a codecademy.com type site but
> for Clojure that can take you from 0 to hero, in one place, with
> interactive tracks depending on subject (i.e. Web-Dev, core functions, key
> libraries, idioms, regex, encryption, etc.). Something like an interactive
> SICP to teach core programming concepts but using Clojure would be nice.
> 4clojure has cool problems but they don't teach you to program.
>
> The best resources I've utilized are "Clojure in Action" and "Web
> Development with Clojure". Clojure from the Ground up and Clojure for the
> Brave and true were also good. The problem with the books is that the
> libs/APIs you learn in the tutorials are often deprecated or abandoned by
> the community for the next hot thing, by the time you even pick them up.
> One, open source, Community maintained user friendly resource with
> "batteries included" would be awesome.
>
> By and large community support has been good for me and I am often
> assisted by the very dude who wrote the book I'm working through. How can I
> complain about that?  This is simply awesome and I hope that stays possible
> in the future.
>
> I would really like a mentor.  Any programs that provide this would make
> the Clojure community stand out as friendly and welcoming, compared to
> other languages. This is just my two cents. Hope it is useful.
>
> Jesse
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[Sam Ritchie]

Hey Peter,

I like the UUID feature, but it doesn't look like the list of all connected 
users is available in the API. How would you do a global broadcast to all 
connected clients using Sente? I'm having trouble figuring out how to write 
a chat demo using Sente.

Thanks for your work!

On Wednesday, February 26, 2014 6:57:24 AM UTC-7, Peter Taoussanis wrote:
>
> Hi folks,
>
> Quick post to announce a new lib release: 
> https://github.com/ptaoussanis/sente
>
> From the README:
> *Sente* is small client+server library that makes it easy to build *reliable, 
> high-performance realtime web applications with Clojure*.
>
> * *Bidirectional a/sync comms* over both *WebSockets* and *Ajax* 
> (auto-selecting).
> * *Robust*: auto keep-alives, buffering, mode fallback, reconnects.
> * edn rocks. So *send edn, get edn*: no json here.
> * *Tiny, simple API*: make-channel-socket! and you're good to go.
> * Automatic, sensible support for users connected with *multiple clients* 
> and/or 
> devices simultaneously.
> * *Flexible model*: use it anywhere you'd use WebSockets or Ajax.
> * *Fully documented, with examples* (more forthcoming).
> * Small: *less than 600 lines of code* for the entire client+server 
> implementation.
> * *Supported servers*: currently only http-kit, but easily extended.
>
> ---
> Have been using something like this in production since a little after 
> core.async came out, and wouldn't want to go back. Note that I tweaked a 
> few things for the public release so there may be some rough edges 
> initially. 
>
> An example project's included (new as of today) and there's a Leiningen 
> alias configured to handle all the fiddly bits like getting the Cljx and 
> Cljs to compile: just download, `lein start-dev` at a terminal, and you're 
> good to go.
>
> Any questions/problems/whatever, you can reach me here or on GitHub.
>
> That's it! Happy hacking, cheers! :-)
> - *Peter Taoussanis*
> https://twitter.com/ptaoussanis
> https://www.taoensso.com/clojure-libraries
>

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

[Jony Hudson]

Thanks for the kind words chaps - glad you like it!

@Steve Are you sure your Leiningen is up to date? I've only seen this 
problem when accidentally trying to run Gorilla with Lein 1.7 (as Debian 
seems to have that version as its default install).

@Andrew Probably not what you're looking for, but there should be a 
renderer for Loom graphs soon, which shells out to GraphViz to do the heavy 
lifting. Take a look at this PR: https://github.com/aysylu/loom/pull/20 . 
Even if your data doesn't fit with loom then it might be useful for an idea.

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

Re: How to work with variables that need to change

[Gary Trakhman]

One nitpick I noticed, reduce is eager, not lazy.


On Tue, Apr 15, 2014 at 9:25 AM, Alex Vzorov  wrote:

> Hi, Cecil.
>
> The difference is that doseq is used to produce side-effects, which is
> idiomatic, which is exactly what you did. When using doseq you can be
> sure that it's body will evaluate, whereas with map, for, reduce you
> can't - they expect pure functions, and produce lazy sequences, and there
> in no way for them to know that you want these sequences evaluated. At
> least, this is my understanding at the moment.
>
> Because you said you liked clean code, I'd like to point out that your
> solution, although works, relies on mutating state of external vars, i.e.
> producing side effects, which is not necessary, and looks spaghetti-like,
> somewhat.
>
> Instead, you could modify return value of foo function to return a vector
> of [result, time], or, because you seem to not care about the result,
> time the function took to complete.
>
> It would look similar to what you already did:
>
> - first define a higher order function, that records executions time of a
> supplied function:
>
> (defn timed [f]
>   (fn [& args]
> (let [start (.getTimeInMillis (now))
>   result (apply f args)
>   end (.getTimeInMillis (now))]
>   [result (- end start)])))
>
> - define a timed version of foo:
>
> (defn foo' (timed foo))
>
> - use it with doseq, because you are doing side-effects:
>
> (doseq [time (map second (map foo' numbers))]
> ;; alternatively, you can use threading macro: (doseq [time (->> numbers
> (map foo') (map second))]
>   (println "it took" time "ms"))
>
> And it works! Without mutating global state, with pure functions - what a
> marvel. However, one piece is missing: number of threads the foo function
> was using - the whole point of this typing, eh, programming, I mean.
> You have 2 options here. First, the most obvious, is to return that number
> in foo. Second is applicable if you're doing what I think you're doing -
> applying the same computational algorithm using different number of
> threads. If second is true, you know number of threads you are going to use
> beforehand and foo could use them as input... ah, well, this is exactly
> what you were doing, I know realize, numbers being number of threads to
> use. Anyways, in light of this knowledge we can now rewrite doseq part as:
>
> (doseq [[time nthreads] (map (fn [n] [(second (foo' n)) n]) numbers)]
>   (println nthreads "threads took" time "ms to compute things"))
>
> Yay!
> Note, that timed should work regardless of what function you supply to it.
>
> On Saturday, April 12, 2014 10:33:02 PM UTC+5:45, Cecil Westerhof wrote:
>>
>> 2014-04-12 18:19 GMT+02:00 Fergal Byrne :
>>
>>
>>> On Sat, Apr 12, 2014 at 4:55 PM, Cecil Westerhof wrote:
>>>
 (->> numbers
  (reduce timed-foo [])
  (map format-time)
  println)

>>>
>>> (->> numbers
>>>  (reduce timed-foo [])
>>>  (map format-time)
>>>  (map println))
>>>
>>
>> That was my first thought also, but that displays nothing.
>>
>> But the following works:
>> (doseq [i (->> numbers
>>  (reduce timed-foo [])
>>  (map format-time))]
>>  (println i))
>>
>> --
>> Cecil Westerhof
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: How to work with variables that need to change

[Alex Vzorov]

Hi, Cecil.

The difference is that doseq is used to produce side-effects, which is 
idiomatic, which is exactly what you did. When using doseq you can be sure 
that it's body will evaluate, whereas with map, for, reduce you can't - 
they expect pure functions, and produce lazy sequences, and there in no way 
for them to know that you want these sequences evaluated. At least, this is 
my understanding at the moment.

Because you said you liked clean code, I'd like to point out that your 
solution, although works, relies on mutating state of external vars, i.e. 
producing side effects, which is not necessary, and looks spaghetti-like, 
somewhat.

Instead, you could modify return value of foo function to return a vector 
of [result, time], or, because you seem to not care about the result, time 
the function took to complete.

It would look similar to what you already did:

- first define a higher order function, that records executions time of a 
supplied function:

(defn timed [f]
  (fn [& args]
(let [start (.getTimeInMillis (now))
  result (apply f args)
  end (.getTimeInMillis (now))]
  [result (- end start)])))

- define a timed version of foo:

(defn foo' (timed foo))

- use it with doseq, because you are doing side-effects:

(doseq [time (map second (map foo' numbers))]
;; alternatively, you can use threading macro: (doseq [time (->> numbers 
(map foo') (map second))]
  (println "it took" time "ms"))

And it works! Without mutating global state, with pure functions - what a 
marvel. However, one piece is missing: number of threads the foo function 
was using - the whole point of this typing, eh, programming, I mean.
You have 2 options here. First, the most obvious, is to return that number 
in foo. Second is applicable if you're doing what I think you're doing - 
applying the same computational algorithm using different number of 
threads. If second is true, you know number of threads you are going to use 
beforehand and foo could use them as input... ah, well, this is exactly 
what you were doing, I know realize, numbers being number of threads to 
use. Anyways, in light of this knowledge we can now rewrite doseq part as:

(doseq [[time nthreads] (map (fn [n] [(second (foo' n)) n]) numbers)]
  (println nthreads "threads took" time "ms to compute things"))

Yay!
Note, that timed should work regardless of what function you supply to it.

On Saturday, April 12, 2014 10:33:02 PM UTC+5:45, Cecil Westerhof wrote:
>
> 2014-04-12 18:19 GMT+02:00 Fergal Byrne 
> >:
>
>>
>> On Sat, Apr 12, 2014 at 4:55 PM, Cecil Westerhof 
>> 
>> > wrote:
>>
>>> (->> numbers
>>>  (reduce timed-foo [])
>>>  (map format-time)
>>>  println)
>>>
>>
>> (->> numbers
>>  (reduce timed-foo [])
>>  (map format-time)
>>  (map println))
>>
>
> That was my first thought also, but that displays nothing.
>
> But the following works:
> (doseq [i (->> numbers
>  (reduce timed-foo [])
>  (map format-time))]
>  (println i))
>
> -- 
> Cecil Westerhof 
>

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

I think not too favorably. :)  See http://clojure.org/datatypes where Rich says 
"concrete derivation is bad." I do not think he would be interested in adding 
anything to Clojure that included concrete derivation. 

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

[Frankie Sardo]

Thanks for the pointers Andy.
I had a look at the ordered-map and indeed is a smart and fast 
implementation. However it relies on continuously growing a backing array, 
filling dissoc-iated values with nil and hoping that at one point the user 
will call (compact map) to free all the unused positions. In theory my 
implementation should scale better as it only uses the space that it needs.

However after more benchmarking I observed the following:

- (assoc with multiple key-vals) does indeed slow down the operations. But 
calling transient and persistent! only makes things worse with bigger maps 
(I guess the whole map is copied before making it transient).
- There is quite a bottleneck due to querying 'head' and 'tail' on every 
insertion. I thought the performance of a standard hash-map was definitely 
better :)

I could speed up the assoc performance avoiding the insertion of head and 
tail inside the delegate-map and keeping those two nodes as class fields. 
That won't make dissoc better but it seems like a reasonable compromise.

Out of curiosity, is anybody using ordered-map in their projects? Since 
performance is comparable to a standard hash-map I would always prefer to 
use it for the deterministic ordering of the keys. Makes reproducing and 
catching bugs/errors easier imho.


On Monday, April 14, 2014 10:48:48 PM UTC+2, Andy Fingerhut wrote:
>
> 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 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.c

Re: Clojure compiletime vs runtime

[Luc Prefontaine]

Compilation is mandatory before
executing anything.

By default when code is loaded it's
executed. That's how a Lisp behaves.

If you want to isolate compilation,
from execution, you can use AOT (ahead of time 
compilation).

You would use this to
deliver compiled code w/o source
code, make sure there's no missing
references, ...

But this is not used in interactive
development where you want to
redefine stuff, change states, 
and be as dynamic as possible.

Do you have a specific need that
you want to cover ?

Luc P.

> Why are the toplevel forms which arent macros executed at compile time? For
> example Lua can be compiled to bytecode without executing
> its top level calls.
> 
> 
> On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts 
> wrote:
> 
> > Ahem :)
> >
> > a) The fn x does not exist in the universe until you call foo, hence you
> > cannot
> > expect the compiler to known anything about it if it's not called
> > before
> > making any reference to x.
> >
> > b) If you refer to x at the top level (the "universe" above :) before
> > defining
> > it, obviously it does not exist. You might use (declare x) before
> > referring to it. This allows you to define it later at your
> > convenience.
> >
> > c) In general, you should avoid using def/defn within a function.
> > Macros may do that but this is a different story.
> >
> > d) Yes code at the top level is executed, how can you expect
> > the REPL to work interactively if forms are not evaluated first ?
> > A defn expands to a function call, a special form in fact but it still
> > behaves
> > like a function. Any function call at top level will get executed
> > after being
> > compiled to byte code.
> >
> > Now about the "compilation" step...
> >
> > Traditionally, most Lisps allow you to refer to stuff in interpreted mode
> > not defined yet hoping that it will get defined by the time you run the
> > code
> > that refers to these undefined things. It can even be something transient
> > on
> > the stack... oups...
> >
> > You can still compile in other Lisps but this is a special case where you
> > have to
> > make sure that stuff is defined in some way. You need to add directives to
> > tell the compiler that this stuff will exist later and that it can safely
> > refer to it.
> >
> > On the JVM, some underlying byte code has to be generated for any forms
> > typed in the REPL at the top level any reference has to be defined before
> > hand.
> >
> > There's no other way to generate byte code... there cannot be black holes
> > waiting to get filled later.
> >
> > Hence the "compilation" phase and the restriction
> > that stuff you refer to are to be defined either directly or using declare.
> >
> > Hope it explains the compromise.
> >
> > Luc P.
> >
> >
> > > 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.
> > >
> > --
> > Softaddicts sent by ibisMail from my ipad!
> >
> > --
> > 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 

Re: "true" lightweight threads on clojurescript?

[Andrew Chambers]

You need to write either an interpreter of some sort of bytecode in 
javascript/clojurescript and and have the interpreter implement the 
threading, or use a webworker for each process then something like 
core.async for sending ui events to the main browser loop. Clojurescript 
doesnt attempt to emulate full threads.

On Wednesday, April 9, 2014 8:51:57 AM UTC+12, t x wrote:
>
> Hi, 
>
>
>   * I am aware of core.async. However, I don't like the fact that (go 
> ... ) is a macro, thus forcing the >! and  and I can't do nested things like: 
>
>   (defn foo [chan] 
>  (let [x (
>   (go ... (foo ... )) 
>
>
>   * For the following, I only need it to work in ClojureScript. I 
> don't need it to work in Clojure. Furthermore, we can assume browser = 
> latest Firefox, or browser = latest Chrome. 
>
>
>   Now, my question: is there a library which provides "true" 
> lightweight Clojurescript threads? 
>
>
> Thanks! 
>

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

Re: Clojure Office Hours

[Timothy Washington]

I just came from an office hours session, yesterday with Leif.

This is good stuff guys, and a great way to learn and meet with other
developers. Highly recommended.


Thanks Leif

Tim Washington
Interruptsoftware.com 


On Tue, Apr 15, 2014 at 5:12 AM, Jakub Holy  wrote:

> Hi Leif,
>
> This is a great activity, thank you for contributing to the community this
> way!
>
> Do not be surprise and discouraged by the fact that the interest seems
> low. I have a similar experience - in my company we can consult with an
> "industry hero" yet people use the opportunity seldom, presumably because
> of multiple factors: they (wrongly) don't feel that they do not have
> something important/interesting enough to bother him, they are little
> scared of talking to and exposing themselves and their work to this
> experienced guy, and might find it difficult to explain their challenge to
> an outsider and get an advice within the limited time scope. On the other
> hand, those who dare to use the opportunity benefit from it greatly.
>
> Good luck, Jakub
>
>
> On Friday, April 11, 2014 4:13:18 AM UTC+2, Leif wrote:
>>
>> Hmm... less interest than I'd expected, given recent posts.  Maybe I
>> should rename the thread to "Free Clojure Consulting / Tutoring."
>> Tht's not spammy.
>>
>> FYI, all bookings are automatically confirmed, so don't fret if I don't
>> instantly respond.
>>
>> @Tim: Sounds good!  Of course, now I'll have to take some time this
>> weekend and try to actually understand Om. :)  (or maybe ?o_0? )
>>
>> --Leif
>>
>> On Thursday, April 10, 2014 9:56:37 AM UTC-4, frye wrote:
>>>
>>> Sounds great. I just sent a request.
>>>
>>> Tim Washington
>>>  Interruptsoftware.com 
>>>
>>>
>>> On Thu, Apr 10, 2014 at 9:43 AM, Colin Fleming wrote:
>>>
 Hi Leif,

 This sounds like a very interesting project, please report back and let
 us know how it went! I'd be very interested to know.

 Cheers,
 Colin


 On 11 April 2014 00:53, Leif  wrote:

> Hi, everybody.  Inspired by the SF Bay Area clojure group,
> ClojureBridge, and the great talks on community education from 
> Clojure/West
> on youtube, I've decided to try holding my own personal Clojure office
> hours (online).
>
> I am personally of the opinion that face-to-face interaction is
> superior, so you may want to get your local user group to follow the Bay
> Area's lead.  But if you don't agree, or you don't live near such a user
> group, then read on.
>
> Borrowed from the Bay Area's posting:
>
> "This is a [2-person] meetup for anyone who is working on a Clojure
> project and wants to talk over their code or approach with an experienced
> Clojure developer.
>
> Projects of all levels and complexity are welcome, anyone just getting
> started in Clojure is encouraged to come in and talk through their first
> Euler or 4Clojure problems."
> Disclaimer: This community being what it is, there may be projects of
> too high a complexity for me, but I'll give it a shot.
>
> I'm going to try a test run of this for two weeks, and then I'll have
> to see what state I'm in (mentally and geographically).  If interested, 
> you
> can book at this link:
>
> https://leifpoorman.youcanbook.me/
>
> Note: all the times are evening, US Eastern.  That pretty much limits
> it to the western hemisphere and any east asian friends that want to do
> some morning hacking.  Eastern hemisphere friends, make noise on this
> thread, and maybe some brave European/Asian clojure developer will try
> something similar.
>
> Cheers,
> Leif
>
>

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

[Andrew Chambers]

This is awesome (reminds me of ipython notebooks). I hope to use this to 
custom render some data structures internal to my compiler project. I'll 
have to read up on how to render  directed graphs.

On Thursday, March 20, 2014 9:22:57 AM UTC+13, 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: Clojure compiletime vs runtime

[Andrew Chambers]

I only noticed it because I was trying to write a macro which expands to
multiple def calls. This requires the def's to be inside a do block, which
made me question a whole lot about how the AOT compiler works.


On Tue, Apr 15, 2014 at 11:05 PM, Phillip Lord  wrote:

>
> You need to distinguish between "compiled" and "aot compiled to byte
> code".
>
> As far as I know, all forms are compiled before they are executed. So,
> if you type:
>
> (+ 1 1)
>
> it is first compiled to bytecode, and then run. It's not executed at
> compile time at all; rather when it is evaluated, it is compiled and
> then run. If you aot compile, then you are do the same thing, but dump
> the bytecode to file. So, you still evaluate the entire top level.
>
> So, when you say compile, I presume you you mean aot compiled. Macros
> have to be run, so the question is should they be expanded but not
> evaluated? And what about macros with side-effects?
>
> And if top level forms are NOT evaluated when loaded what would this do:
>
> (ns user)
> (def x 1)
>
> (load "user_y")
>
> === in user_y.clj
> (def y 1)
>
>
> Now the AOT would only load the first file in the namespace because
> (load "user_y") would not be evaluated.
>
> Why are you worried about this? Most of the time compilation in Clojure
> is an implementation detail, as it is in python. It just happens when it
> needs to, and away you go.
>
> Phil
>
>
>
> Andrew Chambers  writes:
> > Why are the toplevel forms which arent macros executed at compile time?
> For
> > example Lua can be compiled to bytecode without executing
> > its top level calls.
> >
> >
> > On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts <
> lprefonta...@softaddicts.ca>wrote:
> >
> >> Ahem :)
> >>
> >> a) The fn x does not exist in the universe until you call foo, hence you
> >> cannot
> >> expect the compiler to known anything about it if it's not called
> >> before
> >> making any reference to x.
> >>
> >> b) If you refer to x at the top level (the "universe" above :) before
> >> defining
> >> it, obviously it does not exist. You might use (declare x) before
> >> referring to it. This allows you to define it later at your
> >> convenience.
> >>
> >> c) In general, you should avoid using def/defn within a function.
> >> Macros may do that but this is a different story.
> >>
> >> d) Yes code at the top level is executed, how can you expect
> >> the REPL to work interactively if forms are not evaluated first ?
> >> A defn expands to a function call, a special form in fact but it
> still
> >> behaves
> >> like a function. Any function call at top level will get executed
> >> after being
> >> compiled to byte code.
> >>
> >> Now about the "compilation" step...
> >>
> >> Traditionally, most Lisps allow you to refer to stuff in interpreted
> mode
> >> not defined yet hoping that it will get defined by the time you run the
> >> code
> >> that refers to these undefined things. It can even be something
> transient
> >> on
> >> the stack... oups...
> >>
> >> You can still compile in other Lisps but this is a special case where
> you
> >> have to
> >> make sure that stuff is defined in some way. You need to add directives
> to
> >> tell the compiler that this stuff will exist later and that it can
> safely
> >> refer to it.
> >>
> >> On the JVM, some underlying byte code has to be generated for any forms
> >> typed in the REPL at the top level any reference has to be defined
> before
> >> hand.
> >>
> >> There's no other way to generate byte code... there cannot be black
> holes
> >> waiting to get filled later.
> >>
> >> Hence the "compilation" phase and the restriction
> >> that stuff you refer to are to be defined either directly or using
> declare.
> >>
> >> Hope it explains the compromise.
> >>
> >> Luc P.
> >>
> >>
> >> > 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.c

Re: Clojure compiletime vs runtime

[Phillip Lord]

You need to distinguish between "compiled" and "aot compiled to byte
code".

As far as I know, all forms are compiled before they are executed. So,
if you type:

(+ 1 1)

it is first compiled to bytecode, and then run. It's not executed at
compile time at all; rather when it is evaluated, it is compiled and
then run. If you aot compile, then you are do the same thing, but dump
the bytecode to file. So, you still evaluate the entire top level.

So, when you say compile, I presume you you mean aot compiled. Macros
have to be run, so the question is should they be expanded but not
evaluated? And what about macros with side-effects?

And if top level forms are NOT evaluated when loaded what would this do:

(ns user)
(def x 1)

(load "user_y")

=== in user_y.clj
(def y 1)


Now the AOT would only load the first file in the namespace because
(load "user_y") would not be evaluated.

Why are you worried about this? Most of the time compilation in Clojure
is an implementation detail, as it is in python. It just happens when it
needs to, and away you go.

Phil

 

Andrew Chambers  writes:
> Why are the toplevel forms which arent macros executed at compile time? For
> example Lua can be compiled to bytecode without executing
> its top level calls.
>
>
> On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts 
> wrote:
>
>> Ahem :)
>>
>> a) The fn x does not exist in the universe until you call foo, hence you
>> cannot
>> expect the compiler to known anything about it if it's not called
>> before
>> making any reference to x.
>>
>> b) If you refer to x at the top level (the "universe" above :) before
>> defining
>> it, obviously it does not exist. You might use (declare x) before
>> referring to it. This allows you to define it later at your
>> convenience.
>>
>> c) In general, you should avoid using def/defn within a function.
>> Macros may do that but this is a different story.
>>
>> d) Yes code at the top level is executed, how can you expect
>> the REPL to work interactively if forms are not evaluated first ?
>> A defn expands to a function call, a special form in fact but it still
>> behaves
>> like a function. Any function call at top level will get executed
>> after being
>> compiled to byte code.
>>
>> Now about the "compilation" step...
>>
>> Traditionally, most Lisps allow you to refer to stuff in interpreted mode
>> not defined yet hoping that it will get defined by the time you run the
>> code
>> that refers to these undefined things. It can even be something transient
>> on
>> the stack... oups...
>>
>> You can still compile in other Lisps but this is a special case where you
>> have to
>> make sure that stuff is defined in some way. You need to add directives to
>> tell the compiler that this stuff will exist later and that it can safely
>> refer to it.
>>
>> On the JVM, some underlying byte code has to be generated for any forms
>> typed in the REPL at the top level any reference has to be defined before
>> hand.
>>
>> There's no other way to generate byte code... there cannot be black holes
>> waiting to get filled later.
>>
>> Hence the "compilation" phase and the restriction
>> that stuff you refer to are to be defined either directly or using declare.
>>
>> Hope it explains the compromise.
>>
>> Luc P.
>>
>>
>> > 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.goog

Re: Clojure compiletime vs runtime

[Andrew Chambers]

Why are the toplevel forms which arent macros executed at compile time? For
example Lua can be compiled to bytecode without executing
its top level calls.


On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts wrote:

> Ahem :)
>
> a) The fn x does not exist in the universe until you call foo, hence you
> cannot
> expect the compiler to known anything about it if it's not called
> before
> making any reference to x.
>
> b) If you refer to x at the top level (the "universe" above :) before
> defining
> it, obviously it does not exist. You might use (declare x) before
> referring to it. This allows you to define it later at your
> convenience.
>
> c) In general, you should avoid using def/defn within a function.
> Macros may do that but this is a different story.
>
> d) Yes code at the top level is executed, how can you expect
> the REPL to work interactively if forms are not evaluated first ?
> A defn expands to a function call, a special form in fact but it still
> behaves
> like a function. Any function call at top level will get executed
> after being
> compiled to byte code.
>
> Now about the "compilation" step...
>
> Traditionally, most Lisps allow you to refer to stuff in interpreted mode
> not defined yet hoping that it will get defined by the time you run the
> code
> that refers to these undefined things. It can even be something transient
> on
> the stack... oups...
>
> You can still compile in other Lisps but this is a special case where you
> have to
> make sure that stuff is defined in some way. You need to add directives to
> tell the compiler that this stuff will exist later and that it can safely
> refer to it.
>
> On the JVM, some underlying byte code has to be generated for any forms
> typed in the REPL at the top level any reference has to be defined before
> hand.
>
> There's no other way to generate byte code... there cannot be black holes
> waiting to get filled later.
>
> Hence the "compilation" phase and the restriction
> that stuff you refer to are to be defined either directly or using declare.
>
> Hope it explains the compromise.
>
> Luc P.
>
>
> > 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.
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VUWTAwOEHS0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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.

Re: Clojure Office Hours

[Jakub Holy]

Hi Leif,

This is a great activity, thank you for contributing to the community this 
way!

Do not be surprise and discouraged by the fact that the interest seems low. 
I have a similar experience - in my company we can consult with an 
"industry hero" yet people use the opportunity seldom, presumably because 
of multiple factors: they (wrongly) don't feel that they do not have 
something important/interesting enough to bother him, they are little 
scared of talking to and exposing themselves and their work to this 
experienced guy, and might find it difficult to explain their challenge to 
an outsider and get an advice within the limited time scope. On the other 
hand, those who dare to use the opportunity benefit from it greatly.

Good luck, Jakub 

On Friday, April 11, 2014 4:13:18 AM UTC+2, Leif wrote:
>
> Hmm... less interest than I'd expected, given recent posts.  Maybe I 
> should rename the thread to "Free Clojure Consulting / Tutoring."  
> Tht's not spammy.
>
> FYI, all bookings are automatically confirmed, so don't fret if I don't 
> instantly respond.
>
> @Tim: Sounds good!  Of course, now I'll have to take some time this 
> weekend and try to actually understand Om. :)  (or maybe ?o_0? )
>
> --Leif
>
> On Thursday, April 10, 2014 9:56:37 AM UTC-4, frye wrote:
>>
>> Sounds great. I just sent a request. 
>>
>> Tim Washington 
>> Interruptsoftware.com  
>>
>>
>> On Thu, Apr 10, 2014 at 9:43 AM, Colin Fleming wrote:
>>
>>> Hi Leif,
>>>
>>> This sounds like a very interesting project, please report back and let 
>>> us know how it went! I'd be very interested to know.
>>>
>>> Cheers,
>>> Colin
>>>
>>>
>>> On 11 April 2014 00:53, Leif  wrote:
>>>
 Hi, everybody.  Inspired by the SF Bay Area clojure group, 
 ClojureBridge, and the great talks on community education from 
 Clojure/West 
 on youtube, I've decided to try holding my own personal Clojure office 
 hours (online).

 I am personally of the opinion that face-to-face interaction is 
 superior, so you may want to get your local user group to follow the Bay 
 Area's lead.  But if you don't agree, or you don't live near such a user 
 group, then read on.

 Borrowed from the Bay Area's posting:

 "This is a [2-person] meetup for anyone who is working on a Clojure 
 project and wants to talk over their code or approach with an experienced 
 Clojure developer.

 Projects of all levels and complexity are welcome, anyone just getting 
 started in Clojure is encouraged to come in and talk through their first 
 Euler or 4Clojure problems."
 Disclaimer: This community being what it is, there may be projects of 
 too high a complexity for me, but I'll give it a shot.

 I'm going to try a test run of this for two weeks, and then I'll have 
 to see what state I'm in (mentally and geographically).  If interested, 
 you 
 can book at this link:

 https://leifpoorman.youcanbook.me/

 Note: all the times are evening, US Eastern.  That pretty much limits 
 it to the western hemisphere and any east asian friends that want to do 
 some morning hacking.  Eastern hemisphere friends, make noise on this 
 thread, and maybe some brave European/Asian clojure developer will try 
 something similar.

 Cheers,
 Leif


>>

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

[Softaddicts]

Ahem :)

a) The fn x does not exist in the universe until you call foo, hence you cannot
expect the compiler to known anything about it if it's not called before 
making any reference to x. 

b) If you refer to x at the top level (the "universe" above :) before defining
it, obviously it does not exist. You might use (declare x) before 
referring to it. This allows you to define it later at your convenience.

c) In general, you should avoid using def/defn within a function.
Macros may do that but this is a different story.

d) Yes code at the top level is executed, how can you expect
the REPL to work interactively if forms are not evaluated first ?
A defn expands to a function call, a special form in fact but it still 
behaves
like a function. Any function call at top level will get executed after 
being
compiled to byte code.

Now about the "compilation" step...

Traditionally, most Lisps allow you to refer to stuff in interpreted mode
not defined yet hoping that it will get defined by the time you run the code
that refers to these undefined things. It can even be something transient on
the stack... oups...

You can still compile in other Lisps but this is a special case where you have 
to
make sure that stuff is defined in some way. You need to add directives to
tell the compiler that this stuff will exist later and that it can safely refer 
to it.

On the JVM, some underlying byte code has to be generated for any forms
typed in the REPL at the top level any reference has to be defined before hand. 

There's no other way to generate byte code... there cannot be black holes
waiting to get filled later.

Hence the "compilation" phase and the restriction
that stuff you refer to are to be defined either directly or using declare.

Hope it explains the compromise.

Luc P.


> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

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

[Colin Yates]

Multimethods are fantastic and do indeed work across namespaces if by 
"across namespaces" you mean you can defmethod in ns2 a defmulti in ns1.

On Tuesday, April 15, 2014 2:56:30 AM UTC+1, Andrew Chambers wrote:
>
> 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: Helping newcomers get involved in Clojure projects

[kurofune]

For what it's worth, I would like to see a codecademy.com type site but for 
Clojure that can take you from 0 to hero, in one place, with interactive tracks 
depending on subject (i.e. Web-Dev, core functions, key libraries, idioms, 
regex, encryption, etc.). Something like an interactive SICP to teach core 
programming concepts but using Clojure would be nice. 4clojure has cool 
problems but they don't teach you to program. 

The best resources I've utilized are "Clojure in Action" and "Web Development 
with Clojure". Clojure from the Ground up and Clojure for the Brave and true 
were also good. The problem with the books is that the libs/APIs you learn in 
the tutorials are often deprecated or abandoned by the community for the next 
hot thing, by the time you even pick them up. One, open source, Community 
maintained user friendly resource with "batteries included" would be awesome. 

By and large community support has been good for me and I am often assisted by 
the very dude who wrote the book I'm working through. How can I complain about 
that?  This is simply awesome and I hope that stays possible in the future. 

I would really like a mentor.  Any programs that provide this would make the 
Clojure community stand out as friendly and welcoming, compared to other 
languages. This is just my two cents. Hope it is useful.

Jesse

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

[kurofune]

For what it's worth, I would like to see a codecademy.com type site but for 
Clojure that can take you from 0 to hero, in one place, with interactive tracks 
depending on subject (i.e. Web-Dev, core functions, key libraries, idioms, 
regex, encryption, etc.). Something like an interactive SICP to teach core 
programming concepts but using Clojure would be nice. 4clojure has cool 
problems but they don't teach you to program. 

The best resources I've utilized are "Clojure in Action" and "Web Development 
with Clojure". Clojure from the Ground up and Clojure for the Brave and true 
were also good. The problem with the books is that the libs/APIs you learn in 
the tutorials are often deprecated or abandoned by the community for the next 
hot thing, by the time you even pick them up. One, open source, Community 
maintained user friendly resource with "batteries included" would be awesome. 

By and large community support has been good for me and I am often assisted by 
the very dude who wrote the book I'm working through. How can I complain about 
that?  This is simply awesome and I hope that stays possible in the future. 

I would really like a mentor.  Any programs that provide this would make the 
Clojure community stand out as friendly and welcoming, compared to other 
languages. This is just my two cents. Hope it is useful.

Jesse

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