Re: Question about Clojure function naming

[Atamert Ölçgen]

>
> why Clojure chose to name functions operating on refs and atoms so
> differently


swap! is not an alter on atoms. And vice versa.

reset! is not a ref-set on atoms. And vice versa.

The analogous functions names would make remembering which is which easier.


Are you having trouble remembering them?



On Fri, Feb 19, 2016 at 7:04 AM, Tianxiang Xiong 
wrote:

> I'm currently reading Practical Clojure
>  by VanderHart and Sierra, and am on
> the section about state management.
>
> I'm curious why Clojure chose to name functions operating on refs and
> atoms so differently. As I understand it,
>
> swap! -> atoms, alter -> refs
> reset! -> atoms, ref-set -> refs
>
> Why "swap!" and "reset!", instead of "atom-alter" and "atom-set"? The
> analogous functions names would make remembering which is which easier.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: Brief Clojars outage in ~5 hours

[Chris Ford]

Thanks for being vigilant, Toby, and for keeping us informed.

On 19 February 2016 at 02:06, Toby Crawley  wrote:

> This maintenance has been completed.
>
> Let us know if you see any issues:
> https://github.com/clojars/clojars-web/wiki/Contact
>
> On Thu, Feb 18, 2016 at 3:43 PM, Toby Crawley  wrote:
> > In a little over five hours, we'll be rebooting the server hosting
> > clojars.org in order to apply the update for the glibc vulnerability
> > that was recently announced[1]. The downtime should be no more than
> > five minutes. The reboot will happen at 2016-02-19 02:00 UTC[2].
> >
> > Let me know if you have any issues or questions.
> >
> > - Toby
> >
> > [1]:
> https://threatpost.com/critical-glibc-vulnerability-puts-all-linux-machines-at-risk/116261/
> > [2]: for your local time, see
> > https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160219T02
>
> --
> You received this message because you are subscribed to the Google Groups
> "clojars-maintainers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojars-maintainers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Unexpected behavior of bidi.ring/make-handler function when using nginx-clojure-embed.

[Arturas Kveselis]

Hi,

I've tried to play with bidi using embedded nginx server and faced this 
problem:
Noticed that if I'm calling ring handler function directly, request map I'm 
receiving is correct, but then calling the same handler using bidi's 
routing map and make-handler function, reques map gets partly destroyed.
I suppose it's something to do with request type of nginx server whitch is 
of the nginx.clojure.clj.LazyRequestMap type, while for example jetty 
returns clojure.lang.PersistentHashMap.


Test code:
(defn index-handler [req]
  {:body (with-out-str (clojure.pprint/pprint req))})

(def routes
  ["/" {"" index-handler}])

(def bidi-handler
  (bidi.ring/make-handler routes))

;(def my-app index-handler)
(def my-app bidi-handler)

(nginx.clojure.embed/run-server my-app {:port 8181})



I'm getting this request map using make-handler:
{:body nil,
 :server-port "8181",
 :remote-addr "127.0.0.1",
 :scheme "http",
 :content-type nil,
 :websocket? false,
 :route-params nil}

This is request map using index-handler directly:
{:uri "/",
 :body nil,
 :headers
 {"Host" "localhost:8181",
  "Connection" "keep-alive",
  "Cache-Control" "max-age=0",
  "Accept"
  
"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
  "Upgrade-Insecure-Requests" "1",
  "User-Agent"
  "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/48.0.2564.109 Safari/537.36",
  "Accept-Encoding" "gzip, deflate, sdch",
  "Accept-Language"
  
"nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en-US;q=0.2,en;q=0.2,da;q=0.2,lt;q=0.2,sv;q=0.2,ceb;q=0.2",
  "Cookie"
  "__utma=111872281.1858584428.1455043971.1455043971.1455043971.1; 
__utmc=111872281; 
__utmz=111872281.1455043971.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)"},
 :server-port "8181",
 :server-name "",
 :remote-addr "127.0.0.1",
 :query-string nil,
 :scheme "http",
 :request-method :get,
 :content-type nil,
 :character-encoding nil,
 :websocket? false}

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

