Re: ClassCastException in APersistentVector.doEquiv with custom implementation of IPersistentVector

[Vincent]

On Friday, July 12, 2013 12:01:08 AM UTC+2, Sean Corfield wrote:
>
> On Wed, Jul 10, 2013 at 11:00 AM, Vincent > 
> wrote: 
> > I guess I can proxy APersistentVector, but the Clojure docs [1] advise 
> to 
> > use reify in favour to proxy whenever possible. My goal is to have my 
> byte 
> > stream behave like a standard Clojure vector. 
>
> Given the definition of IPersistentVector, I would expect you to need 
> to provide several more method definitions? 
>

Sure. I left my example minimal on purpose so that people can easily see 
the point. Eventually I'll implement the methods of IPersistentVector and 
all its super-interfaces, but I was hoping that I wouldn't have to 
implement java.util.Collection (and its inherently mutable corresponding 
Iterator).


https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IPersistentVector.java
 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

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

Re: Multiple REPLs in Emacs? (was: test run startup time

[Islon Scherer]

Here at doo we have a shortcut "C-c X" where X is a number to change 
between nrepls.

The code is in https://github.com/maxweber/emacs.d/blob/master/my/nrepl.el

Note that the nrepl ports are hardcoded but it's good enough for us.

Hope this helps.

--
Islon

On Thursday, July 11, 2013 11:53:31 PM UTC+2, Sean Corfield wrote:
>
> On Wed, Jul 10, 2013 at 10:53 AM, Jay Fields 
> > 
> wrote: 
> > I work in emacs with 2 repls running - 1 for running my app and 1 for 
> > running my tests. 
>
> What is the magic to get this working and how does Emacs / nrepl.el 
> know which REPL to send commands to? 
>
> I've often wanted multiple active REPLs (usually for working with 
> multiple projects) but have never figured out how to get it working... 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

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

Re: (newbie) replace certain values of a map based on a predicate

[Colin Yates]

Thanks Cedric,

I am constantly writing code and then finding something in the core library
whivh already does what I need :).

http://clojuredocs.org/clojure_core/1.2.0/clojure.walk/keywordize-keys was
the latest gem.
On 5 Jul 2013 22:51, "Cedric Greevey"  wrote:

