Re: Clojure as first language

[Daniel Kersten]

In my experience running the local clojure user group, a lot of clojure
beginners (NOT programming beginners) struggle with two things: the
paradigm switch (immutable data etc) and clojure's error messages.

I think if a beginner to programming started with clojure, they may be able
to sidestep the paradigm switch (because they haven't yet learned any
alternative approaches), but would struggle even more with the error
messages. Java stack traces are rather daunting at the best of times, but I
can imagine a beginner seeing something cryptic like wrong arity followed
by a 20 line stack trace would be rather demoralising.

Since this is a problem even seasoned programmers (but new to clojure)
have, I feel this needs to be improved before I'd be comfortable
recommending the language to absolute programming beginners.

Beyond that, as long as you introduce the concepts one at a time (should be
relatively easy, since clojure is all about untangling the various
concepts), then I think clojure would make a pretty interesting language to
teach programming with. When I tutored first year CS students in the past,
the biggest issue was introducing too much at once, but I feel that most of
clojure can be drip-fed as needed.
On Mon 22 Feb 2016 at 07:55 Michael Sperber  wrote:

>
> Terje Dahl  writes:
>
> > I believe that the simplicity of Clojure's syntax in combination with its
> > clean functional nature and prefix notation makes it ideal as a "first
> > language" for anyone who wants to start programming - including, and
> > perhaps especially kids.
>
> There's a lot of research out of the PLT and DeinProgramm projects on
> this. You'll find the relevant ones here:
>
> http://deinprogramm.de/publications.html
>
> These are not about Clojure per se, but discuss Scheme, which is close
> enough.
>
> tl;dr: No, Clojure is not an ideal language for teaching beginners.  For
> teaching beginners, you should use a language specifically engineered
> for beginners, such as the teaching languages that come with Racket.
> (The transition to Clojure from these languages should be quite easy,
> though.)
>
> --
> Regards,
> Mike
>
> --
> 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: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

[Thomas Heller]

Projects for this already exist but are somewhat dormant.

See:
https://github.com/clojure/tools.analyzer
https://github.com/clojure/tools.analyzer.jvm
https://github.com/clojure/tools.analyzer.js
https://github.com/clojure/tools.analyzer.clr
https://github.com/clojure/tools.emitter.jvm

Neither Clojure or ClojureScript currently use them since they are either 
incomplete or have performance issues compared to the default 
implementation. The idea was however to have a pluggable solution that can 
share as much code as possible. IIRC it all started as GSoC work, so it 
might be useful to continue in this way. I'm not sure who was involved but 
authors are still around I think.

Cheers,
/thomas



On Sunday, February 21, 2016 at 9:20:18 AM UTC+1, Edward Knyshov wrote:
>
>
>
> *Pluggable back-ends architecture for ClojureScript compilerBrief 
> explanation:* There are a lot of ClojureScript script compiler forks 
> exist to provide different compilation targets other than js. Most of them 
> are currently stuck because of rapid ClojureScript development and 
> difficulties with keeping fork in sync with upstream. We could consider 
> refactoring ClojureScript to provide plugable backends architecture, 
> specifically to allow users replace code generation stage of compiler and 
> implement js generator as one of such backends.
>  
> *Expected results: *ClojureScript compiler is refactored to allow further 
> active development of plenty other backends to bootstrap Clojure in such 
> environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to use 
> clojure mostly everywhere.
>  
> *Knowledge:* ClojureScript, Clojure, JavaScript
>
> Need to know, what do you think guys.
>

-- 
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 as first language

[Mark Engelberg]

Racket is a language that is explicitly designed for creating other
languages.  DrRacket is a remarkable pedagogical IDE.  For those who are
interested in providing a smooth learning path to Clojure, one of the best
ways to do that would be for our community to invest some effort in
building a "Clojure language mode" for DrRacket.  It wouldn't have to be
incredibly efficient, and wouldn't have to support the full range of
Clojure constructs, just a nice pedagogical subset of Clojure.

Racket-implemented languages interoperate with each other and with the IDE,
so beginning programmers could use DrRacket and get great error messages
and graphical stack traces in the IDE, as well as access to all its great
teachpack libraries (such as the functional graphics/animation library) and
the ability to use the various curricula designed by the PLT group.

The transition from Racket to Clojure already is fairly small, but this
way, beginners could then work through a tried-and-true curriculum using
Cloure syntax for a truly seamless transition to full-blown Clojure once
they are ready.