Re: Question about Clojure function naming

[Gary Verhaegen]

I'd say only Rich Hickey can really answer these questions, but here is one
possible explanation.

These functions are not equivalent. Just like 'send' on an agent has
fundamental differences with 'swap!', 'alter' has fundamental differences
with both. There is also some similarity, of course: in all three cases,
the intent is to "update" the "current" value by supplying a transformation
function, but:

* 'swap!' will happen immediately, in the current thread, with no regard
for whatever else happens;
* 'send' will happen at some point in the (hopefully near) future on a
different thread;
* 'alter' can only be used within a transaction and will do some complex
magic to coordinate changes to multiple refs.

Bear in mind that Clojure is built on top of a polymorphic foundation, so
names like "atom-swap!" and "ref-swap!" would not really make sense; if the
point was to call them the same, they could just be called the same, like
'conj' is the same for all data structures, and like 'deref', which does
have the same semantics for atoms, refs, and agents, is called the same for
the three of them.

In short, one possible explanation is that they were deemed sufficiently
different to warrant a different name.

On Friday, 19 February 2016, Atamert Ölçgen  wrote:

> why Clojure chose to name functions operating on refs and atoms so
>> differently
>
>
> swap! is not an alter on atoms. And vice versa.
>
> reset! is not a ref-set on atoms. And vice versa.
>
> The analogous functions names would make remembering which is which easier.
>
>
> Are you having trouble remembering them?
>
>
>
> On Fri, Feb 19, 2016 at 7:04 AM, Tianxiang Xiong <
> tianxiang.xi...@gmail.com
> > wrote:
>
>> I'm currently reading Practical Clojure
>>  by VanderHart and Sierra, and am
>> on the section about state management.
>>
>> I'm curious why Clojure chose to name functions operating on refs and
>> atoms so differently. As I understand it,
>>
>> swap! -> atoms, alter -> refs
>> reset! -> atoms, ref-set -> refs
>>
>> Why "swap!" and "reset!", instead of "atom-alter" and "atom-set"? The
>> analogous functions names would make remembering which is which easier.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> 
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

surprising behaviour from dissoc on records

[Stig Brautaset]

Dissoc behaviour on records really surprised me:

user> (defrecord Foo [bar])
;; => user.Foo
user> (def foo (->Foo nil))
;; => #'user/foo
user> (dissoc foo :bar)
;; => {}
user> (assoc foo :bar nil)
;; => #user.Foo{:bar nil}

It lead to a bug where a component of mine, which I was using to
dispatch in a multimethod was replaced with an empty map:

https://github.com/stig/accounts/commit/f4124b69cfc9fdc201b29f97e33a5b7bd6279e7f

*toy project alert*

As an aside, I'm now starting to understand why all the components
examples use `assoc foo :bar nil` rather than dissoc...

Stig

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

[GSoC Idea] Distributed Load Testing Tool in Clojure

[Markus Hjort]

*Brief explanation:* Clojure as a language is a good choice for writing 
readable load test scenarios. Core libraries and runtime are well suited 
for doing highly parallel computation while lazy sequences and transducers 
are effective for doing calculations on big data structures. All of these 
properties are required in load testing. At the moment all the load testing 
solutions for Clojure at least partly utilize tools from other languages. 
Pure Clojure solution for this problem could be simpler and more concise.

*Expected results:* a Clojure tool for distributed load testing

*Knowledge prerequisites:* Clojure, performance tuning, Cloud computing

*Mentor:* Markus Hjort

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

How to compile with optimizations none when using web workers

[William la Forge]

Compiling with optimizations none is no doubt quite handy, especially in 
conjunction with source maps, as a traceback will take you to the line of 
code causing the problems, and with the same variable names used in your 
original clojurescript code. But this is not currently possible for .jc 
files used by web workers as the unoptimized .js file contains a reference 
to js/window--and window does not exist in a web worker.


