Re: how do I get primitive typ hints to appear in the output of a macro?

[john]

yes that's the reason thank you very much!
Meikel also pointed me in that direction with ; (meta (first (nth 
(macroexpand-1 '(aTest)) 2))) => {:tag long} and on ihis blog
*http://kotka.de/blog/2009/12/with-meta_and_the_reader.html*
 which 
has been very helpful
Many Thanx 
Am Donnerstag, 19. Juli 2012 05:49:02 UTC+2 schrieb dgrnbrg:

> I don't think that the type hint will appear in the printed output. It is 
> metadata, so it won't be shown by the printer. If you try (let [[_ _ [b] 
> (macroexpand-1 '(aTest))] (meta b)) you should see {:tag long}.
>
> On Wednesday, July 18, 2012 7:55:31 AM UTC-4, john wrote:
>>
>> Hello,
>> how do I get primitive typ hints to appear in the output of a macro?
>>  
>> like :
>> (defmacro aTest []
>>   `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))
>>
>> (macroexpand-1 '(aTest))
>> yields :
>>
>> (aFun 7)
>> (macroexpand-1 '(aTest))
>> yields :
>>  
>> (defn aFun [b] (clojure.core/meta b))
>>  
>> but I wold like it to be :
>> (defn aFun [^long b] (clojure.core/meta b))
>>  
>> Many greetings
>> John
>>
>>  
>>
>

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

Re: how do I get primitive typ hints to appear in the output of a macro?

[dgrnbrg]

I don't think that the type hint will appear in the printed output. It is 
metadata, so it won't be shown by the printer. If you try (let [[_ _ [b] 
(macroexpand-1 '(aTest))] (meta b)) you should see {:tag long}.

On Wednesday, July 18, 2012 7:55:31 AM UTC-4, john wrote:
>
> Hello,
> how do I get primitive typ hints to appear in the output of a macro?
>  
> like :
> (defmacro aTest []
>   `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))
>
> (macroexpand-1 '(aTest))
> yields :
>
> (aFun 7)
> (macroexpand-1 '(aTest))
> yields :
>  
> (defn aFun [b] (clojure.core/meta b))
>  
> but I wold like it to be :
> (defn aFun [^long b] (clojure.core/meta b))
>  
> Many greetings
> John
>
>  
>

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

Can you make Amotoen faster?

[Richard Lyman]

All,

There's not much code, and (sadly) not much documentation, but what's
there needs some performance love.

https://github.com/richard-lyman/amotoen

Notes:
 - jvisualvm doesn't like me this week so help there might be enough
(I can't see anything other than clojure classes - I'd love to only
see my code)
 - reifying IPosition to a faster implementation seems like it has potential
 - I've used *warn-on-reflection* and fixed the single spot it mentioned
 - I'm not convinced that the code used in 'either' is the best, and
I'm a bit confused about why it's better than the two other
commented-out forms
 - Switching IPosition grammar-grammar away from a character-based
approach is an option, just one I'd like to avoid

It's a leiningen project, with 'lein test' being what I run to check
performance. The grammar parses itself 40 times and prints out how
long that took. The self-check method might be a good place to start
if walking through the code. Ignore the grammar samples, they haven't
been updated in a while. Basically the two 'core' files, under src and
test are all I'm working with right now.

Is it already as 'fast' as it can be??

-Rich

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

Re: atom and lock

[Softaddicts]

With multiple CPUs, for costs and design complexity reasons, coordination uses
 test and set instructions in shared memory.

When the bit is set, other contenders can either try latter or enter a spin loop
(spin lock) retrying the operation until it succeeds.

Implementing complex hardware atomic instructions coordinated between all CPUs
was the norm before RISC chips came out.

Simulation proved that this approach was too slow given the speed boost
of RISC chips, memory access speed was impaired when implementing
complex coordination between all CPUs and RISC chips were spending
too much time waiting for the memory subsystem to keep the pace.

>From then on, test and set shared memory became the norm.

Luc P.

> 
> It's not. Locks are created by using CAS, not the other way around. 
> 
> > On a x86 machine the swap basically compiles down to a single assembly 
> > code instruction: 
> >
> > http://jsimlo.sk/docs/cpu/index.php/cmpxchg.html 
> >
> > On a normal x86 machine, every lock in the system will boil down to 
> > using this single instruction. x86 has no concept of "locks". Locks 
> > are simply a construct created by the operating system that is 
> > implemented with a series of cmpxchg instructions. This is the reason 
> > this instruction exists in the first place. Every type of 
> > lock/semephore/mutex we need in a operating system can be built off of 
> > this single instruction. This is also why Clojure includes atoms. 
> >
> >
> >
> Ok. Now I understand. So atom wants to take advantage of this hardware high 
> efficiency CAS. Then I agree if the load is not high, atom will be faster 
> than locking. Thanks for pointing this out.
> 
> Now I got a broader question, why CAS is hardware supported, but lock is 
> not (i.e., why it is not the other way around)? I used to work on some 
> firmware, and we have hardware mutex. Why this is not generally the case 
> for general purpose CPUs?
> 
> -- 
> 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
--
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

Re: atom and lock

[Timothy Baldridge]

> Now I got a broader question, why CAS is hardware supported, but lock is not
> (i.e., why it is not the other way around)? I used to work on some firmware,
> and we have hardware mutex. Why this is not generally the case for general
> purpose CPUs?

There's several issues at work here, I'll try to cover them, but this
comes with a massive disclaimer I'm going to be radically
oversimplifying here.

Two factors at work here is the fact that modern CPUs have several
layers of caches (L3, L2, and L1 in most modern multi core CPUs).
Secondly, modern systems can have cores that share none or more of
these caches. So this all has to be handled in some way.

In addition, most systems only support loading memory in cache lines.
IIRC, today most cache lines are 16KB. So when you read a single byte,
the 16KB around that memory location is loaded as well.

So, when you do a swap in a x86, it first tells all other cores in the
system to flush their cache lines that correspond with the memory
location the swap is about to happen on. This will cause these CPUs to
lock if they attempt to read from that cache line. From there the core
is free to update the cache line and write it out to memory, and then
finally release it back to the other CPUs.

If this all sounds expensive, it really is. Part of this too is that
CPUs buffer reads/writes in queues, before a swap the pending
reads/writes must be flushed. Frankly I'm amazed that CAS works as
well as it does.

So there's a odd side-effect here. Notice how it locks a whole cache
line (16KB)? This means that if you allocated 4K atoms from the same
cache line, swapping one would cause the others to lock during the
CAS.

You can probably imagine how bad this would all get if we were allowed
to just randomly start and stop locks.

So yeah, there it is, simplified (and probably partly wrong). Hope
that helps ;-)

Timothy

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

Re: atom and lock

[Warren Lynn]

It's not. Locks are created by using CAS, not the other way around. 

> On a x86 machine the swap basically compiles down to a single assembly 
> code instruction: 
>
> http://jsimlo.sk/docs/cpu/index.php/cmpxchg.html 
>
> On a normal x86 machine, every lock in the system will boil down to 
> using this single instruction. x86 has no concept of "locks". Locks 
> are simply a construct created by the operating system that is 
> implemented with a series of cmpxchg instructions. This is the reason 
> this instruction exists in the first place. Every type of 
> lock/semephore/mutex we need in a operating system can be built off of 
> this single instruction. This is also why Clojure includes atoms. 
>
>
>
Ok. Now I understand. So atom wants to take advantage of this hardware high 
efficiency CAS. Then I agree if the load is not high, atom will be faster 
than locking. Thanks for pointing this out.

Now I got a broader question, why CAS is hardware supported, but lock is 
not (i.e., why it is not the other way around)? I used to work on some 
firmware, and we have hardware mutex. Why this is not generally the case 
for general purpose CPUs?

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

Re: Expanding the Community Through Online Courses

[mnicky]

Another one that comes into mind is SICP course [1] in Clojure. Given 
Clojure's similarity to Scheme it should be doable. Also, because the SICP 
book is now licensed under CC-BY-SA, there shouldn't be any copyright 
problems etc. IMO 

[1] http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

On Wednesday, July 18, 2012 7:44:52 PM UTC+2, Eduardo Bellani wrote:
>
> Great idea and great effort. I would be awesome if Norvig gave a class 
> based on his PAIP 
> book, using clojure or any other lisp beast. 
>
> On Wed, Jul 18, 2012 at 1:38 PM, Joshua Bowles  
> wrote: 
> > I've made a request to Udacity and forwarded Harrison Maseko's 
> suggestions 
> > in my request. 
> > 
> > I'm sure if enough people get behind this... 
> > 
> > 
> > On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles  
> > wrote: 
> >> 
> >> Peter Norvig's response: 
> >> 
> >> Possible ... Udacity would be more likely -- they seem to be more 
> >> skill-based whereas Coursera is more academic-based. 
> >> 
> >> 
> >> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles  
> >> wrote: 
> >>> 
> >>> I agree. My thinking with an AI class is that as LISP used to be 
> taught 
> >>> for AI in school, and most programs offer Java classes, there's got to 
> be a 
> >>> few Professors out there who really dig Clojure and have a good chance 
> >>> teaching it. I didn't propose a "functional programming" course 
> because they 
> >>> already have that with Scala (not to say they wouldn't offer another). 
> >>> 
> >>> As far as Udacity, Peter Norvig is somehow related with Udacity (not 
> sure 
> >>> what his role is), he's an old school LISPer and he's totally familiar 
> with 
> >>> Java. I don't know if he's into Clojure (but he's definitely not 
> against the 
> >>> idea of LISP running on JVM --- he wrote is own version a while back 
> with 
> >>> scheme http://norvig.com/jscheme.html). I'll email him and see if 
> he's 
> >>> interested. 
> >>> 
> >>> 
> >>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko  
> >>> wrote: 
>  
>  That sounds like a good move, if a professor at some at one of those 
>  Coursera linked universities would be willing to do that. However, 
> can the 
>  same request be sent to Udacity? Also, is AI the only practical 
> course to 
>  suggest? I would like to suggest to Udacity, "Introduction to 
> Functional 
>  Programming." Another course I would suggest is, "Building a Dynamic 
>  Contacts Application for the Cloud," and the third one would be "Game 
>  Development in Clojure" or something more focused like "Fluid 
> Dynamics for 
>  Game Development." All these could use Clojure. 
>  -h. 
>  
>  
>  On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote: 
> > 
> > Yes! Just this morning (before reading this thread) I emailed 
> Coursera 
> > to request a course like "Artificial Intelligence in Clojure". I 
> posted on a 
> > separate thread here ("community interest in machine learning(?)") 
> that I 
> > had made the request and provided a link for anyone else who wanted 
> to make 
> > a request: 
> >  http://help.coursera.org/customer/portal/emails/new 
> > 
> > 
> > On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko  
> > wrote: 
> >> 
> >> Hi Yann, 
> >> I agree that Udacity is more approachable in this regard than 
> >> Coursera. But imagine the publicity the language would get if such 
> a massive 
> >> audience were given exposure to Clojure and Clojurescript. I have 
> always 
> >> believed that a subset of Clojure (or any Lisp) could be taught 
> even to 
> >> programming beginners with ease. This in turn could dispel much of 
> the myths 
> >> surrounding Lisp-based languages to thousands at once (one of which 
> is 'Lisp 
> >> is difficult.' Simple as it may sound, it has deterred many from 
> even 
> >> peering into a Lisp). However, with a platform like Udacity, the 
> instructor 
> >> is at liberty to really explain in a newbie-friendly way the 
> elegance and 
> >> power of a language such as Clojure. The brief lesson videos would 
> perhaps 
> >> be a more navigable route to Clojure for some than reading a book. 
> All we 
> >> need is an attractive, *practical* topic (which can be suggested by 
> anyone 
> >> here), a reputable instructor, and a way of engaging Udacity 
> faculty about 
> >> our offer. And I wish that this process could begin sooner. 
> >> Thanks, 
> >> -h. 
> >> 
> >> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote: 
> >>> 
> >>> 
> >>> 
> >>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko  
>
> >>> wrote: 
>  
>  Hi All, 
>  Massive Open Online Courses (MOOC) such as the ones offered by 
>  Udacity, Coursera, and soon edX will eventually become platforms 
> from which 
>  a language can be showcased an

Re: atom and lock

[Timothy Baldridge]

> It's not. Locks are created by using CAS, not the other way around.
> On a x86 machine the swap basically compiles down to a single assembly
> code instruction:
>

Eh, let me clarify thatlocks do exist on x86, it's just that they
only lock a single assembly instruction. The complete list of
instructions that can be locked is here:

http://jsimlo.sk/docs/cpu/index.php/lock.html

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

Re: atom and lock

[Timothy Baldridge]

>> But consider swap! is already doing some kind of internal locking at commit 
>> time as I mentioned before
>> I assume even with STM style atom, some kind of lock is happening 
>> internally, for the final commit, because when committing,
>> you still need to coordinate the access to some state with other threads. 
>> Maybe it is not called a lock, but something similar.
>> So that same mechanism can be used to lock the whole swap! and should not 
>> increase any overhead.

It's not. Locks are created by using CAS, not the other way around.
On a x86 machine the swap basically compiles down to a single assembly
code instruction:

http://jsimlo.sk/docs/cpu/index.php/cmpxchg.html

On a normal x86 machine, every lock in the system will boil down to
using this single instruction. x86 has no concept of "locks". Locks
are simply a construct created by the operating system that is
implemented with a series of cmpxchg instructions. This is the reason
this instruction exists in the first place. Every type of
lock/semephore/mutex we need in a operating system can be built off of
this single instruction. This is also why Clojure includes atoms.

>> And that "apply" is slow too.

Atom's apply uses apply as well:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Atom.java


Plus, all these tests are worthless without introducing a few threads
into the mix:

user=>  (time (doall (pmap (fn [x] (dotimes [x 100] (lock-swap! a
(fn [o n] n) x))) (range 10
"Elapsed time: 5323.677006 msecs"
(nil nil nil nil nil nil nil nil nil nil)
user=>  (time (doall (pmap (fn [x] (dotimes [x 100] (swap! a (fn
[o n] n) x))) (range 10
"Elapsed time: 708.689155 msecs"
(nil nil nil nil nil nil nil nil nil nil)


Timothy

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

Re: Expanding the Community Through Online Courses

[Harrison Maseko]

Thanks, Joshua.

On Wednesday, July 18, 2012 6:38:10 PM UTC+2, Joshua Bowles wrote:
>
> I've made a request to Udacity and forwarded Harrison Maseko's suggestions 
> in my request.
>
> I'm sure if enough people get behind this...
>
> On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles wrote:
>
>> Peter Norvig's response:
>>
>> Possible ... Udacity would be more likely -- they seem to be more 
>> skill-based whereas Coursera is more academic-based.
>>
>>
>> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles wrote:
>>
>>> I agree. My thinking with an AI class is that as LISP used to be taught 
>>> for AI in school, and most programs offer Java classes, there's got to be a 
>>> few Professors out there who really dig Clojure and have a good chance 
>>> teaching it. I didn't propose a "functional programming" course because 
>>> they already have that with Scala (not to say they wouldn't offer another).
>>>
>>> As far as Udacity, Peter Norvig is somehow related with Udacity (not 
>>> sure what his role is), he's an old school LISPer and he's totally familiar 
>>> with Java. I don't know if he's into Clojure (but he's definitely not 
>>> against the idea of LISP running on JVM --- he wrote is own version a while 
>>> back with scheme http://norvig.com/jscheme.html). I'll email him and 
>>> see if he's interested.
>>>
>>>
>>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko wrote:
>>>
 That sounds like a good move, if a professor at some at one of those 
 Coursera linked universities would be willing to do that. However, can the 
 same request be sent to Udacity? Also, is AI the only practical course to 
 suggest? I would like to suggest to Udacity, "Introduction to Functional 
 Programming." Another course I would suggest is, "Building a Dynamic 
 Contacts Application for the Cloud," and the third one would be "Game 
 Development in Clojure" or something more focused like "Fluid Dynamics for 
 Game Development." All these could use Clojure.
 -h.


 On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>
> Yes! Just this morning (before reading this thread) I emailed Coursera 
> to request a course like "Artificial Intelligence in Clojure". I posted 
> on 
> a separate thread here ("community interest in machine learning(?)") that 
> I 
> had made the request and provided a link for anyone else who wanted to 
> make 
> a request: 
>  
> http://help.coursera.org/**customer/portal/emails/new
>
>
> On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko wrote:
>
>> Hi Yann,
>> I agree that Udacity is more approachable in this regard than 
>> Coursera. But imagine the publicity the language would get if such a 
>> massive audience were given exposure to Clojure and Clojurescript. I 
>> have 
>> always believed that a subset of Clojure (or any Lisp) could be taught 
>> even 
>> to programming beginners with ease. This in turn could dispel much of 
>> the 
>> myths surrounding Lisp-based languages to thousands at once (one of 
>> which 
>> is 'Lisp is difficult.' Simple as it may sound, it has deterred many 
>> from 
>> even peering into a Lisp). However, with a platform like Udacity, the 
>> instructor is at liberty to really explain in a newbie-friendly way the 
>> elegance and power of a language such as Clojure. The brief lesson 
>> videos 
>> would perhaps be a more navigable route to Clojure for some than reading 
>> a 
>> book. All we need is an attractive, *practical* topic (which can be 
>> suggested by anyone here), a reputable instructor, and a way of engaging 
>> Udacity faculty about our offer. And I wish that this process could 
>> begin 
>> sooner.
>> Thanks,
>> -h. 
>>
>> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>>>
>>>
>>>
>>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko 
>>> wrote:
>>>
 Hi All,
 Massive Open Online Courses (MOOC) such as the ones offered by 
 Udacity , Coursera, 
 and soon edX  will eventually become 
 platforms from which a language can be showcased and exposed to a very 
 wide 
 audience. Here are a few examples, all from 
 Coursera
 :

- Scala: Functional Programming Principles in 
 Scala.
- R:   Computing for Data 
 Analysis. 
- Python:   An Introduction to Interactive Programming In 
Python .
- C++/Java:   Compilers

Re: atom and lock

[Warren Lynn]

Thanks for the discussion This is not a reply to any particular post. Here 
is my thinking on the various points raised.

1. The length of the critical section is irrelevant in this discussion. 
Even with locks, people agree that the critical section should be as short 
as possible. So the limiting factor is the algorithm itself, with or 
without lock. 

2. I assume even with STM style atom, some kind of lock is happening 
internally, for the final commit, because when committing, you still need 
to coordinate the access to some state with other threads. Maybe it is not 
called a lock, but something similar. So that same mechanism can be used to 
lock the whole swap! and should not increase any overhead.

3. Is lock so expensive? Let's find out. tbc++ showed my implementation is 
much slower. That's true, because I want to have a separate type so there 
is no chance to mix swap! and lock-swap! on one object. And that "apply" is 
slow too. Let's have a more fair comparison by changing the original 
lock-swap! to this:

(defn lock-swap!
  [lock-atom f x]
  (locking lock-atom
(swap! lock-atom f x)))

user> (time (dotimes [x 100] (swap! a (fn [o n] n) x))) 
"Elapsed time: 41.417993 msecs"
nil
user> (time (dotimes [x 100] (lock-swap! a (fn [o n] n) x))) 
"Elapsed time: 136.342714 msecs"
nil

The difference is 3.3 times. But consider swap! is already doing some kind 
of internal locking at commit time as I mentioned before, I am doing 
(unnecessary) double-locking here, so the actual difference is less (maybe 
by half, if we assume fn [o n] is super fast). There might be more 
optimization room If we move the lock into the Clojure core. But the point 
is, lock is not that expensive at all here.

4. Some may argue that the STM style atom swap is not always better than 
lock style swap, but sometimes it is (the claim that it is not optimized 
for all use cases). Given lock is not expensive, can anyone give an example 
in what case STM style atom swap is better than lock based swap? Basically 
I am thinking STM atom is always no-better than lock based atom. Even for 
real-time system, the fact that you don't know when (and how many) re-try 
may happen will reduce its usefulness a lot.

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

Re: Expanding the Community Through Online Courses

[Harrison Maseko]

That's true. This reminds me of Pascal Chatterjee's Talking to 
Machines. 
It should be possible to fork it and embed it in videos? That is if we take 
the route suggested by Erlis Vidal. What else would that kind of work need?
-h

On Wednesday, July 18, 2012 7:55:14 PM UTC+2, Erlis Vidal wrote:
>
> Great idea!
>
> But even the community could create the space to learn clojure a la 
> UDacity. Something like Khan Academy but for clojure, where people can 
> choose a topic, maybe even a function and instead of having text as 
> documentation, we could have videos, with advises and real life examples on 
> how to use it. 
>
> UDacity was a great experience to meet Mr. Python. It was a great way to 
> learn the language, it will be super if clojure could have this chance. 
>
> On Wed, Jul 18, 2012 at 1:44 PM, Eduardo Bellani wrote:
>
>> Great idea and great effort. I would be awesome if Norvig gave a class
>> based on his PAIP
>> book, using clojure or any other lisp beast.
>>
>> On Wed, Jul 18, 2012 at 1:38 PM, Joshua Bowles  
>> wrote:
>> > I've made a request to Udacity and forwarded Harrison Maseko's 
>> suggestions
>> > in my request.
>> >
>> > I'm sure if enough people get behind this...
>> >
>> >
>> > On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles 
>> > wrote:
>> >>
>> >> Peter Norvig's response:
>> >>
>> >> Possible ... Udacity would be more likely -- they seem to be more
>> >> skill-based whereas Coursera is more academic-based.
>> >>
>> >>
>> >> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles 
>> >> wrote:
>> >>>
>> >>> I agree. My thinking with an AI class is that as LISP used to be 
>> taught
>> >>> for AI in school, and most programs offer Java classes, there's got 
>> to be a
>> >>> few Professors out there who really dig Clojure and have a good chance
>> >>> teaching it. I didn't propose a "functional programming" course 
>> because they
>> >>> already have that with Scala (not to say they wouldn't offer another).
>> >>>
>> >>> As far as Udacity, Peter Norvig is somehow related with Udacity (not 
>> sure
>> >>> what his role is), he's an old school LISPer and he's totally 
>> familiar with
>> >>> Java. I don't know if he's into Clojure (but he's definitely not 
>> against the
>> >>> idea of LISP running on JVM --- he wrote is own version a while back 
>> with
>> >>> scheme http://norvig.com/jscheme.html). I'll email him and see if 
>> he's
>> >>> interested.
>> >>>
>> >>>
>> >>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko 
>> >>> wrote:
>> 
>>  That sounds like a good move, if a professor at some at one of those
>>  Coursera linked universities would be willing to do that. However, 
>> can the
>>  same request be sent to Udacity? Also, is AI the only practical 
>> course to
>>  suggest? I would like to suggest to Udacity, "Introduction to 
>> Functional
>>  Programming." Another course I would suggest is, "Building a Dynamic
>>  Contacts Application for the Cloud," and the third one would be "Game
>>  Development in Clojure" or something more focused like "Fluid 
>> Dynamics for
>>  Game Development." All these could use Clojure.
>>  -h.
>> 
>> 
>>  On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>> >
>> > Yes! Just this morning (before reading this thread) I emailed 
>> Coursera
>> > to request a course like "Artificial Intelligence in Clojure". I 
>> posted on a
>> > separate thread here ("community interest in machine learning(?)") 
>> that I
>> > had made the request and provided a link for anyone else who wanted 
>> to make
>> > a request:
>> >  http://help.coursera.org/customer/portal/emails/new
>> >
>> >
>> > On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko 
>> > wrote:
>> >>
>> >> Hi Yann,
>> >> I agree that Udacity is more approachable in this regard than
>> >> Coursera. But imagine the publicity the language would get if such 
>> a massive
>> >> audience were given exposure to Clojure and Clojurescript. I have 
>> always
>> >> believed that a subset of Clojure (or any Lisp) could be taught 
>> even to
>> >> programming beginners with ease. This in turn could dispel much of 
>> the myths
>> >> surrounding Lisp-based languages to thousands at once (one of 
>> which is 'Lisp
>> >> is difficult.' Simple as it may sound, it has deterred many from 
>> even
>> >> peering into a Lisp). However, with a platform like Udacity, the 
>> instructor
>> >> is at liberty to really explain in a newbie-friendly way the 
>> elegance and
>> >> power of a language such as Clojure. The brief lesson videos would 
>> perhaps
>> >> be a more navigable route to Clojure for some than reading a book. 
>> All we
>> >> need is an attractive, *practical* topic (which can be suggested 
>> by anyone
>> >> here), a reputable instructor, and a way of engaging Udacity 
>> faculty about
>> >> our offer. And I w

Re: atom and lock

[Alan Malloy]

Sorta off-topic from the main discussion, but in reference to the error you 
pointed out, one clever fix for this is to add a delay around the future:

(defn cache-image [icache url]
  (let [task (delay (future (download-image url)))]
(doto (swap! icache update-in [url] #(or % task))
  (-> (get url) (force)

(defn wait-for-image [icache url]
  (deref (force (get icache url

As long as your swap! never overwrites an existing delay, only one will get 
added, and thus only one gets forced.

On Wednesday, July 18, 2012 4:48:17 AM UTC-7, tbc++ wrote:
>
> (def icache (atom {})) 
>
> (defn cache-image [url] 
>(let [f (future (download-image url))] 
>  (swap! icache assoc url f))) 
>
> I'll admit, we'll still try to download the image twice if two people 
> try to cache the same image at the exact same time but we could get 
> around that using promise or agents. So in general, your attitude when 
> using atoms, refs, or agents should be "get in and get out". Don't do 
> your work inside of swap!, send or alter 
>

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

Re: Expanding the Community Through Online Courses

[Erlis Vidal]

Great idea!

But even the community could create the space to learn clojure a la
UDacity. Something like Khan Academy but for clojure, where people can
choose a topic, maybe even a function and instead of having text as
documentation, we could have videos, with advises and real life examples on
how to use it.

UDacity was a great experience to meet Mr. Python. It was a great way to
learn the language, it will be super if clojure could have this chance.

On Wed, Jul 18, 2012 at 1:44 PM, Eduardo Bellani  wrote:

> Great idea and great effort. I would be awesome if Norvig gave a class
> based on his PAIP
> book, using clojure or any other lisp beast.
>
> On Wed, Jul 18, 2012 at 1:38 PM, Joshua Bowles 
> wrote:
> > I've made a request to Udacity and forwarded Harrison Maseko's
> suggestions
> > in my request.
> >
> > I'm sure if enough people get behind this...
> >
> >
> > On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles 
> > wrote:
> >>
> >> Peter Norvig's response:
> >>
> >> Possible ... Udacity would be more likely -- they seem to be more
> >> skill-based whereas Coursera is more academic-based.
> >>
> >>
> >> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles 
> >> wrote:
> >>>
> >>> I agree. My thinking with an AI class is that as LISP used to be taught
> >>> for AI in school, and most programs offer Java classes, there's got to
> be a
> >>> few Professors out there who really dig Clojure and have a good chance
> >>> teaching it. I didn't propose a "functional programming" course
> because they
> >>> already have that with Scala (not to say they wouldn't offer another).
> >>>
> >>> As far as Udacity, Peter Norvig is somehow related with Udacity (not
> sure
> >>> what his role is), he's an old school LISPer and he's totally familiar
> with
> >>> Java. I don't know if he's into Clojure (but he's definitely not
> against the
> >>> idea of LISP running on JVM --- he wrote is own version a while back
> with
> >>> scheme http://norvig.com/jscheme.html). I'll email him and see if he's
> >>> interested.
> >>>
> >>>
> >>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko 
> >>> wrote:
> 
>  That sounds like a good move, if a professor at some at one of those
>  Coursera linked universities would be willing to do that. However,
> can the
>  same request be sent to Udacity? Also, is AI the only practical
> course to
>  suggest? I would like to suggest to Udacity, "Introduction to
> Functional
>  Programming." Another course I would suggest is, "Building a Dynamic
>  Contacts Application for the Cloud," and the third one would be "Game
>  Development in Clojure" or something more focused like "Fluid
> Dynamics for
>  Game Development." All these could use Clojure.
>  -h.
> 
> 
>  On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
> >
> > Yes! Just this morning (before reading this thread) I emailed
> Coursera
> > to request a course like "Artificial Intelligence in Clojure". I
> posted on a
> > separate thread here ("community interest in machine learning(?)")
> that I
> > had made the request and provided a link for anyone else who wanted
> to make
> > a request:
> >  http://help.coursera.org/customer/portal/emails/new
> >
> >
> > On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko 
> > wrote:
> >>
> >> Hi Yann,
> >> I agree that Udacity is more approachable in this regard than
> >> Coursera. But imagine the publicity the language would get if such
> a massive
> >> audience were given exposure to Clojure and Clojurescript. I have
> always
> >> believed that a subset of Clojure (or any Lisp) could be taught
> even to
> >> programming beginners with ease. This in turn could dispel much of
> the myths
> >> surrounding Lisp-based languages to thousands at once (one of which
> is 'Lisp
> >> is difficult.' Simple as it may sound, it has deterred many from
> even
> >> peering into a Lisp). However, with a platform like Udacity, the
> instructor
> >> is at liberty to really explain in a newbie-friendly way the
> elegance and
> >> power of a language such as Clojure. The brief lesson videos would
> perhaps
> >> be a more navigable route to Clojure for some than reading a book.
> All we
> >> need is an attractive, *practical* topic (which can be suggested by
> anyone
> >> here), a reputable instructor, and a way of engaging Udacity
> faculty about
> >> our offer. And I wish that this process could begin sooner.
> >> Thanks,
> >> -h.
> >>
> >> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko  >
> >>> wrote:
> 
>  Hi All,
>  Massive Open Online Courses (MOOC) such as the ones offered by
>  Udacity, Coursera, and soon edX will eventually become platforms
> from which
>  a language can be showcased an

Re: Expanding the Community Through Online Courses

[Eduardo Bellani]

Great idea and great effort. I would be awesome if Norvig gave a class
based on his PAIP
book, using clojure or any other lisp beast.

On Wed, Jul 18, 2012 at 1:38 PM, Joshua Bowles  wrote:
> I've made a request to Udacity and forwarded Harrison Maseko's suggestions
> in my request.
>
> I'm sure if enough people get behind this...
>
>
> On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles 
> wrote:
>>
>> Peter Norvig's response:
>>
>> Possible ... Udacity would be more likely -- they seem to be more
>> skill-based whereas Coursera is more academic-based.
>>
>>
>> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles 
>> wrote:
>>>
>>> I agree. My thinking with an AI class is that as LISP used to be taught
>>> for AI in school, and most programs offer Java classes, there's got to be a
>>> few Professors out there who really dig Clojure and have a good chance
>>> teaching it. I didn't propose a "functional programming" course because they
>>> already have that with Scala (not to say they wouldn't offer another).
>>>
>>> As far as Udacity, Peter Norvig is somehow related with Udacity (not sure
>>> what his role is), he's an old school LISPer and he's totally familiar with
>>> Java. I don't know if he's into Clojure (but he's definitely not against the
>>> idea of LISP running on JVM --- he wrote is own version a while back with
>>> scheme http://norvig.com/jscheme.html). I'll email him and see if he's
>>> interested.
>>>
>>>
>>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko 
>>> wrote:

 That sounds like a good move, if a professor at some at one of those
 Coursera linked universities would be willing to do that. However, can the
 same request be sent to Udacity? Also, is AI the only practical course to
 suggest? I would like to suggest to Udacity, "Introduction to Functional
 Programming." Another course I would suggest is, "Building a Dynamic
 Contacts Application for the Cloud," and the third one would be "Game
 Development in Clojure" or something more focused like "Fluid Dynamics for
 Game Development." All these could use Clojure.
 -h.


 On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>
> Yes! Just this morning (before reading this thread) I emailed Coursera
> to request a course like "Artificial Intelligence in Clojure". I posted 
> on a
> separate thread here ("community interest in machine learning(?)") that I
> had made the request and provided a link for anyone else who wanted to 
> make
> a request:
>  http://help.coursera.org/customer/portal/emails/new
>
>
> On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko 
> wrote:
>>
>> Hi Yann,
>> I agree that Udacity is more approachable in this regard than
>> Coursera. But imagine the publicity the language would get if such a 
>> massive
>> audience were given exposure to Clojure and Clojurescript. I have always
>> believed that a subset of Clojure (or any Lisp) could be taught even to
>> programming beginners with ease. This in turn could dispel much of the 
>> myths
>> surrounding Lisp-based languages to thousands at once (one of which is 
>> 'Lisp
>> is difficult.' Simple as it may sound, it has deterred many from even
>> peering into a Lisp). However, with a platform like Udacity, the 
>> instructor
>> is at liberty to really explain in a newbie-friendly way the elegance and
>> power of a language such as Clojure. The brief lesson videos would 
>> perhaps
>> be a more navigable route to Clojure for some than reading a book. All we
>> need is an attractive, *practical* topic (which can be suggested by 
>> anyone
>> here), a reputable instructor, and a way of engaging Udacity faculty 
>> about
>> our offer. And I wish that this process could begin sooner.
>> Thanks,
>> -h.
>>
>> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>>>
>>>
>>>
>>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko 
>>> wrote:

 Hi All,
 Massive Open Online Courses (MOOC) such as the ones offered by
 Udacity, Coursera, and soon edX will eventually become platforms from 
 which
 a language can be showcased and exposed to a very wide audience. Here 
 are a
 few examples, all from Coursera:

 Scala: Functional Programming Principles in Scala.
 R:   Computing for Data Analysis.
 Python:   An Introduction to Interactive Programming In Python.
 C++/Java:   Compilers.
 Java:   Automata.

 Udacity has used Python and/or Javascript in some, if not most, of
 their recent courses. What do you think, will there ever be a chance 
 for a
 Clojure/ClojureScript-based course to be offered on one of these 
 platforms?
 What can the community d

Re: Idea around SCMs and Clojure

[Softaddicts]

I come from a world were we would write assembler code directly in
hexadecimal using the debugger and  decipher the memory dump
 to write back the source code.

You learned to be very fluent in hexadecimal :)))

Luc P.


> > I don't think so.  After some practice you can read patches as if they
> > were finest prose. ;-)
> 
> Yea, for prose they work. I believe that. But I'm paid for writing code :)
> 
> > There are already special-purpose, format-dependent diff/patch tools,
> > e.g., XMLdiff, various binary diff/patch tools, and some more.
> 
> I believe that too. But where are they? There are topics and themes
> you cannot miss. Like clojure. And there are topics and themes no one
> talks about - the special-purpose diff tools. I have a suspicion they
> somehow do not meet the needs. Can you point us to any?
> 
> Bost
> 
> -- 
> 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
> 
--
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

Re: Expanding the Community Through Online Courses

[Joshua Bowles]

I've made a request to Udacity and forwarded Harrison Maseko's suggestions
in my request.

I'm sure if enough people get behind this...

On Wed, Jul 18, 2012 at 10:33 AM, Joshua Bowles wrote:

> Peter Norvig's response:
>
> Possible ... Udacity would be more likely -- they seem to be more
> skill-based whereas Coursera is more academic-based.
>
>
> On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles wrote:
>
>> I agree. My thinking with an AI class is that as LISP used to be taught
>> for AI in school, and most programs offer Java classes, there's got to be a
>> few Professors out there who really dig Clojure and have a good chance
>> teaching it. I didn't propose a "functional programming" course because
>> they already have that with Scala (not to say they wouldn't offer another).
>>
>> As far as Udacity, Peter Norvig is somehow related with Udacity (not sure
>> what his role is), he's an old school LISPer and he's totally familiar with
>> Java. I don't know if he's into Clojure (but he's definitely not against
>> the idea of LISP running on JVM --- he wrote is own version a while back
>> with scheme http://norvig.com/jscheme.html). I'll email him and see if
>> he's interested.
>>
>>
>> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko wrote:
>>
>>> That sounds like a good move, if a professor at some at one of those
>>> Coursera linked universities would be willing to do that. However, can the
>>> same request be sent to Udacity? Also, is AI the only practical course to
>>> suggest? I would like to suggest to Udacity, "Introduction to Functional
>>> Programming." Another course I would suggest is, "Building a Dynamic
>>> Contacts Application for the Cloud," and the third one would be "Game
>>> Development in Clojure" or something more focused like "Fluid Dynamics for
>>> Game Development." All these could use Clojure.
>>> -h.
>>>
>>>
>>> On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:

 Yes! Just this morning (before reading this thread) I emailed Coursera
 to request a course like "Artificial Intelligence in Clojure". I posted on
 a separate thread here ("community interest in machine learning(?)") that I
 had made the request and provided a link for anyone else who wanted to make
 a request:
  
 http://help.coursera.org/**customer/portal/emails/new


 On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko wrote:

> Hi Yann,
> I agree that Udacity is more approachable in this regard than
> Coursera. But imagine the publicity the language would get if such a
> massive audience were given exposure to Clojure and Clojurescript. I have
> always believed that a subset of Clojure (or any Lisp) could be taught 
> even
> to programming beginners with ease. This in turn could dispel much of the
> myths surrounding Lisp-based languages to thousands at once (one of which
> is 'Lisp is difficult.' Simple as it may sound, it has deterred many from
> even peering into a Lisp). However, with a platform like Udacity, the
> instructor is at liberty to really explain in a newbie-friendly way the
> elegance and power of a language such as Clojure. The brief lesson videos
> would perhaps be a more navigable route to Clojure for some than reading a
> book. All we need is an attractive, *practical* topic (which can be
> suggested by anyone here), a reputable instructor, and a way of engaging
> Udacity faculty about our offer. And I wish that this process could begin
> sooner.
> Thanks,
> -h.
>
> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>>
>>
>>
>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko wrote:
>>
>>> Hi All,
>>> Massive Open Online Courses (MOOC) such as the ones offered by
>>> Udacity , Coursera,
>>> and soon edX  will eventually become
>>> platforms from which a language can be showcased and exposed to a very 
>>> wide
>>> audience. Here are a few examples, all from 
>>> Coursera
>>> :
>>>
>>>- Scala: Functional Programming Principles in 
>>> Scala.
>>>- R:   Computing for Data 
>>> Analysis.
>>>- Python:   An Introduction to Interactive Programming In
>>>Python .
>>>- C++/Java:   Compilers
>>>.
>>>- Java:   Automata
>>>.
>>>
>>> Udacity has used Python and/or Javascript in some, if not most, of
>>> their recent courses. What do you think, will there ever be a chance 
>>> for a
>>> Clojure/ClojureScrip

Re: Expanding the Community Through Online Courses

[Joshua Bowles]

Peter Norvig's response:

Possible ... Udacity would be more likely -- they seem to be more
skill-based whereas Coursera is more academic-based.

On Wed, Jul 18, 2012 at 10:16 AM, Joshua Bowles wrote:

> I agree. My thinking with an AI class is that as LISP used to be taught
> for AI in school, and most programs offer Java classes, there's got to be a
> few Professors out there who really dig Clojure and have a good chance
> teaching it. I didn't propose a "functional programming" course because
> they already have that with Scala (not to say they wouldn't offer another).
>
> As far as Udacity, Peter Norvig is somehow related with Udacity (not sure
> what his role is), he's an old school LISPer and he's totally familiar with
> Java. I don't know if he's into Clojure (but he's definitely not against
> the idea of LISP running on JVM --- he wrote is own version a while back
> with scheme http://norvig.com/jscheme.html). I'll email him and see if
> he's interested.
>
>
> On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko  wrote:
>
>> That sounds like a good move, if a professor at some at one of those
>> Coursera linked universities would be willing to do that. However, can the
>> same request be sent to Udacity? Also, is AI the only practical course to
>> suggest? I would like to suggest to Udacity, "Introduction to Functional
>> Programming." Another course I would suggest is, "Building a Dynamic
>> Contacts Application for the Cloud," and the third one would be "Game
>> Development in Clojure" or something more focused like "Fluid Dynamics for
>> Game Development." All these could use Clojure.
>> -h.
>>
>>
>> On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>>>
>>> Yes! Just this morning (before reading this thread) I emailed Coursera
>>> to request a course like "Artificial Intelligence in Clojure". I posted on
>>> a separate thread here ("community interest in machine learning(?)") that I
>>> had made the request and provided a link for anyone else who wanted to make
>>> a request:
>>>  
>>> http://help.coursera.org/**customer/portal/emails/new
>>>
>>>
>>> On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko wrote:
>>>
 Hi Yann,
 I agree that Udacity is more approachable in this regard than Coursera.
 But imagine the publicity the language would get if such a massive audience
 were given exposure to Clojure and Clojurescript. I have always believed
 that a subset of Clojure (or any Lisp) could be taught even to programming
 beginners with ease. This in turn could dispel much of the myths
 surrounding Lisp-based languages to thousands at once (one of which is
 'Lisp is difficult.' Simple as it may sound, it has deterred many from even
 peering into a Lisp). However, with a platform like Udacity, the instructor
 is at liberty to really explain in a newbie-friendly way the elegance and
 power of a language such as Clojure. The brief lesson videos would perhaps
 be a more navigable route to Clojure for some than reading a book. All we
 need is an attractive, *practical* topic (which can be suggested by anyone
 here), a reputable instructor, and a way of engaging Udacity faculty about
 our offer. And I wish that this process could begin sooner.
 Thanks,
 -h.

 On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>
>
>
> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko wrote:
>
>> Hi All,
>> Massive Open Online Courses (MOOC) such as the ones offered by
>> Udacity , Coursera ,
>> and soon edX  will eventually become
>> platforms from which a language can be showcased and exposed to a very 
>> wide
>> audience. Here are a few examples, all from 
>> Coursera
>> :
>>
>>- Scala: Functional Programming Principles in 
>> Scala.
>>- R:   Computing for Data 
>> Analysis.
>>- Python:   An Introduction to Interactive Programming In
>>Python .
>>- C++/Java:   Compilers
>>.
>>- Java:   Automata
>>.
>>
>> Udacity has used Python and/or Javascript in some, if not most, of
>> their recent courses. What do you think, will there ever be a chance for 
>> a
>> Clojure/ClojureScript-based course to be offered on one of these 
>> platforms?
>> What can the community do to create such a chance? Or is this perhaps not
>> important at all?
>> Thanks,
>> -h.
>
>
> Coursera only provides courses backed by established  universities, so
> it may rule out

Re: Expanding the Community Through Online Courses

[Joshua Bowles]

I agree. My thinking with an AI class is that as LISP used to be taught for
AI in school, and most programs offer Java classes, there's got to be a few
Professors out there who really dig Clojure and have a good chance teaching
it. I didn't propose a "functional programming" course because they already
have that with Scala (not to say they wouldn't offer another).

As far as Udacity, Peter Norvig is somehow related with Udacity (not sure
what his role is), he's an old school LISPer and he's totally familiar with
Java. I don't know if he's into Clojure (but he's definitely not against
the idea of LISP running on JVM --- he wrote is own version a while back
with scheme http://norvig.com/jscheme.html). I'll email him and see if he's
interested.

On Wed, Jul 18, 2012 at 9:08 AM, Harrison Maseko  wrote:

> That sounds like a good move, if a professor at some at one of those
> Coursera linked universities would be willing to do that. However, can the
> same request be sent to Udacity? Also, is AI the only practical course to
> suggest? I would like to suggest to Udacity, "Introduction to Functional
> Programming." Another course I would suggest is, "Building a Dynamic
> Contacts Application for the Cloud," and the third one would be "Game
> Development in Clojure" or something more focused like "Fluid Dynamics for
> Game Development." All these could use Clojure.
> -h.
>
>
> On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>>
>> Yes! Just this morning (before reading this thread) I emailed Coursera to
>> request a course like "Artificial Intelligence in Clojure". I posted on a
>> separate thread here ("community interest in machine learning(?)") that I
>> had made the request and provided a link for anyone else who wanted to make
>> a request:
>>  
>> http://help.coursera.org/**customer/portal/emails/new
>>
>>
>> On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko wrote:
>>
>>> Hi Yann,
>>> I agree that Udacity is more approachable in this regard than Coursera.
>>> But imagine the publicity the language would get if such a massive audience
>>> were given exposure to Clojure and Clojurescript. I have always believed
>>> that a subset of Clojure (or any Lisp) could be taught even to programming
>>> beginners with ease. This in turn could dispel much of the myths
>>> surrounding Lisp-based languages to thousands at once (one of which is
>>> 'Lisp is difficult.' Simple as it may sound, it has deterred many from even
>>> peering into a Lisp). However, with a platform like Udacity, the instructor
>>> is at liberty to really explain in a newbie-friendly way the elegance and
>>> power of a language such as Clojure. The brief lesson videos would perhaps
>>> be a more navigable route to Clojure for some than reading a book. All we
>>> need is an attractive, *practical* topic (which can be suggested by anyone
>>> here), a reputable instructor, and a way of engaging Udacity faculty about
>>> our offer. And I wish that this process could begin sooner.
>>> Thanks,
>>> -h.
>>>
>>> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:



 On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko wrote:

> Hi All,
> Massive Open Online Courses (MOOC) such as the ones offered by 
> Udacity
> , Coursera , and soon 
> edXwill eventually become platforms from which 
> a language can be showcased and
> exposed to a very wide audience. Here are a few examples, all from
> Coursera :
>
>- Scala: Functional Programming Principles in 
> Scala.
>- R:   Computing for Data 
> Analysis.
>- Python:   An Introduction to Interactive Programming In
>Python .
>- C++/Java:   Compilers 
>.
>- Java:   Automata
>.
>
> Udacity has used Python and/or Javascript in some, if not most, of
> their recent courses. What do you think, will there ever be a chance for a
> Clojure/ClojureScript-based course to be offered on one of these 
> platforms?
> What can the community do to create such a chance? Or is this perhaps not
> important at all?
> Thanks,
> -h.


 Coursera only provides courses backed by established  universities, so
 it may rule out community-based offerings. Udacity's case is different but
 the offering is more focused and very Python oriented. IMO, Udacity with
 its online Python editor and overall delivery style would be a better match
 for a clojure/clojurescript REPL approach. I have no idea how to get in
 touch with Dr Thrun et al

Re: Expanding the Community Through Online Courses

[Harrison Maseko]

That sounds like a good move, if a professor at some at one of those 
Coursera linked universities would be willing to do that. However, can the 
same request be sent to Udacity? Also, is AI the only practical course to 
suggest? I would like to suggest to Udacity, "Introduction to Functional 
Programming." Another course I would suggest is, "Building a Dynamic 
Contacts Application for the Cloud," and the third one would be "Game 
Development in Clojure" or something more focused like "Fluid Dynamics for 
Game Development." All these could use Clojure.
-h.

On Wednesday, July 18, 2012 4:29:04 PM UTC+2, Joshua Bowles wrote:
>
> Yes! Just this morning (before reading this thread) I emailed Coursera to 
> request a course like "Artificial Intelligence in Clojure". I posted on a 
> separate thread here ("community interest in machine learning(?)") that I 
> had made the request and provided a link for anyone else who wanted to make 
> a request: 
>  http://help.coursera.org/customer/portal/emails/new
>
>
> On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko  wrote:
>
>> Hi Yann,
>> I agree that Udacity is more approachable in this regard than Coursera. 
>> But imagine the publicity the language would get if such a massive audience 
>> were given exposure to Clojure and Clojurescript. I have always believed 
>> that a subset of Clojure (or any Lisp) could be taught even to programming 
>> beginners with ease. This in turn could dispel much of the myths 
>> surrounding Lisp-based languages to thousands at once (one of which is 
>> 'Lisp is difficult.' Simple as it may sound, it has deterred many from even 
>> peering into a Lisp). However, with a platform like Udacity, the instructor 
>> is at liberty to really explain in a newbie-friendly way the elegance and 
>> power of a language such as Clojure. The brief lesson videos would perhaps 
>> be a more navigable route to Clojure for some than reading a book. All we 
>> need is an attractive, *practical* topic (which can be suggested by anyone 
>> here), a reputable instructor, and a way of engaging Udacity faculty about 
>> our offer. And I wish that this process could begin sooner.
>> Thanks,
>> -h. 
>>
>> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>>>
>>>
>>>
>>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko wrote:
>>>
 Hi All,
 Massive Open Online Courses (MOOC) such as the ones offered by 
 Udacity
 , Coursera , and soon 
 edXwill eventually become platforms from which a 
 language can be showcased and 
 exposed to a very wide audience. Here are a few examples, all from 
 Coursera :

- Scala: Functional Programming Principles in 
 Scala.
- R:   Computing for Data 
 Analysis. 
- Python:   An Introduction to Interactive Programming In 
 Python
.
- C++/Java:   Compilers . 
- Java:   Automata
.

 Udacity has used Python and/or Javascript in some, if not most, of 
 their recent courses. What do you think, will there ever be a chance for a 
 Clojure/ClojureScript-based course to be offered on one of these 
 platforms? 
 What can the community do to create such a chance? Or is this perhaps not 
 important at all?
 Thanks,
 -h.
>>>
>>>
>>> Coursera only provides courses backed by established  universities, so 
>>> it may rule out community-based offerings. Udacity's case is different but 
>>> the offering is more focused and very Python oriented. IMO, Udacity with 
>>> its online Python editor and overall delivery style would be a better match 
>>> for a clojure/clojurescript REPL approach. I have no idea how to get in 
>>> touch with Dr Thrun et al about this, my only experience so far is with 
>>> taking classes with both Udacity and Coursera.
>>>  
>>  -- 
>> 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 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

Re: Expanding the Community Through Online Courses

[Joshua Bowles]

Yes! Just this morning (before reading this thread) I emailed Coursera to
request a course like "Artificial Intelligence in Clojure". I posted on a
separate thread here ("community interest in machine learning(?)") that I
had made the request and provided a link for anyone else who wanted to make
a request:
 http://help.coursera.org/customer/portal/emails/new


On Wed, Jul 18, 2012 at 8:18 AM, Harrison Maseko  wrote:

> Hi Yann,
> I agree that Udacity is more approachable in this regard than Coursera.
> But imagine the publicity the language would get if such a massive audience
> were given exposure to Clojure and Clojurescript. I have always believed
> that a subset of Clojure (or any Lisp) could be taught even to programming
> beginners with ease. This in turn could dispel much of the myths
> surrounding Lisp-based languages to thousands at once (one of which is
> 'Lisp is difficult.' Simple as it may sound, it has deterred many from even
> peering into a Lisp). However, with a platform like Udacity, the instructor
> is at liberty to really explain in a newbie-friendly way the elegance and
> power of a language such as Clojure. The brief lesson videos would perhaps
> be a more navigable route to Clojure for some than reading a book. All we
> need is an attractive, *practical* topic (which can be suggested by anyone
> here), a reputable instructor, and a way of engaging Udacity faculty about
> our offer. And I wish that this process could begin sooner.
> Thanks,
> -h.
>
> On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>>
>>
>>
>> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko wrote:
>>
>>> Hi All,
>>> Massive Open Online Courses (MOOC) such as the ones offered by 
>>> Udacity
>>> , Coursera , and soon 
>>> edXwill eventually become platforms from which a 
>>> language can be showcased and
>>> exposed to a very wide audience. Here are a few examples, all from
>>> Coursera :
>>>
>>>- Scala: Functional Programming Principles in 
>>> Scala.
>>>- R:   Computing for Data 
>>> Analysis.
>>>- Python:   An Introduction to Interactive Programming In 
>>> Python
>>>.
>>>- C++/Java:   Compilers .
>>>- Java:   Automata 
>>>.
>>>
>>> Udacity has used Python and/or Javascript in some, if not most, of their
>>> recent courses. What do you think, will there ever be a chance for a
>>> Clojure/ClojureScript-based course to be offered on one of these platforms?
>>> What can the community do to create such a chance? Or is this perhaps not
>>> important at all?
>>> Thanks,
>>> -h.
>>
>>
>> Coursera only provides courses backed by established  universities, so it
>> may rule out community-based offerings. Udacity's case is different but the
>> offering is more focused and very Python oriented. IMO, Udacity with its
>> online Python editor and overall delivery style would be a better match for
>> a clojure/clojurescript REPL approach. I have no idea how to get in touch
>> with Dr Thrun et al about this, my only experience so far is with taking
>> classes with both Udacity and Coursera.
>>
>  --
> 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 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

[ANN] jenkins-leiningen

[Pierre-Yves Ritschard]

Hi guys,

I wanted this for a while so here goes:
https://github.com/pyr/jenkins-leiningen.
It is very simplistic and inspired from the sbt one.

I posted a small blurb about it here as well:
http://spootnik.org/entries/2012/07/18_a-leiningen-plugin-for-jenkins.html

Cheers,
  - pyr

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

Re: Expanding the Community Through Online Courses

[Harrison Maseko]

Hi Yann,
I agree that Udacity is more approachable in this regard than Coursera. But 
imagine the publicity the language would get if such a massive audience 
were given exposure to Clojure and Clojurescript. I have always believed 
that a subset of Clojure (or any Lisp) could be taught even to programming 
beginners with ease. This in turn could dispel much of the myths 
surrounding Lisp-based languages to thousands at once (one of which is 
'Lisp is difficult.' Simple as it may sound, it has deterred many from even 
peering into a Lisp). However, with a platform like Udacity, the instructor 
is at liberty to really explain in a newbie-friendly way the elegance and 
power of a language such as Clojure. The brief lesson videos would perhaps 
be a more navigable route to Clojure for some than reading a book. All we 
need is an attractive, *practical* topic (which can be suggested by anyone 
here), a reputable instructor, and a way of engaging Udacity faculty about 
our offer. And I wish that this process could begin sooner.
Thanks,
-h. 

On Wednesday, July 18, 2012 3:16:56 PM UTC+2, Yann Schwartz wrote:
>
>
>
> On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko  wrote:
>
>> Hi All,
>> Massive Open Online Courses (MOOC) such as the ones offered by 
>> Udacity
>> , Coursera , and soon 
>> edXwill eventually become platforms from which a 
>> language can be showcased and 
>> exposed to a very wide audience. Here are a few examples, all from 
>> Coursera :
>>
>>- Scala: Functional Programming Principles in 
>> Scala.
>>- R:   Computing for Data 
>> Analysis. 
>>- Python:   An Introduction to Interactive Programming In 
>> Python
>>.
>>- C++/Java:   Compilers . 
>>- Java:   Automata .
>>
>> Udacity has used Python and/or Javascript in some, if not most, of their 
>> recent courses. What do you think, will there ever be a chance for a 
>> Clojure/ClojureScript-based course to be offered on one of these platforms? 
>> What can the community do to create such a chance? Or is this perhaps not 
>> important at all?
>> Thanks,
>> -h.
>
>
> Coursera only provides courses backed by established  universities, so it 
> may rule out community-based offerings. Udacity's case is different but the 
> offering is more focused and very Python oriented. IMO, Udacity with its 
> online Python editor and overall delivery style would be a better match for 
> a clojure/clojurescript REPL approach. I have no idea how to get in touch 
> with Dr Thrun et al about this, my only experience so far is with taking 
> classes with both Udacity and Coursera.
>  

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

Re: Idea around SCMs and Clojure

[Chris Ford]

I really hope that refactoring-aware diffs are on their way. They'll allow
for a whole class of merge conflicts to be resolved automatically.

Chris

On 18 July 2012 14:19, Leonardo Borges  wrote:

> I haven't been following this discussion that closely so far but I'd
> like to comment on this bit:
>
> > One of my frustrations with source control systems is the way you end up
> repeating information, e.g. Modified function X, Refactored function Y. >
> Added defmethod etc… This information is already present in the commit,
> after all its what you DID. The system should be able to work that out >
> and provide that information.
>
> Good commit messages contain more than that. For instance it would
> contain the reasoning behind the refactoring of function Y or the
> change to function X. That might be clear to you and perhaps some of
> your team. New members - and existing ones - might lack that context.
>
> My point is that I don't think the proposed output should replace a
> well hand crafted commit message.
>
> Cheers,
> Leonardo Borges
> www.leonardoborges.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Idea around SCMs and Clojure

[Leonardo Borges]

I haven't been following this discussion that closely so far but I'd
like to comment on this bit:

> One of my frustrations with source control systems is the way you end up 
> repeating information, e.g. Modified function X, Refactored function Y. > 
> Added defmethod etc… This information is already present in the commit, after 
> all its what you DID. The system should be able to work that out > and 
> provide that information.

Good commit messages contain more than that. For instance it would
contain the reasoning behind the refactoring of function Y or the
change to function X. That might be clear to you and perhaps some of
your team. New members - and existing ones - might lack that context.

My point is that I don't think the proposed output should replace a
well hand crafted commit message.

Cheers,
Leonardo Borges
www.leonardoborges.com

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

Re: Expanding the Community Through Online Courses

[Yann Schwartz]

On Wed, Jul 18, 2012 at 3:01 PM, Harrison Maseko  wrote:

> Hi All,
> Massive Open Online Courses (MOOC) such as the ones offered by 
> Udacity
> , Coursera , and soon 
> edXwill eventually become platforms from which a 
> language can be showcased and
> exposed to a very wide audience. Here are a few examples, all from
> Coursera :
>
>- Scala: Functional Programming Principles in 
> Scala.
>- R:   Computing for Data 
> Analysis.
>- Python:   An Introduction to Interactive Programming In 
> Python
>.
>- C++/Java:   Compilers .
>- Java:   Automata .
>
> Udacity has used Python and/or Javascript in some, if not most, of their
> recent courses. What do you think, will there ever be a chance for a
> Clojure/ClojureScript-based course to be offered on one of these platforms?
> What can the community do to create such a chance? Or is this perhaps not
> important at all?
> Thanks,
> -h.


Coursera only provides courses backed by established  universities, so it
may rule out community-based offerings. Udacity's case is different but the
offering is more focused and very Python oriented. IMO, Udacity with its
online Python editor and overall delivery style would be a better match for
a clojure/clojurescript REPL approach. I have no idea how to get in touch
with Dr Thrun et al about this, my only experience so far is with taking
classes with both Udacity and Coursera.

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

Re: Idea around SCMs and Clojure

[Nathan Matthews]

Hi Nahuel,

I think from a technical perspective something like Datomic would be a good 
fit, I think it has the right ingredients. If Git allows access to the lower 
layers, that may also be a good fit. One of my frustrations with source control 
systems is the way you end up repeating information, e.g. Modified function X, 
Refactored function Y. Added defmethod etc… This information is already present 
in the commit, after all its what you DID. The system should be able to work 
that out and provide that information. Granted source control systems don't do 
this today because they have no semantic understanding of the code, its just 
text to them. Wouldn't it be nice if the commit automatically compiled a list 
of the changes, E.g. the functions added, parameters added, functions removed, 
refactored etc.  My belief this that a user provided commit statement should 
contain the WHY not the WHAT. The system can determine the WHAT but not the 
WHY. If the information generated by the commit was structured in some way 
useful queries could be run against the source control system. E.g. show me the 
commit which added parameter "foo" to function "bar". 

On 18 Jul 2012, at 13:46, Nahuel Greco wrote:

> What about storing the vars definitions in Datomic? Maybe augmented
> with semantic information ("added defmethod", "redefined function",
> etc).
> 
> Saludos,
> Nahuel Greco.
> 
> 
> On Wed, Jul 18, 2012 at 5:19 AM, Mark Derricutt  wrote:
>> On 17/07/12 10:27 PM, N8Dawgrr wrote:
>> 
>> 
>> In a nutshell its about why use files for source in Clojure, can we do
>> better?
>> 
>> Almost sounds like you're wanting the Smalltalk "image" along with something
>> like Monticello - the smalltalk distributed version control system (
>> versioning at the function layer would be awesome ).
>> 
>> http://wiresong.ca/monticello/
>> 
>> 
>> --
>> 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 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 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

Expanding the Community Through Online Courses

[Harrison Maseko]

Hi All,
Massive Open Online Courses (MOOC) such as the ones offered by 
Udacity
, Coursera , and soon 
edXwill eventually become platforms from which a 
language can be showcased and 
exposed to a very wide audience. Here are a few examples, all from 
Coursera
:

   - Scala: Functional Programming Principles in 
Scala.
   - R:   Computing for Data 
Analysis.
   - Python:   An Introduction to Interactive Programming In 
Python
   .
   - C++/Java:   Compilers .
   - Java:   Automata .

Udacity has used Python and/or Javascript in some, if not most, of their 
recent courses. What do you think, will there ever be a chance for a 
Clojure/ClojureScript-based course to be offered on one of these platforms? 
What can the community do to create such a chance? Or is this perhaps not 
important at all?
Thanks,
-h.

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

Re: Idea around SCMs and Clojure

[Nahuel Greco]

What about storing the vars definitions in Datomic? Maybe augmented
with semantic information ("added defmethod", "redefined function",
etc).

Saludos,
Nahuel Greco.


On Wed, Jul 18, 2012 at 5:19 AM, Mark Derricutt  wrote:
> On 17/07/12 10:27 PM, N8Dawgrr wrote:
>
>
> In a nutshell its about why use files for source in Clojure, can we do
> better?
>
> Almost sounds like you're wanting the Smalltalk "image" along with something
> like Monticello - the smalltalk distributed version control system (
> versioning at the function layer would be awesome ).
>
> http://wiresong.ca/monticello/
>
>
> --
> 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 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

Re: how do I get primitive typ hints to appear in the output of a macro?

[Meikel Brandmeyer (kotarak)]

Hi,

the correct syntax is

(defmacro aTest
  []
  `(defn ~'aFun [~(with-meta 'b {:tag 'long})]))

; (meta (first (nth (macroexpand-1 '(aTest)) 2))) => {:tag long}

The 'long might also be a `long. I'm not sure about that one.

Kind regards
Meikel

PS: Shameless self-promotion: 
http://kotka.de/blog/2009/12/with-meta_and_the_reader.html

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

Re: how do I get primitive typ hints to appear in the output of a macro?

[Ambrose Bonnaire-Sergeant]

:-) Sorry, it has me stumped too.

Hopefully someone can clarify.

Ambrose

On Wed, Jul 18, 2012 at 8:28 PM, john  wrote:

> Hi Ambrose,
> I liked your core.logic video very much!
> But no the code doeen't seem to work:
>
> (defmacro aTest []
>   `(~'defn ~'aFun [^{:tag ~'long} ~'b ]  (meta ~'b) ))
>
> and I also tried:
>
> (defmacro aTest []
>   (list 'defn 'aFun (vector (with-meta 'b {:tag long})) '(meta b)))
> before
>
> (aFun 8) yields nil
>
> So I think the type hint are not on the param
>
> Am Mittwoch, 18. Juli 2012 14:18:21 UTC+2 schrieb Ambrose
> Bonnaire-Sergeant:
>
>> Hi John,
>>
>> The type hint ^long expands to ^{:tag long}.
>>
>> So something like this should do the trick (untested).
>>
>> (defmacro aTest []
>>   `(~'defn ~'aFun [^{:tag '~'long ~'b ]  (meta ~'b) ))
>>
>> Thanks,
>> Ambrose
>>
>>
>> Hello,
>>> how do I get primitive typ hints to appear in the output of a macro?
>>>
>>> like :
>>> (defmacro aTest []
>>>   `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))
>>>
>>> (macroexpand-1 '(aTest))
>>> yields :
>>>
>>> (aFun 7)
>>> (macroexpand-1 '(aTest))
>>> yields :
>>>
>>> (defn aFun [b] (clojure.core/meta b))
>>>
>>> but I wold like it to be :
>>> (defn aFun [^long b] (clojure.core/meta b))
>>>
>>> Many greetings
>>> John
>>>
>>>
>>>
>>
>>  --
> 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 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

Re: how do I get primitive typ hints to appear in the output of a macro?

[john]

Hi Ambrose,
I liked your core.logic video very much!
But no the code doeen't seem to work:
 
(defmacro aTest []
  `(~'defn ~'aFun [^{:tag ~'long} ~'b ]  (meta ~'b) ))
 
and I also tried:

(defmacro aTest []
  (list 'defn 'aFun (vector (with-meta 'b {:tag long})) '(meta b)))
before
 
(aFun 8) yields nil
 
So I think the type hint are not on the param

Am Mittwoch, 18. Juli 2012 14:18:21 UTC+2 schrieb Ambrose Bonnaire-Sergeant:

> Hi John,
>
> The type hint ^long expands to ^{:tag long}.
>
> So something like this should do the trick (untested).
>
> (defmacro aTest []
>   `(~'defn ~'aFun [^{:tag '~'long ~'b ]  (meta ~'b) ))
>
> Thanks,
> Ambrose
>
>
> Hello,
>> how do I get primitive typ hints to appear in the output of a macro?
>>  
>> like :
>> (defmacro aTest []
>>   `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))
>>
>> (macroexpand-1 '(aTest))
>> yields :
>>
>> (aFun 7)
>> (macroexpand-1 '(aTest))
>> yields :
>>  
>> (defn aFun [b] (clojure.core/meta b))
>>  
>> but I wold like it to be :
>> (defn aFun [^long b] (clojure.core/meta b))
>>  
>> Many greetings
>> John
>>
>>  
>>
>
>

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

Re: community interest in machine learning (?)

[Joshua Bowles]

I've written to Coursera to request a course in "Artificial Intelligence
with Clojure"; they offer about 8 courses related to Artificial
Intelligence. One of the latest course offerings is "Functional Programming
Principles in Scala" taught by the language's creator Martin Odersky.

If you would like to send Coursera a request for a Clojure class:
http://help.coursera.org/customer/portal/emails/new

On Wed, Jul 18, 2012 at 4:37 AM, Maik Schünemann
wrote:

> I'm interested too and I am glad to here that the community shares the
> interest!
> Clojure seems like an ideal AI and ML language for me because of its lisp
> heritage and because it is running on the jvm and can use all java and jvm
> language libraries and vice versa
>
>
> On Wed, Jul 18, 2012 at 3:58 AM, myriam abramson wrote:
>
>>
>> Yes, I am interested too. All I have done is an implementation of HMM and
>> I am looking to use clj-ml to interface with Weka.
>>
>> --
>> 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 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 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

Re: how do I get primitive typ hints to appear in the output of a macro?

[Ambrose Bonnaire-Sergeant]

Hi John,

The type hint ^long expands to ^{:tag long}.

So something like this should do the trick (untested).

(defmacro aTest []
  `(~'defn ~'aFun [^{:tag '~'long ~'b ]  (meta ~'b) ))

Thanks,
Ambrose

On Wed, Jul 18, 2012 at 7:55 PM, john  wrote:

> Hello,
> how do I get primitive typ hints to appear in the output of a macro?
>
> like :
> (defmacro aTest []
>   `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))
>
> (macroexpand-1 '(aTest))
> yields :
>
> (aFun 7)
> (macroexpand-1 '(aTest))
> yields :
>
> (defn aFun [b] (clojure.core/meta b))
>
> but I wold like it to be :
> (defn aFun [^long b] (clojure.core/meta b))
>
> Many greetings
> John
>
>
>
> --
> 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 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

Re: atom and lock

[Meikel Brandmeyer (kotarak)]

Hi,

Am Mittwoch, 18. Juli 2012 00:57:13 UTC+2 schrieb Warren Lynn:
>
> I have a hard time understanding why there is a need to retry when doing 
> "swap!" on an atom. Why does not Clojure just lock the atom up-front and do 
> the update? I have this question because I don't see any benefit of the 
> current "just try and then re-try if needed" (STM?) approach for atom 
> (maybe OK for refs because you cannot attach a lock to unknown ref 
> combinations in a "dosync" clause). Right now I have an atom in my program 
> and there are two "swap!" functions on it. One may take a (relatively) long 
> time, and the other is short. I don't want the long "swap!" function to 
> retry just because in the last minute the short one sneaked in and changed 
> the atom value. I can do the up-front lock myself, but I wonder why this is 
> not already so in the language. Thank you for any enlightenment.
>

Clojure is not optimised for one use case. As the answers of the other 
participants in this thread showed there is a plethora of use cases where 
the lock is not necessary and, in the contrary, can be actually harmful. 
Would Clojure directly use the lock as you propose everyone would have to 
pay the performance penalty imposed by the locking. And there would be no 
way to remedy this fact with on-board means.

By not using a lock to protect the update, Clojure allows to be fast where 
the lock is not necessary and still it is possible for you to base a quite 
simple LockAtom on the existing implementation as you have proven yourself. 
I feel the need for LockAtom very often put it in a library on Clojars. If 
you get a lot of "Hey, Dude! That is exactly what I needed. You saved my 
life. You are my hero!", then propose it for inclusion into Clojure proper 
(or some contrib) to have it also in the official distribution.

Kind regards
Meikel

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

Re: atom and lock

[Marshall T. Vandegrift]

Warren Lynn  writes:

> I have a hard time understanding why there is a need to retry when
> doing "swap!" on an atom. Why does not Clojure just lock the atom
> up-front and do the update?

This is just my two cents, but I think the/one big reason is that
Clojure atoms just *are* non-locking STM-based synchronized references.
They allow you to handle "shared, synchronous, independent state," but
that's their typical use-case, not their definition.  The Clojure atom
is defined in terms of mechanism, not application.

If you want locks, the Java standard library has locks aplenty.  My
understanding of the Clojure idiom is that when "traditional"
threads-locks-and-queues concurrency is the best fit for the job, then
just use it.  My reading of the standard library suggests a strong
preference for using higher-level constructs which leverage shared
thread pools (futures and agents) over raw threads, but absolutely no
shame in using e.g. LinkedBlockingQueue.

Here's my quick stab at something implemented atop Java read-write
locks:

  https://gist.github.com/3135772

-Marshall

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

how do I get primitive typ hints to appear in the output of a macro?

[john]

Hello,
how do I get primitive typ hints to appear in the output of a macro?
 
like :
(defmacro aTest []
  `(~'defn ~'aFun [^long ~'b ]  (meta ~'b) ))

(macroexpand-1 '(aTest))
yields :

(aFun 7)
(macroexpand-1 '(aTest))
yields :
 
(defn aFun [b] (clojure.core/meta b))
 
but I wold like it to be :
(defn aFun [^long b] (clojure.core/meta b))
 
Many greetings
John

 

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

Re: atom and lock

[Brian Hurt]

Accesses to atoms are just wrappers around atomic compare and swap
instructions at the hardware level.  Locking an object also uses an atomic
compare and swap, but piles other stuff on top of it, making it more
expensive.  So atoms are useful in situations where there is likely not
going to be much in the way of contention (multiple writes happening at the
same time), so there won't be that many retries, and where the cost of
redoing the computation is low enough that it's cheaper to simply redo an
occasional update than pay the cost of locking.  So, a classic example of a
good use of atom is to assign ids, like:

(def counter (atom 0))

(def get-id [] (swap! counter inc))

Incrementing an integer is about as cheap as computations get.  Even if
some unlucky thread had to redo the computation dozens of times before
"winning", that isn't that high of a cost.  And even if you're getting
millions of ids a second, the number of collisions you have will be low.
So this is a good use for atoms.  Any more advanced locking behavior would
simply slow things down.

Holding hash maps in atoms is a borderline case.  I tend to only do it when
I know the update rate will be low, and thus collisions very rare.

For situations where collisions are a lot more common, or where the update
is a lot more expensive, I'd use a ref cell and a dosync block.  Of course,
if you need atomic updates to multiple different cells, there is no
replacement for dosync blocks.

Brian

On Tue, Jul 17, 2012 at 6:57 PM, Warren Lynn  wrote:

> I have a hard time understanding why there is a need to retry when doing
> "swap!" on an atom. Why does not Clojure just lock the atom up-front and do
> the update? I have this question because I don't see any benefit of the
> current "just try and then re-try if needed" (STM?) approach for atom
> (maybe OK for refs because you cannot attach a lock to unknown ref
> combinations in a "dosync" clause). Right now I have an atom in my program
> and there are two "swap!" functions on it. One may take a (relatively) long
> time, and the other is short. I don't want the long "swap!" function to
> retry just because in the last minute the short one sneaked in and changed
> the atom value. I can do the up-front lock myself, but I wonder why this is
> not already so in the language. Thank you for any enlightenment.
>
> --
> 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 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

Re: atom and lock

[Timothy Baldridge]

>> Being lockless seems useful for certain cases (like real-time system as
>> mentioned in the Wikipedia article). But I still could not grasp the idea
>> how it can increase *real* work throughput, as the problem itself mandates a
>> part of the work can only be done in serial.


Well first of all, your solution is horribly slow:

user=> (time (dotimes [x 100] (lock-swap! la (fn [o n] n) x)))
"Elapsed time: 43289.909709 msecs"
nil
user=> (def a (atom 0))
#'user/a
user=> (time (dotimes [x 100] (swap! a (fn [o n] n) x)))
"Elapsed time: 475.085593 msecs"
nil

But that's probably made worse by the use of reflection, so let's try this:

user=> (defn lock-swap! [^LockAtom lock-atom & rest-args] (locking
lock-atom (apply swap! (.atom lock-atom) rest-args)))
#'user/lock-swap!
user=> (time (dotimes [x 100] (lock-swap! la (fn [o n] n) x)))
"Elapsed time: 7596.568038 msecs"
nil

So, still it's 20x slower than straight old swap!

In all the multithreaded code I've worked on (and I've worked on quite
a lot in Clojure), I've never had code inside a swap! that would take
more than ~1ms to execute. In fact, I would say that by using delay,
promise and future, you can implement your "1 hour task" with much
less touching of locks. For instance, a naive implementation of an
image cache may look like this:


(def icache (atom {}))

(defn cache-image [url]
   (swap! icache assoc url (download-image url)))


However, this is going to hit some of the issues you mentioned above.
We're going to re-download images if there was a swap! retry. Well
here's the correct way to go about this (or one of them).

(def icache (atom {}))

(defn cache-image [url]
   (let [f (future (download-image url))]
 (swap! icache assoc url f)))

I'll admit, we'll still try to download the image twice if two people
try to cache the same image at the exact same time but we could get
around that using promise or agents. So in general, your attitude when
using atoms, refs, or agents should be "get in and get out". Don't do
your work inside of swap!, send or alter

Timothy

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

Re: why does Clojure need to cache keywords?

[jaime]

make senseI just came up with this similar answer on my way 
home...Thanks.

在 2012年7月18日星期三UTC+8下午6时56分42秒，dennis写道：
>
> I think this cache is just the same with String.intern method in java,it 
> just want to reduce the cost (memory & cpu) of producing keywords 
> frequently especial when using them with map structure.
>
> 2012/7/18 jaime 
>
>> I doubt because keyword will use its internal Symbol object to compare 
>> with each other (or other objects), it means it's Symbol's interned 
>> strings(ns & name) make the comparison fast but not this caching stuff. I 
>> found a "find()" method in source code but not sure if the cache is 
>> relevant to this method.
>>
>> 在 2012年7月18日星期三UTC+8下午4时52分25秒，dennis写道：
>>
>>> Compare keywords can be very fast.
>>> 在 2012-7-18 PM4:51，"jaime" 写道：
>>>
 Hello,

 When I read the source code keyword, say, Keyword.java (V1.3), I found 
 that when we "intern" a keyword,   (if I understand it correctly)  it uses 
 a cache for keywords:
 ==**===
 public static Keyword intern(Symbol sym) {
  if (sym.meta() != null)
 sym = (Symbol) sym.withMeta(null);
 *Util.clearCache(rq, table);*
  Keyword k = new Keyword(sym);
 Reference existingRef = table.putIfAbsent(sym,
  new WeakReference(k, rq));
 if (existingRef == null)
  return k;
 Keyword existingk = existingRef.get();
 if (existingk != null)
  return existingk;
 // entry died in the interim, do over
 table.remove(sym, existingRef);
  return intern(sym);
 }
 ==**

 well, I just don't understand why we need caching for keywords. Anyone 
 could give me a hint?

 -- 
 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+unsubscribe@**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 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
>>
>
>
>
> -- 
> 庄晓丹 
> Email:killme2...@gmail.com xzhu...@avos.com
> Site:   http://fnil.net
> Twitter:  @killme2008
>
>
>
>

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

Re: why does Clojure need to cache keywords?

[dennis zhuang]

I think this cache is just the same with String.intern method in java,it
just want to reduce the cost (memory & cpu) of producing keywords
frequently especial when using them with map structure.

2012/7/18 jaime 

> I doubt because keyword will use its internal Symbol object to compare
> with each other (or other objects), it means it's Symbol's interned
> strings(ns & name) make the comparison fast but not this caching stuff. I
> found a "find()" method in source code but not sure if the cache is
> relevant to this method.
>
> 在 2012年7月18日星期三UTC+8下午4时52分25秒，dennis写道：
>
>> Compare keywords can be very fast.
>> 在 2012-7-18 PM4:51，"jaime" 写道：
>>
>>> Hello,
>>>
>>> When I read the source code keyword, say, Keyword.java (V1.3), I found
>>> that when we "intern" a keyword,   (if I understand it correctly)  it uses
>>> a cache for keywords:
>>> ==**===
>>> public static Keyword intern(Symbol sym) {
>>>  if (sym.meta() != null)
>>> sym = (Symbol) sym.withMeta(null);
>>> *Util.clearCache(rq, table);*
>>>  Keyword k = new Keyword(sym);
>>> Reference existingRef = table.putIfAbsent(sym,
>>>  new WeakReference(k, rq));
>>> if (existingRef == null)
>>>  return k;
>>> Keyword existingk = existingRef.get();
>>> if (existingk != null)
>>>  return existingk;
>>> // entry died in the interim, do over
>>> table.remove(sym, existingRef);
>>>  return intern(sym);
>>> }
>>> ==**
>>>
>>> well, I just don't understand why we need caching for keywords. Anyone
>>> could give me a hint?
>>>
>>> --
>>> 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+unsubscribe@**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 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
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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

Re: atom and lock

[Andrew Rafas]

On Wednesday, July 18, 2012 1:20:03 AM UTC+1, Warren Lynn wrote:
>
> The "making progress" seems an illusion here to me. Sure, you can make 
> progress in one thread while another thread is taking one hour to finish 
> its part. But the cost is the "long" thread finally found out "oops, I have 
> to start over my one-hour job". 
>
> Being lockless seems useful for certain cases (like real-time system as 
> mentioned in the Wikipedia article). But I still could not grasp the idea 
> how it can increase *real* work throughput, as the problem itself mandates 
> a part of the work can only be done in serial.
>
>
Being lockless will not introduce more parallelism to an algorithm. So it 
will not beat Amdahl's law no matter how hard you try. In practice, because 
of the retries, performance will degrade to a level (sometimes much lower) 
which can be achieved by using locks. The point of clojure's threading 
support is (as I see it) is that you do not have to deal with lock 
hierarchies and deadlocks. On the other hand you cannot really control 
performance degradation in case of contention (too many retries) so in the 
end it is just a trade off. For some problems it is worth to make it, for 
other problems you are better to use locks or work queues.
Hope that helps.
Andrew

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

Re: community interest in machine learning (?)

[Maik Schünemann]

I'm interested too and I am glad to here that the community shares the
interest!
Clojure seems like an ideal AI and ML language for me because of its lisp
heritage and because it is running on the jvm and can use all java and jvm
language libraries and vice versa

On Wed, Jul 18, 2012 at 3:58 AM, myriam abramson wrote:

>
> Yes, I am interested too. All I have done is an implementation of HMM and
> I am looking to use clj-ml to interface with Weka.
>
> --
> 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 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

Re: why does Clojure need to cache keywords?

[jaime]

I doubt because keyword will use its internal Symbol object to compare with 
each other (or other objects), it means it's Symbol's interned strings(ns & 
name) make the comparison fast but not this caching stuff. I found a 
"find()" method in source code but not sure if the cache is relevant to 
this method.

在 2012年7月18日星期三UTC+8下午4时52分25秒，dennis写道：
>
> Compare keywords can be very fast.
> 在 2012-7-18 PM4:51，"jaime" 写道：
>
>> Hello,
>>
>> When I read the source code keyword, say, Keyword.java (V1.3), I found 
>> that when we "intern" a keyword,   (if I understand it correctly)  it uses 
>> a cache for keywords:
>> =
>> public static Keyword intern(Symbol sym) {
>>  if (sym.meta() != null)
>> sym = (Symbol) sym.withMeta(null);
>> *Util.clearCache(rq, table);*
>>  Keyword k = new Keyword(sym);
>> Reference existingRef = table.putIfAbsent(sym,
>>  new WeakReference(k, rq));
>> if (existingRef == null)
>>  return k;
>> Keyword existingk = existingRef.get();
>> if (existingk != null)
>>  return existingk;
>> // entry died in the interim, do over
>> table.remove(sym, existingRef);
>>  return intern(sym);
>> }
>> ==
>>
>> well, I just don't understand why we need caching for keywords. Anyone 
>> could give me a hint?
>>
>> -- 
>> 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 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

Re: why does Clojure need to cache keywords?

[dennis zhuang]

Compare keywords can be very fast.
在 2012-7-18 PM4:51，"jaime" 写道：

> Hello,
>
> When I read the source code keyword, say, Keyword.java (V1.3), I found
> that when we "intern" a keyword,   (if I understand it correctly)  it uses
> a cache for keywords:
> =
> public static Keyword intern(Symbol sym) {
> if (sym.meta() != null)
> sym = (Symbol) sym.withMeta(null);
> *Util.clearCache(rq, table);*
> Keyword k = new Keyword(sym);
> Reference existingRef = table.putIfAbsent(sym,
> new WeakReference(k, rq));
> if (existingRef == null)
> return k;
> Keyword existingk = existingRef.get();
> if (existingk != null)
> return existingk;
> // entry died in the interim, do over
> table.remove(sym, existingRef);
> return intern(sym);
> }
> ==
>
> well, I just don't understand why we need caching for keywords. Anyone
> could give me a hint?
>
> --
> 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 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

why does Clojure need to cache keywords?

[jaime]

Hello,

When I read the source code keyword, say, Keyword.java (V1.3), I found that 
when we "intern" a keyword,   (if I understand it correctly)  it uses a 
cache for keywords:
=
public static Keyword intern(Symbol sym) {
if (sym.meta() != null)
sym = (Symbol) sym.withMeta(null);
*Util.clearCache(rq, table);*
Keyword k = new Keyword(sym);
Reference existingRef = table.putIfAbsent(sym,
new WeakReference(k, rq));
if (existingRef == null)
return k;
Keyword existingk = existingRef.get();
if (existingk != null)
return existingk;
// entry died in the interim, do over
table.remove(sym, existingRef);
return intern(sym);
}
==

well, I just don't understand why we need caching for keywords. Anyone 
could give me a hint?

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

Re: Idea around SCMs and Clojure

[Mark Derricutt]

On 17/07/12 10:27 PM, N8Dawgrr wrote:


In a nutshell its about why use files for source in Clojure, can we do 
better?


Almost sounds like you're wanting the Smalltalk "image" along with 
something like Monticello - the smalltalk distributed version control 
system ( versioning at the function layer would be awesome ).


http://wiresong.ca/monticello/


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

Re: atom and lock

[Ulises]

Please excuse my ignorance and my late comment, but can you make your
1hr operation shorter?

The general advice I've always been given has been "whenever you need
to use a resource that might cause contention do it quickly, in and
out in a blink".

I know that the argument then would be "why do I need to change my
code to fit the tool?" but in general terms I'd think that having such
a long running operation is a bad thing anyway?

Unless the 1hr operation is just an exaggeration to get your point
across, in which case just ignore my comment :)

U

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

Re: {ANN} clojure-control 0.4.1 released.

[dennis zhuang]

I see,thanks.

Pallet is more powerful than clojure-control.It seems that it contains many
features for cloud service rather than just a deployment tool.

And clojure-control is just a deployment tool like fabric in python for
many machines using SSH,it can reuse tasks and clusters,and have a simple
bash script to run them.


2012/7/18 Murtaza Husain 

>
> http://palletops.com/
>
>
> On Wednesday, July 18, 2012 11:41:11 AM UTC+5:30, dennis wrote:
>>
>> I am sorry,i don't know pallet,any links? thanks.
>>
>> 2012/7/18 Murtaza Husain 
>> 
>> >
>>
>>>
>>> Hi,
>>>
>>> How is this different from pallet ?
>>>
>>> Thanks,
>>> Murtaza
>>>
>>>
>>> On Wednesday, July 18, 2012 10:52:57 AM UTC+5:30, dennis wrote:

 Clojure-control  is a
 clojure tool library to execute user defined tasks on remote machines
 grouped into cluster just like fabric in python or node-control in node.js.

 *Home*: 
 https://github.com/**killm**e2008/clojure-control

 Control 0.4.1 released,it has a little improvement in command line,
 introduced -f option to set control file,for example

control -f mycontrol.clj run mycluster mytask

 You can upgrade it by

control upgrade

 Thanks.

 --
 庄晓丹
 Email:killme2...@gmail.com xzhu...@avos.com
 Site:   http://fnil.net
 Twitter:  @killme2008



   --
>>> 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+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/clojure?hl=en
>>
>>
>>
>>
>> --
>> 庄晓丹
>> Email:killme2...@gmail.com xzhu...@avos.com
>> Site:   http://fnil.net
>> Twitter:  @killme2008
>>
>>
>>
>>  --
> 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
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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