I believe this would be *far* easier and more useful than trying to build a
robust set of features for beginner programmers into Clojure (given that
the DrRacket team has already spent decades on this problem, so we're
better off figuring out how to leverage their work than trying to reinvent
and reimplement 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.

Re: Clojure as first language

[Lee Spector]

When I taught with DrScheme back in the day it was a very good experience 
overall, and while I haven't taught with DrRacket I understand that the team 
has continued to do great things, and that this is probably a perfect first 
environment for many teaching contexts. FWIW in my context the restricted 
language subsets were more of a hinderance than a help, but since we could get 
around them, and since everything else about the environment was so nice, I was 
quite happy with the experience overall.

But I nonetheless think that actual Clojure can also be a great first language. 
Although it would take a *lot* work to do all of the things that the PLT/Racket 
people have done, I think that we're already on the cusp of having sufficiently 
good Clojure environments for beginners. For me, I think we'll be over the 
threshold for teaching Clojure as a first language as soon as the "quick real 
start" story gets a little better, making it trivial for total newbies to set 
up an environment and start coding, with a few essential features like 
auto-re-indenting and as few unnecessary sources of confusion as possible. Once 
we're over that threshold (and many projects are quite close, but not yet quite 
there IMHO) I think that Clojure-first will be a reasonable path, and that 
things will then get even better as the work that people are doing on improved 
error messages etc. can be incorporated. 

So I hope that Clojure tool developers will continue to push in this direction 
too! 

 -Lee

PS if anyone is curious about how I've been using just lein + Gorilla REPL as a 
teaching environment, which I mentioned earlier, you might want to look at my 
brief notes at 
http://faculty.hampshire.edu/lspector/temp/Secrets-of-Gorilla-REPL.pdf. Note 
that this is still missing one key feature for more general use: Save Without 
Markup. Right now, any edited file will be "polluted" with markup, which would 
obviously be problematic in many situations. A student in my group is looking 
into adding this feature.


> On Feb 22, 2016, at 8:34 AM, Mark Engelberg  wrote:
> 
> Racket is a language that is explicitly designed for creating other 
> languages.  DrRacket is a remarkable pedagogical IDE.  For those who are 
> interested in providing a smooth learning path to Clojure, one of the best 
> ways to do that would be for our community to invest some effort in building 
> a "Clojure language mode" for DrRacket.  It wouldn't have to be incredibly 
> efficient, and wouldn't have to support the full range of Clojure constructs, 
> just a nice pedagogical subset of Clojure.
> 
> Racket-implemented languages interoperate with each other and with the IDE, 
> so beginning programmers could use DrRacket and get great error messages and 
> graphical stack traces in the IDE, as well as access to all its great 
> teachpack libraries (such as the functional graphics/animation library) and 
> the ability to use the various curricula designed by the PLT group.
> 
> The transition from Racket to Clojure already is fairly small, but this way, 
> beginners could then work through a tried-and-true curriculum using Cloure 
> syntax for a truly seamless transition to full-blown Clojure once they are 
> ready.
> 
> I believe this would be far easier and more useful than trying to build a 
> robust set of features for beginner programmers into Clojure (given that the 
> DrRacket team has already spent decades on this problem, so we're better off 
> figuring out how to leverage their work than trying to reinvent and 
> reimplement it).
> 

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

clojure as part of agnostic project

[Kendall Shaw]

Generally, I try to not make projects depend on a specific build 
environment. So, for example, a directory structure containing java file 
and configuration files can exist independent of the build environment. 
The reason being that the future is sometimes different from the past 
and in the future a different build environment might be appropriate. 
Checking out some code and finding that you have to go find a copy of 
IBM VisualBefunge to do anything is not good.


So, how are people including clojure in projects without requiring the 
use of leiningen/boot and preferably allowing the use of leiningen/boot 
at the same time?


Kendall

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

[DOCS] clojure.org Feb update

[Alex Miller]

I've been meaning to do an update on clojure.org, now that it's been a 
little over a month since we switched over to the new site.

I'm very happy with everything I've seen on the operational side - the 
Clojure web site has had much less down time than the old host, is serving 
the site much faster, and has generally made things far easier to manage. 
We've had a few spiky days where traffic was about double the normal and my 
only knowledge of that was in noticing it in the stats after the fact, 
rather than alarms going off. :)