You should still be able to use optimizations none with your main 
javascript code, but you will need to compile your main code and your web 
worker code separately so that you can use different optimizations as 
appropriate. And you can do this so long as your not using shared workers. 
The question then is, how to compile the .js files separately.

The duracell  demo 
uses a web worker AND is itself compiled with optimizations none. There are 
two things done to accomplish this:

   1. Duracell itself has no web worker code. Though it uses a library, 
   durable-cells , which includes 
   a web worker.
   2. In the duracell build.boot 
    file, 
   the dev task uses pandeiro/boot-http 
    rather than the simpler 
   tailrecursion/boot-jetty . 
   The advantage to using boot-http is that it supports the loading of static 
   files from library jar files. In this case, that means the main code in 
   aaworker can create a web worker using durable-cell's dcells.js file.

So how does the durable-cells library create the dcells.js file? Again, 
there are two things done to accomplish this:

   1. In the durable-cells build.boot 
    file, 
   the dev task includes (cljs :optimizations :simple). This invokes the 
   compiler with an appropriate level of optimizations.
   2. But we still need to define the .js file. This is done in the 
   dcells.cljs.edn 
   

 file. 
   See Multiple Builds 
    for 
   more information on cljs.edn files.

>From https://github.com/aatree/aaworker/wiki/Compiling-with-Optimizations-None

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

Re: [GSoC Idea] Distributed Load Testing Tool in Clojure

[Alex Miller]

I added this to the page - thanks Markus!

On Friday, February 19, 2016 at 9:49:51 AM UTC-6, Markus Hjort wrote:
>
> *Brief explanation:* Clojure as a language is a good choice for writing 
> readable load test scenarios. Core libraries and runtime are well suited 
> for doing highly parallel computation while lazy sequences and transducers 
> are effective for doing calculations on big data structures. All of these 
> properties are required in load testing. At the moment all the load testing 
> solutions for Clojure at least partly utilize tools from other languages. 
> Pure Clojure solution for this problem could be simpler and more concise.
>
> *Expected results:* a Clojure tool for distributed load testing
>
> *Knowledge prerequisites:* Clojure, performance tuning, Cloud computing
>
> *Mentor:* Markus Hjort
>

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

Re: surprising behaviour from dissoc on records

[Alex Miller]

You can find some of the background for this 
at http://clojure.org/reference/datatypes. Records are intended to capture 
"application domain information" - where the fields are known. Dissoc'ing 
means you are removing not just a value, but the whole "field", and the 
implication here is that you devolve from a thing of that "type" to a plain 
map. Similarly, "empty" is not implemented on records (because you then 
remove all the "fields").

This is an intentional choice made by Rich in the design of records. I 
think it's reasonable to argue that this creates some surprises in the use 
of records - particularly in dissoc and empty. Afaik there is no plan for 
this behavior to change, however.



On Friday, February 19, 2016 at 8:30:47 AM UTC-6, Stig Brautaset wrote:
>
>
> Dissoc behaviour on records really surprised me: 
>
> user> (defrecord Foo [bar]) 
> ;; => user.Foo 
> user> (def foo (->Foo nil)) 
> ;; => #'user/foo 
> user> (dissoc foo :bar) 
> ;; => {} 
> user> (assoc foo :bar nil) 
> ;; => #user.Foo{:bar nil} 
>
> It lead to a bug where a component of mine, which I was using to 
> dispatch in a multimethod was replaced with an empty map: 
>
>
> https://github.com/stig/accounts/commit/f4124b69cfc9fdc201b29f97e33a5b7bd6279e7f
>  
>
> *toy project alert* 
>
> As an aside, I'm now starting to understand why all the components 
> examples use `assoc foo :bar nil` rather than dissoc... 
>
> Stig 
>
>

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

[ANN] trapperkeeper-webserver-jetty9 v1.5.1 released