> Even without reaching for libraries outside clojure.core, there's
>
> (update-in m [:key-of-interest] #(if (condition? %) (transformation %) %))
>
> and the ability to convert that into a function, e.g.
>
> (defn conditional-update-in [m condition? transformation k]
>   (update-in m [k] #(if (condition? %) (transformation %) %)))
>
> and then, if you have many keys that should undergo the same
> transformation under the same condition,
>
> (reduce (partial conditional-update-in m condition? transformation)
> [keys...]), and its encapsulation,
>
> (defn conditional-update-multi [m condition? transformation ks]
>   (reduce (partial conditional-update-in m condition? transformation) ks))
>
>
>
>
> On Fri, Jul 5, 2013 at 5:31 PM, Ben Wolfson  wrote:
>
>> You could use clojure.algo.generic.functor.fmap: (fmap #(if (pred? %)
>> replacement-value %) your-map).
>>
>>
>> On Fri, Jul 5, 2013 at 2:08 PM, John Walker wrote:
>>
>>> I had to do something similar, and used 
>>> clojure.walk.
>>>
>>> On Friday, July 5, 2013 8:59:54 PM UTC, Colin Yates wrote:

 Hi all,

 I think this is one of those questions which has quite a few answers,
 but given a map, how do I replace the values by applying a function to
 those values, but only if they meet a condition?

 I understand the building blocks of (map..), (filter..), (assoc-in..)
 and (filter..) and I can see how something could work using those pieces
 but is would be pretty verbose.  I am sure there is probably a much more
 simple way using a more abstract function.

 The actual use case is I have a list of maps as returned from the
 clojure.java.jdbc framework and they contain timestamps.  I want to replace
 all the timestamps with (for example) to a Joda LocalDate using the
 excellent clj-time library.

 Any pointers?

 Thanks!

 Col

>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks,
>> which may be sweet, aromatic, fermented or spirit-based. ... Family and
>> social life also offer numerous other occasions to consume drinks for
>> pleasure." [Larousse, "Drink" entry]
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/Wqu-VBR5bSk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to

Re: Doc about auto-namespaced keywords (e.g. ::user)?

[Bastien Guerry]

Hi Chas,

Chas Emerick  writes:

> We talked about namespaced keywords in 'Clojure Programming'.  A brief
> introduction to them can be found on page 14, which you can get for
> free @ http://clojurebook.com (look for the "first chapter" link on
> the right).  They're used for more than e.g. unambiguously keying
> slots in a map, but those cases are described later in the book.

Great, I didn't expect this example chapter to be so detailed and
informative.

Thanks for the pointer!  

-- 
 Bastien

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

Re: Stack overflow deep in repl printer

[David Goldfarb]

Yes, I agree with you: better to bind outside the whole repl loop. I 
misspoke when I said "around the printing".

That said, I think it might still be reasonable to put much tighter bounds 
on the cotents inside the printing of "#< ... >".

David

On Thursday, July 11, 2013 3:09:07 PM UTC+3, Meikel Brandmeyer (kotarak) 
wrote:
>
> David,
>
> I wouldn't automatically set any values around the printing. The user 
> should be free to do what he likes.
>
> But the repl could start out with some sane defaults, which are not 
> limiting in the usual case, but safe in general. Like 50 for the level and 
> 1000 for the length. Then you are not caught by the infitinite recursion, 
> but still can override the default should the need arise.
>
> 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: core.async: communicating termination

[vemv]

If one used those preds to try putting values on the channels one is asking 
about, then yes, that would generate a classic nasty check-then-act 
scenario:

(when-not (closed? c) (>! c 42)) ;; Value could be never put, in face of 
interleavings

Programmers experienced in concurrency should have developed a sensibility 
against that kind of code anyway.

However, if what one is trying is to *stop* putting values on the channel, 
I see no possible race conditions.

On Friday, July 12, 2013 2:01:02 AM UTC+2, Brandon Bloom wrote:
>
> Wouldn't closed and drained predicates introduce race conditions?
>
> (Sorry for brevity, on my phone)
>

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

lazy-seq with meta

[Karsten Schmidt]

Hello, what is the correct way (assuming there is one) to create a lazy-seq
with metadata attached? The below works for short seqs, but causes a stack
overflow for large ones, which obviously means the lazy-seq mechanism is
altered/broken if wrapped with `with-meta`. So I guess there must be
another way...

(defn meta-test
  [i]
  (with-meta
(lazy-seq
  (when (pos? i) (cons i (meta-test (dec i)
{:range i}))

(meta (meta-test 100))
; => {:range 100}

Thanks for any insights!
K.

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

Re: lazy-seq with meta

[Karsten Schmidt]

Okay, I just found a negative answer to this on SO:
http://stackoverflow.com/questions/1056061/adding-metadata-to-a-lazy-sequence

However, to give a bit more context for my concrete use case: I'm
building a Turtle (RDF) parser which emits a lazy seq of triples,
basically a seq of 3-element vectors where the first 2 are URIs. In
Turtle these URIs can be abbreviated using namespace prefixes declared
at the beginning of the file, e.g given this TTL chunk:

@prefix ex:  .
@prefix rdf:  .
@prefix doap:  .

ex:clojure rdf:type doap:Project ;
doap:name "Clojure" .

results in this seq of 2 triples:

(["http://example.org/ns#clojure";
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type";
"http://usefulinc.com/ns/doap#Project";]
 ["http://example.org/ns#clojure"; "http://usefulinc.com/ns/doap#name";
"Clojure"])

Sinc the prefix map is built iteratively as part of the parsing I was
hoping to attach it as meta data to the returned lazy-seq, since I
can't see any other way of returning this map apart from attaching to
every single triple in the seq (which seems like overkill).

Are there any other options I'm missing here?

On 12 July 2013 14:42, Karsten Schmidt  wrote:
> Hello, what is the correct way (assuming there is one) to create a lazy-seq
> with metadata attached? The below works for short seqs, but causes a stack
> overflow for large ones, which obviously means the lazy-seq mechanism is
> altered/broken if wrapped with `with-meta`. So I guess there must be another
> way...
>
> (defn meta-test
>   [i]
>   (with-meta
> (lazy-seq
>   (when (pos? i) (cons i (meta-test (dec i)
> {:range i}))
>
> (meta (meta-test 100))
> ; => {:range 100}
>
> Thanks for any insights!
> K.



-- 
Karsten Schmidt
http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk

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

Re: core.async: communicating termination

[Brandon Bloom]

> However, if what one is trying is to *stop* putting values on the 
channel, I see no possible race conditions.

Querying the state of a channel at worst leads to race conditions and at 
best leads to bad design.

You're only supposed to close a channel from the producer side. So if 
you're the only writer, then you know if you've closed the channel or not. 
If there are multiple writers, then need to be coordinated in some way. 
Typically, they would alt! against reading from a control channel and 
writing to the output channel. When you get a shutdown signal from the 
control channel, you stop writing.

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

Re: core.async: communicating termination

[Víctor M . Valenzuela]

>
> Querying the state of a channel at worst leads to race conditions and at
> best leads to bad design.
>

The open/closed state of a channel is simple to reason about (it only
changes, if ever, once), unlike the rest of state that is associated to a
given channel...

You're only supposed to close a channel from the producer side.
>

Why?

On Fri, Jul 12, 2013 at 9:22 PM, Brandon Bloom wrote:

> > However, if what one is trying is to *stop* putting values on the
> channel, I see no possible race conditions.
>
> Querying the state of a channel at worst leads to race conditions and at
> best leads to bad design.
>
> You're only supposed to close a channel from the producer side. So if
> you're the only writer, then you know if you've closed the channel or not.
> If there are multiple writers, then need to be coordinated in some way.
> Typically, they would alt! against reading from a control channel and
> writing to the output channel. When you get a shutdown signal from the
> control channel, you stop writing.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/_KzEoq0XcHQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: core.async: communicating termination

[Brandon Bloom]

>> You're only supposed to close a channel from the producer side.
> Why?

First, an appeal to authority: http://golang.org/pkg/builtin/#close
Notice the type of the argument: chan<-
That's a write-only port. Go's type system allows automatic coercion from
read/write ports to constrained read or write only ports. However, you
can't coerce a constrained port back to an unconstrained one.

See also the discussion here:
https://groups.google.com/d/topic/golang-nuts/pZwdYRGxCIk/discussion

There are a few points discussed there, but in summary: It is a programming
error to write a message to a closed channel. "close" is not a resource
cleanup operation, it is a control signal. It "flows" in the same direction
as the messages sent on the channel itself. If the receiver were allowed to
close the channel, then the sender would have no way of avoiding a
closed/write race condition.

This brings up another issue: Currently writing to a closed channel is a
no-op, but it probably should throw an exception. Similarly, closing a
closed channel is a no-op, but also probably should throw an exception.
Both are things that a well behaved sender should never do, since they know
when they close, so they know not to keep putting stuff in there. Or, they
are warned of the impending close by some coordination process & the same
rules apply.

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

ClojureScript concurrency?

[Alexander Gunnarson]

One of Clojure's main selling points is the ability to implement 
concurrency in a fairly straightforward way. I know that ClojureScript 
doesn't support concurrency because JavaScript's VM doesn't support it. I 
mean, of course you can try to get around that by doing crazy tricks with 
asynchronous event loops and such, but really it only is *simulating* 
concurrency 
with no real speed advantage. My question to everyone is, when do you all 
think that the JavaScript VM will support concurrency? Will it ever support 
it?

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

Re: ClojureScript concurrency?

[Michał Marczyk]

At the risk of sounding pedantic, concurrency is not the same as
parallelism. Multiple threads can be scheduled on a single core (and
that's plenty useful). So, with the async stuff you mention,
JavaScript already supports concurrency. ClojureScript has recently
come to have particularly good support for it thanks to core.async.

As for parallelism, you can already do it with web workers. There are
limitations, but you can still do very cool things with them, cf. the
pedestal-app tutorial's web worker section:

https://github.com/pedestal/app-tutorial/wiki/Parallel-Processing

More thread-like (as opposed to process-like) models... Who knows.
Here's hoping.

Cheers,
Michał


On 13 July 2013 00:42, Alexander Gunnarson  wrote:
> One of Clojure's main selling points is the ability to implement concurrency
> in a fairly straightforward way. I know that ClojureScript doesn't support
> concurrency because JavaScript's VM doesn't support it. I mean, of course
> you can try to get around that by doing crazy tricks with asynchronous event
> loops and such, but really it only is simulating concurrency with no real
> speed advantage. My question to everyone is, when do you all think that the
> JavaScript VM will support concurrency? Will it ever support it?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: ClojureScript concurrency?

[Ben Mabey]

On Fri Jul 12 16:56:17 2013, Michał Marczyk wrote:

At the risk of sounding pedantic, concurrency is not the same as
parallelism. Multiple threads can be scheduled on a single core (and
that's plenty useful). So, with the async stuff you mention,
JavaScript already supports concurrency. ClojureScript has recently
come to have particularly good support for it thanks to core.async.

As for parallelism, you can already do it with web workers. There are
limitations, but you can still do very cool things with them, cf. the
pedestal-app tutorial's web worker section:

https://github.com/pedestal/app-tutorial/wiki/Parallel-Processing

More thread-like (as opposed to process-like) models... Who knows.
Here's hoping.

Cheers,
Michał


On 13 July 2013 00:42, Alexander Gunnarson  wrote:

One of Clojure's main selling points is the ability to implement concurrency
in a fairly straightforward way. I know that ClojureScript doesn't support
concurrency because JavaScript's VM doesn't support it. I mean, of course
you can try to get around that by doing crazy tricks with asynchronous event
loops and such, but really it only is simulating concurrency with no real
speed advantage. My question to everyone is, when do you all think that the
JavaScript VM will support concurrency? Will it ever support it?

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






To learn more Rob Pike gave a good presentation on 'Concurrency Is Not 
Parallelism': http://vimeo.com/49718712


-Ben

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Ntable dependecy table generator

[Kelker Ryan]

Ntable is a Clojure namespace dependency table generator. https://github.com/runexec/ntable Example output of command: java -jar ntable-0.1.0-SNAPSHOT-standalone.jar /src/chp/chp/src/chp/routes/example.clj
:use

chp.core
compojure.core
[chp.html :only [escape]]chp/src/chp/routes/user.clj
:use

chp.corechp/src/chp/routes/chp.clj
:use

chp.core
[cheshire.core :only [generate-string]]
[chp.api :only [api->where]]
[chp.builder :only [binding-exist?]]chp/src/chp/clean.cljchp/src/chp/migration.clj
:refer-clojure

:exclude
[complement alter drop bigint boolean char double float time]


:use

[chp.db :only [*db*]]
(lobos core connectivity migration)chp/src/chp/password.cljchp/src/chp/handler.clj
:use

compojure.core
chp.html
chp.template
[chp.core :exclude [korma-db]]
[chp.api :only [api->where api-dir]]
[chp.db :only [*db*]]
[garden.core :only [css]]


:require

chp.server
[compojure.route :as route]
[korma.db :as kdb]
[korma.core :as kc]
[noir.session :as session]
[chp.routes.chp :refer [chp-builder-paths]]
[chp.routes.example :refer [example-routes]]
[chp.routes.user :refer [user-table-routes]]chp/src/chp/html.clj
:require

hiccup.core
hiccup.util
hiccup.form
hiccup.elementchp/src/chp/server.cljchp/src/chp/api.clj
:use

[chp.db :only [*db*]]


:require

[korma.db :as kdb]
[korma.core :as kc]chp/src/chp/package.clj
:refer-clojure

:exclude
[bigint boolean char double float time]


:use

[chp.schema :only [load-schemas]]
[chp.migration :only [chp-migrate]]
[chp.module :only [mod-enable]]chp/src/chp/template.clj
:use

chp.corechp/src/chp/builder.clj
:use

[chp.db :only [*db*]]
[chp.core :exclude [korma-db]]
chp.html
chp.password
[chp.login :exclude [korma-db]]


:require

[korma.core :as kc]
[korma.db :as kdb]
[noir.session :as session]chp/src/chp/login.clj
:require

[korma.db :as kdb]
[korma.core :as kc]


:use

[chp.db :only [*db*]]
[chp.password :only [password]]chp/src/chp/core.clj
:use

compojure.core
[noir.session :only [wrap-noir-flash wrap-noir-session]]
[chp.db :only [*db*]]


:require

chp.server
[compojure.handler :as handler]
[clojure.string :as string]
[korma.db :as kdb]
[korma.core :as kc]chp/src/chp/generator.clj
:use

[chp.core :only [root-path]]chp/src/chp/module.clj
:require

[clojure.java.io :as io]chp/src/chp/db.cljchp/src/chp/schema.clj
:refer-clojure

:exclude
[bigint boolean char double float time]


:use

[chp.db :only [*db*]]
[lobos.core :only [create]]


 



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

run-jetty not working in a virtualbox vm?

[Daniel Higginbotham]

I'm trying to start a jetty server on a virtualbox vm (ubuntu 12.04 32 bit) 
by running the following:

(run-jetty #'app {:port (Integer. (get (System/getenv) "PORT" 8080)) :join? 
false})

However, I can't connect to the server. If I run "netstat -lp" the java 
process doesn't show up and it looks as if nothing's listening on 8080. 
 However, if I run the above run-jetty function again in a separate process 
I get the error message that another process is already bound to 8080.

The weirdest part of all this is that the very first time I tried starting 
the server, it did start and I was actually able to reach it, but it only 
worked that one time. Has anyone run into this? Is there any way to debug 
the problem?

Thanks!
Daniel

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

Re: ClojureScript concurrency?

[Alexander Gunnarson]

>
> To learn more Rob Pike gave a good presentation on 'Concurrency Is Not 
> Parallelism': http://vimeo.com/49718712 
>

Good video. Thanks for the link. 

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

Re: run-jetty not working in a virtualbox vm?

[gaz jones]

Just to check - you have set ":join? false" so the thread will not block
until the server ends - are you doing this intentionally and blocking the
thread elsewhere?


On Fri, Jul 12, 2013 at 8:45 PM, Daniel Higginbotham  wrote:

> I'm trying to start a jetty server on a virtualbox vm (ubuntu 12.04 32
> bit) by running the following:
>
> (run-jetty #'app {:port (Integer. (get (System/getenv) "PORT" 8080))
> :join? false})
>
> However, I can't connect to the server. If I run "netstat -lp" the java
> process doesn't show up and it looks as if nothing's listening on 8080.
>  However, if I run the above run-jetty function again in a separate process
> I get the error message that another process is already bound to 8080.
>
> The weirdest part of all this is that the very first time I tried starting
> the server, it did start and I was actually able to reach it, but it only
> worked that one time. Has anyone run into this? Is there any way to debug
> the problem?
>
> Thanks!
> Daniel
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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