Bigger changes since initial deploy (see commits for gory details):
- We now support https and are serving about 1/3 of our traffic now via 
https
- Added robots.txt and bumped the Google indexer to look at our sitemap - 
thanks Daniel Compton
- Added many contributors 
- Added many companies  (ping me if 
you want to be added, or send a PR if you're a contributor)
- Added many events  (many already 
over!)
- Added more books  - thanks aadrian on 
github
- Added more resources , 
particularly video training - thanks aadrian on github
- Updated cheatsheet  - thanks Andy 
Fingerhut
- Added contrib library descriptions  - 
thanks ZhiFeng Hu
- Added comparators  guide - thanks 
Andy Fingerhut and Jose Donizetti
- Added reader conditionals  
guide - thanks Daniel Compton
- Added threading macros  guide 
- thanks Paulus Esterhazy
- Updated latest Clojure release from 1.7 to 1.8, added docs on socket 
server 
 and 
direct 
linking 
- Periodically moving older news items from the old clojure.com blog (which 
is deprecated and moving towards decommissioning) into the news area
- Closed 26 PRs and 30 issues

The clojure.org site is open for contributions and there are lots of ways 
you could help if you want to add content. There are a number of requests 
for open content 

 
if someone is interested. For more on contributing to the site, see: 
http://clojure.org/community/contributing_site.


-- 
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 as part of agnostic project

[James Reeves]

At minimum, both Boot and Leiningen just need to be told where you store
your source files. By default this is "src", so a project with a "src"
directory would work with both build tools, and likely any new ones that
pop up in future.

However, this doesn't solve the problem of how to resolve dependencies.
Without a build tool, where will you store the dependencies your project
requires? You might as well just pick a build tool and use it, and if
people for some reason want to use a different tool they can copy the
dependencies from project.clj to build.boot or vice versa.

- James

On 22 February 2016 at 15:57, Kendall Shaw  wrote:

> Generally, I try to not make projects depend on a specific build
> environment. So, for example, a directory structure containing java file
> and configuration files can exist independent of the build environment. The
> reason being that the future is sometimes different from the past and in
> the future a different build environment might be appropriate. Checking out
> some code and finding that you have to go find a copy of IBM VisualBefunge
> to do anything is not good.
>
> So, how are people including clojure in projects without requiring the use
> of leiningen/boot and preferably allowing the use of leiningen/boot at the
> same time?
>
> Kendall
>
> --
> 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 as part of agnostic project

[Timothy Baldridge]

And since both boot and lein store projects in a human readable format
(aka. not machine generated XML), moving from one of these to another
project manager shouldn't be too hard.

On Mon, Feb 22, 2016 at 9:16 AM, James Reeves  wrote:

> At minimum, both Boot and Leiningen just need to be told where you store
> your source files. By default this is "src", so a project with a "src"
> directory would work with both build tools, and likely any new ones that
> pop up in future.
>
> However, this doesn't solve the problem of how to resolve dependencies.
> Without a build tool, where will you store the dependencies your project
> requires? You might as well just pick a build tool and use it, and if
> people for some reason want to use a different tool they can copy the
> dependencies from project.clj to build.boot or vice versa.
>
> - James
>
> On 22 February 2016 at 15:57, Kendall Shaw  wrote:
>
>> Generally, I try to not make projects depend on a specific build
>> environment. So, for example, a directory structure containing java file
>> and configuration files can exist independent of the build environment. The
>> reason being that the future is sometimes different from the past and in
>> the future a different build environment might be appropriate. Checking out
>> some code and finding that you have to go find a copy of IBM VisualBefunge
>> to do anything is not good.
>>
>> So, how are people including clojure in projects without requiring the
>> use of leiningen/boot and preferably allowing the use of leiningen/boot at
>> the same time?
>>
>> Kendall
>>
>> --
>> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

[Zach Oakes]

Yeah I forgot about tools.analyzer. Maybe just updating its JS emitter to 
work with the latest ClojureScript would be a good project. It still 
wouldn't solve the issue of keeping up with the latest ClojureScript 
releases, but it seems like it would be a decent scope for a GSoC project.

On Monday, February 22, 2016 at 5:57:57 AM UTC-5, Thomas Heller wrote:
>
> Projects for this already exist but are somewhat dormant.
>
> See:
> https://github.com/clojure/tools.analyzer
> https://github.com/clojure/tools.analyzer.jvm
> https://github.com/clojure/tools.analyzer.js
> https://github.com/clojure/tools.analyzer.clr
> https://github.com/clojure/tools.emitter.jvm
>
> Neither Clojure or ClojureScript currently use them since they are either 
> incomplete or have performance issues compared to the default 
> implementation. The idea was however to have a pluggable solution that can 
> share as much code as possible. IIRC it all started as GSoC work, so it 
> might be useful to continue in this way. I'm not sure who was involved but 
> authors are still around I think.
>
> Cheers,
> /thomas
>
>
>
> On Sunday, February 21, 2016 at 9:20:18 AM UTC+1, Edward Knyshov wrote:
>>
>>
>>
>> *Pluggable back-ends architecture for ClojureScript compilerBrief 
>> explanation:* There are a lot of ClojureScript script compiler forks 
>> exist to provide different compilation targets other than js. Most of them 
>> are currently stuck because of rapid ClojureScript development and 
>> difficulties with keeping fork in sync with upstream. We could consider 
>> refactoring ClojureScript to provide plugable backends architecture, 
>> specifically to allow users replace code generation stage of compiler and 
>> implement js generator as one of such backends.
>>  
>> *Expected results: *ClojureScript compiler is refactored to allow 
>> further active development of plenty other backends to bootstrap Clojure in 
>> such environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to 
>> use clojure mostly everywhere.
>>  
>> *Knowledge:* ClojureScript, Clojure, JavaScript
>>
>> Need to know, what do you think guys.
>>
>

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

[Help] core.async and jetty

[Miguel Ping]

Hi guys,

I'm trying to replicate an experiment on nodejs and http pipelining: 
http://blog.yld.io/2016/02/08/squeeze-the-juice-out-of-node/

This is what I got right now: 
https://gist.github.com/mping/98bb8eb9faf3c51f9889 (using 
*com.ninjudd/ring-async*)