[Chris Price]

Today we did a new release of puppetlabs/trapperkeeper-webserver-jetty9 to
clojars.  trapperkeeper-webserver-jetty9 is the main webserver component
for use with our "trapperkeeper" service framework.

The new release is version 1.5.1, and it includes a fix for a memory leak
that would be triggered if you restart your application via Trapperkeeper's
recently-added support for HUP signals (added in TK 1.3.0).

trapperkeeper-webserver-jetty9 on clojars:

https://clojars.org/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper-webserver-jetty9 source code:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper docs:

https://github.com/puppetlabs/trapperkeeper/wiki

trapperkeeper source code:

https://github.com/puppetlabs/trapperkeeper

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

Re: surprising behaviour from dissoc on records

[Beau Fabry]

Interesting. I think it makes sense in that `dissoc` is a function for 
removing a kv pair from a map, not a function for setting v to nil given a 
k. I could definitely see tripping up on this though.

On Friday, February 19, 2016 at 8:07:16 AM UTC-8, Alex Miller wrote:
>
> You can find some of the background for this at 
> http://clojure.org/reference/datatypes. Records are intended to capture 
> "application domain information" - where the fields are known. Dissoc'ing 
> means you are removing not just a value, but the whole "field", and the 
> implication here is that you devolve from a thing of that "type" to a plain 
> map. Similarly, "empty" is not implemented on records (because you then 
> remove all the "fields").
>
> This is an intentional choice made by Rich in the design of records. I 
> think it's reasonable to argue that this creates some surprises in the use 
> of records - particularly in dissoc and empty. Afaik there is no plan for 
> this behavior to change, however.
>
>
>
> On Friday, February 19, 2016 at 8:30:47 AM UTC-6, Stig Brautaset wrote:
>>
>>
>> Dissoc behaviour on records really surprised me: 
>>
>> user> (defrecord Foo [bar]) 
>> ;; => user.Foo 
>> user> (def foo (->Foo nil)) 
>> ;; => #'user/foo 
>> user> (dissoc foo :bar) 
>> ;; => {} 
>> user> (assoc foo :bar nil) 
>> ;; => #user.Foo{:bar nil} 
>>
>> It lead to a bug where a component of mine, which I was using to 
>> dispatch in a multimethod was replaced with an empty map: 
>>
>>
>> https://github.com/stig/accounts/commit/f4124b69cfc9fdc201b29f97e33a5b7bd6279e7f
>>  
>>
>> *toy project alert* 
>>
>> As an aside, I'm now starting to understand why all the components 
>> examples use `assoc foo :bar nil` rather than dissoc... 
>>
>> Stig 
>>
>>

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

Anyone going to Clojure West?

[Kester Browne]

Try to find out if anyone from the DC area is going to Clojure West?

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

Re: How to compile with optimizations none when using web workers

[Thomas Heller]

Hello,

I'm not quite sure what you are saying here since I do not know boot or 
hoplon or durable-cells.

I can however suggest a "better" solution for Workers: Using Closure 
Modules.

CLJS or boot do not implement them for :none at the moment but shadow-build 
does. I also have a few extra hints for web-worker support but first let me 
try to explain why you want to use modules.

If you do a separate build for your worker and your main app you'll have to 
download 2 full builds. Meaning that your main.js file will contain an 
implementation of cljs.core and the worker.js will contain a different one. 
If you are on :none they will share some parts, but :advanced will share 
nothing. This is bad as you want to keep the scripts to download to a 
minimum.

So how would the ideal solution look like:

1) base.js for all common code (eg. cljs.core)
2) app.js for all the app code
3) worker.js for all the worker related code

2+3 both share the base.js, you can add more workers trivially. IMHO the 
best way to organize this from a code perspective is to have a separate 
namespace for each worker as well as the app, where the app should not 
depend on the worker or vice versa.

Since this is only one build now, you only need to worry about one compile 
as well.