Problem is I can't get pipelining to work as in nodejs; by doing two reqs 
they are sequential, ie, the dates that I'm printing have two secs.
Basically I want that the server prints two "identical" accpt dates, and 
the  response should show that (now not working):

$ tail -f reqs.txt | nc 127.0.0.1  


HTTP/1.1 200 OK
Date: Mon, 22 Feb 2016 20:29:10 GMT
Transfer-Encoding: chunked
Server: Jetty(7.6.8.v20121106)

48
id: 1, uri: /a
Mon Feb 22 20:29:10 WET 2016
Mon Feb 22 20:29:12 WET 2016
0

HTTP/1.1 200 OK
Date: Mon, 22 Feb 2016 20:29:12 GMT
Transfer-Encoding: chunked
Server: Jetty(7.6.8.v20121106)

48
id: 2, uri: /b
Mon Feb 22 20:29:12 WET 2016
Mon Feb 22 20:29:14 WET 2016


I'm guessing that this is either my mistake with core.async or the adapter.

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: [Help] core.async and jetty

[Miguel Ping]

By the way, I can see that jetty is reusing the same HttpInput instance on 
the request (most probably because of pipelining)

On Monday, February 22, 2016 at 8:33:37 PM UTC, Miguel Ping wrote:
>
> Hi guys,
>
> I'm trying to replicate an experiment on nodejs and http pipelining: 
> http://blog.yld.io/2016/02/08/squeeze-the-juice-out-of-node/
>
> This is what I got right now: 
> https://gist.github.com/mping/98bb8eb9faf3c51f9889 (using 
> *com.ninjudd/ring-async*)
>
> Problem is I can't get pipelining to work as in nodejs; by doing two reqs 
> they are sequential, ie, the dates that I'm printing have two secs.
> Basically I want that the server prints two "identical" accpt dates, and 
> the  response should show that (now not working):
>
> $ tail -f reqs.txt | nc 127.0.0.1  
> 
> 
> HTTP/1.1 200 OK
> Date: Mon, 22 Feb 2016 20:29:10 GMT
> Transfer-Encoding: chunked
> Server: Jetty(7.6.8.v20121106)
>
> 48
> id: 1, uri: /a
> Mon Feb 22 20:29:10 WET 2016
> Mon Feb 22 20:29:12 WET 2016
> 0
>
> HTTP/1.1 200 OK
> Date: Mon, 22 Feb 2016 20:29:12 GMT
> Transfer-Encoding: chunked
> Server: Jetty(7.6.8.v20121106)
>
> 48
> id: 2, uri: /b
> Mon Feb 22 20:29:12 WET 2016
> Mon Feb 22 20:29:14 WET 2016
>
>
> I'm guessing that this is either my mistake with core.async or the adapter.
>
> 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 as first language

[Matching Socks]

Zach Oakes gave a bracing talk about Clojure-as-a-first-language, 
unpedantically entitled "Making Games at Runtime with Clojure", at the 2014 
Clojure conj. 

https://www.youtube.com/watch?v=0GzzFeS5cMc

-- 
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: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

[Antonin Hildebrand]

I like the idea.

I was thinking about a similar project. The goal would be to design and 
implement user-configurable, pluggable system for "jacking" into 
ClojureScript compilation pipeline as discussed here[1].

The first dog-fooding application could be instrumentation middleware for 
collecting code-coverage information. I believe this could be implemented 
by rewriting forms between reader and analyzer. Or instrumenting AST output 
from analyzer before it gets passed to emit-phase.

just my 2cents,
Antonin

[1] http://blog.fogus.me/2012/04/25/the-clojurescript-compilation-pipeline/


On Sunday, February 21, 2016 at 9:20:18 AM UTC+1, Edward Knyshov wrote:
>
>
>
> *Pluggable back-ends architecture for ClojureScript compilerBrief 
> explanation:* There are a lot of ClojureScript script compiler forks 
> exist to provide different compilation targets other than js. Most of them 
> are currently stuck because of rapid ClojureScript development and 
> difficulties with keeping fork in sync with upstream. We could consider 
> refactoring ClojureScript to provide plugable backends architecture, 
> specifically to allow users replace code generation stage of compiler and 
> implement js generator as one of such backends.
>  
> *Expected results: *ClojureScript compiler is refactored to allow further 
> active development of plenty other backends to bootstrap Clojure in such 
> environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to use 
> clojure mostly everywhere.
>  
> *Knowledge:* ClojureScript, Clojure, JavaScript
>
> Need to know, what do you think guys.
>

-- 
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 as first language

[Daniel]

> I heard feedback about a guy who learned to program in Clojure and found 
> Python pretty messed up afterwards.

If love to read this if you can dig up a link.

-- 
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: unable to understand the behaviour of core.matrix/emap ( Bug maybe? )

[Mikera]

Yeah, confirmed this is a bug in vectorz-clj. Indexing error meant that the 
operator was getting applied to the first row twice, instead of once to 
each row.

There is a fix and regression tests in the develop branch already, will be 
fixed in next release (hopefully today if I have time)

On Friday, 19 February 2016 08:11:17 UTC+8, Sunil Nandihalli wrote:
>
> Hi Everybody
>  There seems to be a problem with core.matrix/emap implementation for 
> vectorz implementation
>
> sunil@peacock:~/work/wnmf/clj/wnmf$ lein repl
> Clojure 1.8.0
> wnmf.core=> (def t (m/array [[10] [20]]))
> #'wnmf.core/t
> wnmf.core=> (m/pm t)
> [[10.000]
>  [20.000]]
> nil
> wnmf.core=> (m/pm (m/emap / t 10))
> [[ 0.100]
>  [20.000]]
> nil
> wnmf.core=>
>
> can somebody please clarify this?
> Thanks,
> Sunil.
>

-- 
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: unable to understand the behaviour of core.matrix/emap ( Bug maybe? )

[Sunil S Nandihalli]

Thanks Mikera, Looking forward to the release.
Regards,
Sunil.

On Tue, Feb 23, 2016 at 12:31 PM, Mikera 
wrote:

> Yeah, confirmed this is a bug in vectorz-clj. Indexing error meant that
> the operator was getting applied to the first row twice, instead of once to
> each row.
>
> There is a fix and regression tests in the develop branch already, will be
> fixed in next release (hopefully today if I have time)
>
>
> On Friday, 19 February 2016 08:11:17 UTC+8, Sunil Nandihalli wrote:
>>
>> Hi Everybody
>>  There seems to be a problem with core.matrix/emap implementation for
>> vectorz implementation
>>
>> sunil@peacock:~/work/wnmf/clj/wnmf$ lein repl
>> Clojure 1.8.0
>> wnmf.core=> (def t (m/array [[10] [20]]))
>> #'wnmf.core/t
>> wnmf.core=> (m/pm t)
>> [[10.000]
>>  [20.000]]
>> nil
>> wnmf.core=> (m/pm (m/emap / t 10))
>> [[ 0.100]
>>  [20.000]]
>> nil
>> wnmf.core=>
>>
>> can somebody please clarify this?
>> Thanks,
>> Sunil.
>>
> --
> 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.