I have a demo repo here:
https://github.com/thheller/worker-example

First we have the code:
https://github.com/thheller/worker-example/tree/master/src/cljs/demo/app.cljs
https://github.com/thheller/worker-example/tree/master/src/cljs/demo/worker1.cljs

Each is a self contained namespace that just does some trivial stuff.

The :none output is a bit confusing but lets look at the :advanced output:

https://github.com/thheller/worker-example/blob/advanced/demo/js/demo.js
https://github.com/thheller/worker-example/blob/advanced/demo/js/worker1.js

Each is only the very minimum of code, the worker1.js will automatically 
load the base.js which means it shares all of the code in base.js with the 
page itself. There will be not additional download as the browser has 
already downloaded it when loading the page (since it included base.js and 
demo.js). The :none build basically does the same thing just in a closure 
compliant way. No duplicate file downloads will happen.

Everything is compiled using shadow-build, I can go into further detail on 
how if anyone is interested. I just wanted to make the point that web 
workers should *ALWAYS* be used via closure modules, it is just the most 
efficient way to organise the code and output.

Just my 2 cents,
/thomas







On Friday, February 19, 2016 at 4:54:59 PM UTC+1, William la Forge wrote:
>
> Compiling with optimizations none is no doubt quite handy, especially in 
> conjunction with source maps, as a traceback will take you to the line of 
> code causing the problems, and with the same variable names used in your 
> original clojurescript code. But this is not currently possible for .jc 
> files used by web workers as the unoptimized .js file contains a reference 
> to js/window--and window does not exist in a web worker.
>
>
> You should still be able to use optimizations none with your main 
> javascript code, but you will need to compile your main code and your web 
> worker code separately so that you can use different optimizations as 
> appropriate. And you can do this so long as your not using shared workers. 
> The question then is, how to compile the .js files separately.
>
> The duracell  demo 
> uses a web worker AND is itself compiled with optimizations none. There are 
> two things done to accomplish this:
>
>1. Duracell itself has no web worker code. Though it uses a library, 
>durable-cells , which 
>includes a web worker.
>2. In the duracell build.boot 
> file, 
>the dev task uses pandeiro/boot-http 
> rather than the simpler 
>tailrecursion/boot-jetty . 
>The advantage to using boot-http is that it supports the loading of static 
>files from library jar files. In this case, that means the main code in 
>aaworker can create a web worker using durable-cell's dcells.js file.
>
> So how does the durable-cells library create the dcells.js file? Again, 
> there are two things done to accomplish this:
>
>1. In the durable-cells build.boot 
> file, 
>the dev task includes (cljs :optimizations :simple). This invokes the 
>compiler with an appropriate level of optimizations.
>2. But we still need to define the .js file. This is done in the 
>dcells.cljs.edn 
>
> 
>  file. 
>See Multiple Builds 
>

Re: How to compile with optimizations none when using web workers

[William la Forge]

Thomas,

Modules looks quite exciting. I would be glad to help in developing a boot 
task for same.

Bill 

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

Re: How to compile with optimizations none when using web workers

[William la Forge]

Thomas,

Have you seen this? A simple demo using workers in 
clojurescript: https://github.com/MarcoPolo/Servant
I've converted the demo to use 
boot: https://github.com/aatree/aademos/tree/master/servant-demo


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

Re: How to compile with optimizations none when using web workers

[William la Forge]

Thomas,

Your worker demo includes the entire cljs runtime as part of the 
project? 
https://github.com/thheller/worker-example/tree/master/demo/js/cljs-runtime

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

Re: Question about Clojure function naming

[Tianxiang Xiong]

Yes, as I'm reading further into the book I am coming to understand more 
about the differences between the ref, atom, and agent types. I am 
beginning to see that swap! is not an alter on atoms, etc. The way the book 
presents the information, though, strongly suggests parallels.

Consistency is a virtue, and patterns help memorization. If there are 
parallels in usage, there should be parallels in name. As Phil Karlton 
pointed out, naming things is hard; and it's hard in large part because 
names should convey meaning, not just serve as arbitrary labels.

On Friday, February 19, 2016 at 5:30:00 AM UTC-6, Atamert Ölçgen wrote:
>
> why Clojure chose to name functions operating on refs and atoms so 
>> differently
>
>
> swap! is not an alter on atoms. And vice versa.
>
> reset! is not a ref-set on atoms. And vice versa.
>
> The analogous functions names would make remembering which is which easier.
>
>
> Are you having trouble remembering them?
>
>
>
> On Fri, Feb 19, 2016 at 7:04 AM, Tianxiang Xiong  > wrote:
>
>> I'm currently reading Practical Clojure 
>>  by VanderHart and Sierra, and am 
>> on the section about state management. 
>>
>> I'm curious why Clojure chose to name functions operating on refs and 
>> atoms so differently. As I understand it,
>>
>> swap! -> atoms, alter -> refs
>> reset! -> atoms, ref-set -> refs
>>
>> Why "swap!" and "reset!", instead of "atom-alter" and "atom-set"? The 
>> analogous functions names would make remembering which is which easier.
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
>

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

Clojure glosary

[Tianxiang Xiong]

Is there a better, more comprehensive Clojure glossary than the Clojure-Docs 

 
one? While fairly good, it's not comprehensive, and has not been updated in 
several years.

I'd like a canonical go-to reference if I forget the definition of 
something.

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

Re: Clojure glosary

[Juvenn Woo]

Hi Tianxiang, there is Clojure cheatsheet that may be helpful to you: 
http://jafingerhut.github.io/cheatsheet/grimoire/cheatsheet-tiptip-cdocs-summary.html
 

Best,
-- 
Juvenn Woo
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Saturday, 20 February 2016 at 10:39 AM, Tianxiang Xiong wrote:

> Is there a better, more comprehensive Clojure glossary than the Clojure-Docs 
> (https://github.com/clojuredocs/guides/blob/master/articles/language/glossary.md)
>  one? While fairly good, it's not comprehensive, and has not been updated in 
> several years.
> 
> I'd like a canonical go-to reference if I forget the definition of something. 
> 
> -- 
> 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 
> (mailto: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 
> (mailto: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 
> (mailto:clojure+unsubscr...@googlegroups.com).
> For more options, visit https://groups.google.com/d/optout.

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

[ANN] paren-soup 1.0, now with parinfer

[Zach Oakes]

This is a new release of paren-soup, a browser-based ClojureScript editor 
for people who think CodeMirror is too stable and performant for their 
taste. I gutted my embarrassing paren completion and auto-indentation code 
to make it use the amazing Parinfer library instead. I also added a some 
support for undo/redo. Please direct all bug reports to whoever designed 
contenteditable.

Code: https://github.com/oakes/paren-soup
Demo: http://oakes.github.io/paren-soup/

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

Re: Clojure glosary

[Tianxiang Xiong]

Thanks, but a cheatsheet is not really what I'm looking for. The cheatsheet 
lists commands grouped by function, which is useful, but I'm looking for 
rigorous, precise definitions of terms like "var" and "identity".

On Friday, February 19, 2016 at 9:22:24 PM UTC-6, juvenn wrote:
>
> Hi Tianxiang, there is Clojure cheatsheet that may be helpful to you: 
> http://jafingerhut.github.io/cheatsheet/grimoire/cheatsheet-tiptip-cdocs-summary.html
>  
>
> Best,
> -- 
> Juvenn Woo
> Sent with Sparrow 
>
> On Saturday, 20 February 2016 at 10:39 AM, Tianxiang Xiong wrote:
>
> Is there a better, more comprehensive Clojure glossary than the 
> Clojure-Docs 
> 
>  
> one? While fairly good, it's not comprehensive, and has not been updated in 
> several years.
>
> I'd like a canonical go-to reference if I forget the definition of 
> something.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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