Re: Navigators and lenses

2017-03-09 Thread Mark Engelberg
Just finished reading through Racket's lens library to compare.  Specter
can do everything that Racket's lens library can do, but the converse is
not true.  Specter's navigators can do more than lenses.

The lens-like navigators are the most obviously useful parts of Specter,
and maybe for some people that's all they need and they would prefer to
hide the other functionality.  If so, it looks to me like it would be
trivial to build a lens library like Racket's out of Specter, and it would
almost certainly be higher performance than the "obvious" implementation of
lenses.

But I don't agree at all with the claim that Specter is some sort of
offbeat, ill-researched version of lenses.  It is something more advanced.
If Nathan had constrained his thinking to these other approaches, Specter
wouldn't have such richness of functionality and pragmatic performance
considerations.


On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom 
wrote:

> Responsible adults sometimes needs to access and modify deeply nested data
>> structures
>
>
> So far, my experience has been that it is almost always better to build a
> pair of flattening and unflattening transforms on the data. Especially
> since you frequently want only one flattening, but potentially many
> un-flattenings. The "unflattened" form (aka "documents") is usually an
> end-point where data goes to die; assuming it isn't immediately displayed
> on the screen.
>
> However, having said that, path-dependent / context-sensitive query is a
> very rich and interesting space that does have meaningful utility,
> especially in the context of graph-like datasets. This is especially true
> when combined with some kind of algebra for unioning/intersecting/etc. I'm
> also interested in this sort of thing for programmable user-interface use
> cases: Think text editors with multiple-cursors.
>
> I think experimentation is in order
>>
>
> Agreed. Here's some starting points for pre-hammock reading/viewing
> materials:
>
> *Tree Traversal *
>
>- XPath: https://www.w3.org/TR/xpath/
>- CSS: https://www.w3.org/TR/css3-selectors/
>
> *Richer Tree Querying*
>
>- XQuery: https://www.w3.org/TR/xquery/
>- jQuery: https://api.jquery.com
>
> *Second-Class "Generalized References" (nee "L-values")*
>
>- Common Lisp: http://www.lispworks.com/documentation/lw50/CLHS/
>Body/05_a.htm
>- C/C++: http://eli.thegreenplace.net/2011/12/15/
>understanding-lvalues-and-rvalues-in-c-and-c
>
> 
>
> *Lenses in Other Languages*
>
>- Haskell: https://skillsmatter.com/skillscasts/4251-lenses-
>compositional-data-access-and-manipulation
>
> 
>(great overview of key concepts!)
>- Racket: https://docs.racket-lang.org/lens/index.html
>
> *Graph Querying*
>
>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: Ensure more concurrency

2017-03-09 Thread 'bertschi' via Clojure
Thanks for your comments. As suggested I ran a small benchmark of both 
versions. Turns out that the difference between (ref-set ref @ref) and 
ensure is huge ...

(defn write-skew [de-ref]
  (let [cats (ref 1)
dogs (ref 1)

john (future
   (dosync
 (when (< (+ @cats (de-ref dogs)) 3)
   (alter cats inc
mary (future
   (dosync
 (when (< (+ (de-ref cats) @dogs) 3)
   (alter dogs inc]
(do @john @mary)
(dosync
 (> (+ @cats @dogs) 3

user> (bench/with-progress-reporting
(bench/bench (write-skew (fn [x] (ref-set x @x))) :verbose))
Warming up for JIT optimisations 100 ...
  compilation occurred before 18580 iterations
Estimating execution count ...
Sampling ...
Final GC...
Checking GC...
Finding outliers ...
Bootstrapping ...
Checking outlier significance
amd64 Linux 3.16.0-4-amd64 4 cpu(s)
OpenJDK 64-Bit Server VM 24.121-b00
Runtime arguments: -Dfile.encoding=UTF-8 -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 -XX:-OmitStackTraceInFastThrow 
-Dclojure.compile.path=/home/bertschi/GitRepos/Vorlesungen/PS2/target/classes 
-Dps2.version=0.0.0 -Dclojure.debug=false
Evaluation count : 1675560 in 60 samples of 27926 calls.
  Execution time sample mean : 37,327714 µs
 Execution time mean : 37,325021 µs
Execution time sample std-deviation : 1,137506 µs
Execution time std-deviation : 1,147482 µs
   Execution time lower quantile : 34,971387 µs ( 2,5%)
   Execution time upper quantile : 39,511899 µs (97,5%)
   Overhead used : 12,902114 ns
nil

user> (bench/with-progress-reporting
(bench/bench (write-skew ensure)))
Warming up for JIT optimisations 100 ...
  compilation occurred before 40 iterations
  compilation occurred before 61 iterations
Estimating execution count ...
Sampling ...
Final GC...
Checking GC...
Finding outliers ...
Bootstrapping ...
Checking outlier significance
Evaluation count : 60 in 60 samples of 1 calls.
 Execution time mean : 1,662454 sec
Execution time std-deviation : 1,906919 sec
   Execution time lower quantile : 186,394000 µs ( 2,5%)
   Execution time upper quantile : 7,630998 sec (97,5%)
   Overhead used : 12,902114 ns

Found 4 outliers in 60 samples (6,6667 %)
low-severe 2 (3, %)
low-mild 2 (3, %)
 Variance from outliers : 98,3142 % Variance is severely inflated by 
outliers
nil

I'm running clojure 1.8.0 by the way. According to VisualVM the (ref-set 
ref @ref) version spends most of its time in 
clojure.lang.LockingTransaction$RetryEx. () while ensure gets 
basically stuck (> 99%) at clojure.lang.LockingTransaction.tryWriteLock ().

Am Mittwoch, 8. März 2017 14:40:01 UTC+1 schrieb Herwig Hochleitner:
>
> 2017-03-06 12:06 GMT+01:00 'bertschi' via Clojure  >: 
>
> > From the docs it says "Allows for more concurrency than (ref-set ref 
> @ref)". 
> > I would read that as "runs at least as fast as (ref-set ref @ref)", but 
> > using (ref-set dogs @dogs) instead of (ensure dogs) and the same with 
> cats, 
> > does not exhibit these occasional runtime spikes. 
> > 
> > Am I misunderstanding something or is it a bug in ensure? 
>
> If ensure does indeed show worse (or not even better) performance than 
> (ref-set ref @ref) in benchmarks, it certainly would go against my 
> understanding of clojure's STM and I'd consider this a bug (since 
> ensure could just be implemented by ref-set for a free performance 
> boost, in this case). 
>
> To show this behavior and move this along into a ticket, it would be 
> helpful to run those two examples in a microbenchmark runner, like 
> criterium and attach a profiler to uncover locking problems and 
> excessive retries, that would likely be the root cause. 
>

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


Compiling a library with direct-linking

2017-03-09 Thread Shantanu Kumar
Hi,

As per Clojure 1.8 release info [1][2] "As of Clojure 1.8, the Clojure core 
library itself is compiled with direct linking." I want to know whether it 
is possible to compile a 3rd-party Clojure library with direct-linking - 
does it require AOT compilation? I know about the 
`-Dclojure.compiler.direct-linking=true` flag for applications, but has 
anybody tried to compile a redistributable library with direct-linking 
enabled?

[1] https://clojure.org/reference/compilation#directlinking
[2] 
https://github.com/clojure/clojure/blob/master/changes.md#11-direct-linking


Shantanu

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


2017: Call for participation

2017-03-09 Thread timmolderez

--
 * 2017* : The Art, Science, and Engineering of Programming

   April 3-6, 2017, Brussels, Belgium
   http://2017.programming-conference.org
--

We are excited to welcome you to  2017, a new conference 
focused on everything to do with programming. It takes place at the Vrije 
Universiteit Brussel, Belgium on April 3-6. The  conference is 
closely associated with the open-access journal "The Art, Science, and 
Engineering of Programming".  The journal's first two issues form the 
conference's research track, which means you can freely access all papers 
presented at the conference before it even starts! Along with the research 
track,  2017 features a program with two main keynotes, two 
symposia, eight workshops, a coding dojo, a demo track, and a student 
research competition.

To catch a glimpse of what  2017 has to offer, feel free to 
have a look at our overview video:
https://www.youtube.com/watch?v=GM_hLNW4ioE

***
 Program highlights
***

Main conference:
 - Keynote: "Live Literate Programming" by Gilad Bracha
 - Keynote: "How Racket Went Meta" by Matthew Flatt
 - Research track: 18 full papers
 - Demonstrations: 10 tool demos
 - ACM Student Research Competition: 8 entries

Co-located events:
 - 10th European Lisp Symposium: 2 keynotes by Hans Hübner and Bohdan 
Khomtchouk, ~18 papers (not final yet)
 - Modularity 2017: 8 invited talks by Jörg Kienzle, Shmuel Katz, Mira 
Mezini, Bedir Tekinerdogan, Stéphane Ducasse, Uwe Aßmann, Lodewijk Bergmans 
and Mario Südholt
 - CoCoDo - RainCode Labs Compiler Coding Dojo: code together with experts 
Adrian Johnstone, Elizabeth Scott, Robby Findler, and more to come!
 - LASSY - Workshop on Live Adaptation of Software SYstems
 - MiniPLoP - Mini Pattern Languages of Programs writers' workshop
 - MOMO - Workshop on Modularity in Modeling
 - MoreVMs - Workshop on Modern Language Runtimes, Ecosystems, and VMs
 - PASS - Workshop on Programming Across the System Stack
 - PX - Workshop on Programming Experience
 - ProWeb - Programming Technology for the Future Web
 - Salon des Refusés workshop

Social events:
 - Beer reception at the conference venue (April 3rd)
 - Reception at the Musical Instruments Museum (April 4th)
 - Banquet at the Natural Sciences Museum (April 5th)

***
 Registration, attendance and accommodation
***

 - You can register for  2017 at: 
http://2017.programming-conference.org/attending/registration
 - Early registration ends soon! Please register before March 13th to 
obtain the early-bird discount.
 - More information on attending the conference is available at: 
http://2017.programming-conference.org/attending/reaching-the-conference
 - More information on accommodation is available at: 
http://2017.programming-conference.org/attending/accomodation

***
 About Brussels
***

Brussels is the capital of Belgium, and home to the headquarters of the 
European Union. Despite its European nature and all the different languages 
spoken on every street corner, Brussels still has a very "village-like"  
character. It's well known for its Grand-Place, its Atomium, its 
Manneken-Pis, its Gueuze and its Kriek, its waffles and its chocolates. Be 
sure to take some time off to soak up the special atmosphere of its many 
different districts: Take a stroll to Rue Dansaert, Halles Saint-Géry, and 
Place Sainte-Catherine. Head for Saint-Boniface, Châtelain, or Flagey. In 
other words, go ahead and relish Brussels, a fine and beautiful city to 
explore and discover.

--

For more information, please visit http://2017.programming-conference.org
You can also find us on Twitter (twitter.com/programmingconf) and Facebook (
facebook.com/programmingconf)

Looking forward to see you in Brussels,

Theo D'Hondt (General chair), Wolfgang De Meuter (Organizing chair), Crista 
Lopes (Program chair), Jörg Kienzle, Ralf Lämmel, Hidehiko Masuhara, Tim 
Molderez, Tobias Pape, and Jennifer Sartor

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

Compiling a library with direct-linking

2017-03-09 Thread Alex Miller
Yes, you can compile and release a library that is AOT and direct linked.

-- 
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: Navigators and lenses

2017-03-09 Thread Edwin Watkeys
Alex,

I deeply appreciate the diligent virtue policing, but I don't think calling 
out the Comité de salut public is necessary. There was no attack: I'm much 
more a Nathan than a Rich person. The world needs both kinds of people. For 
me, Clojure would have simply been Yet Another Lisp had Nathan not put 
together Cascalog back in 2010. Yin and Yang.

Given that Rich is the BDFL of Clojure and Clojure is an art project, as 
someone recently wrote, issues of style are far from irrelevant when 
discussing what should be in or out of Clojure proper.

Edwin

On Wednesday, March 8, 2017 at 10:34:10 PM UTC-5, Alex Miller wrote:
>
> Edwin, we can have technical discussions about this topic without 
> comparing Nathan to Rich or making comments about Nathan that may feel like 
> a personal attack.
>
> Thanks
>

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


Re: Navigators and lenses

2017-03-09 Thread Edwin Watkeys
puzzler,

I guess I haven't said this, but I think it's worth saying that I have 
nothing against Specter. Godspeed to people who want to use it. And I don't 
think it should be judged against some other facility in another language; 
human progress would cease if for every Y, Y has to be a better X than X. 
Lenses, though, are one way that humans have tried to cope with accessing 
and updating nested data structures, and they're worth thinking about. 
Rich's hammock driven development talk influenced me powerfully because his 
espoused methodology ran so counter to my code-first-think-later instincts, 
and so I have the zeal of the converted with respect to the "do some 
research" step of HDD.

What you point out—the power and expressiveness of Specter—some people 
might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
with the 90% of situations where something like Specter might be used and 
making them as ridiculously simple and Clojure-y as possible. That 90% of 
usage maps to, in my experience, maybe 25% of the feature set of Specter. 
(YMMV, of course.) I want to facilitate the writing of code that a typical 
Clojure developer will intuitively understand.

Edwin

On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>
> Just finished reading through Racket's lens library to compare.  Specter 
> can do everything that Racket's lens library can do, but the converse is 
> not true.  Specter's navigators can do more than lenses.
>
> The lens-like navigators are the most obviously useful parts of Specter, 
> and maybe for some people that's all they need and they would prefer to 
> hide the other functionality.  If so, it looks to me like it would be 
> trivial to build a lens library like Racket's out of Specter, and it would 
> almost certainly be higher performance than the "obvious" implementation of 
> lenses.
>
> But I don't agree at all with the claim that Specter is some sort of 
> offbeat, ill-researched version of lenses.  It is something more advanced.  
> If Nathan had constrained his thinking to these other approaches, Specter 
> wouldn't have such richness of functionality and pragmatic performance 
> considerations.  
>
>
> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  > wrote:
>
>> Responsible adults sometimes needs to access and modify deeply nested 
>>> data structures
>>
>>
>> So far, my experience has been that it is almost always better to build a 
>> pair of flattening and unflattening transforms on the data. Especially 
>> since you frequently want only one flattening, but potentially many 
>> un-flattenings. The "unflattened" form (aka "documents") is usually an 
>> end-point where data goes to die; assuming it isn't immediately displayed 
>> on the screen.
>>
>> However, having said that, path-dependent / context-sensitive query is a 
>> very rich and interesting space that does have meaningful utility, 
>> especially in the context of graph-like datasets. This is especially true 
>> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
>> also interested in this sort of thing for programmable user-interface use 
>> cases: Think text editors with multiple-cursors.
>>
>> I think experimentation is in order
>>>
>>
>> Agreed. Here's some starting points for pre-hammock reading/viewing 
>> materials:
>>
>> *Tree Traversal *
>>
>>- XPath: https://www.w3.org/TR/xpath/
>>- CSS: https://www.w3.org/TR/css3-selectors/
>>
>> *Richer Tree Querying*
>>
>>- XQuery: https://www.w3.org/TR/xquery/
>>- jQuery: https://api.jquery.com
>>
>> *Second-Class "Generalized References" (nee "L-values")*
>>
>>- Common Lisp: 
>>http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm
>>- C/C++: 
>>
>> http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c
>>
>> *Lenses in Other Languages*
>>
>>- Haskell: 
>>
>> https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation
>>  
>>(great overview of key concepts!)
>>- Racket: https://docs.racket-lang.org/lens/index.html
>>
>> *Graph Querying*
>>
>>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>>
>> -- 
>> 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/

Re: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

2017-03-09 Thread David Nolen
This is correct.

On Thu, Mar 9, 2017 at 2:36 AM, Colin Fleming 
wrote:

> I believe that dependency is because Google Closure requires it.
>
> On 9 March 2017 at 16:45, Mike Rodriguez  wrote:
>
>> Guava is often a dependency conflict when trying to put libs together
>> that use it. I'm surprised cljs has dependencies like this. I'd think a
>> language would try to avoid having any deps at all or repackage them or
>> something. For example, Clojure only has ASM.
>>
>> --
>> 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.
>

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


ensure causes more contention than ref-set [Was: Ensure more concurrency]

2017-03-09 Thread Herwig Hochleitner
2017-03-09 12:34 GMT+01:00 'bertschi' via Clojure :
> Thanks for your comments. As suggested I ran a small benchmark of both
> versions. Turns out that the difference between (ref-set ref @ref) and
> ensure is huge ...
> I'm running clojure 1.8.0 by the way. According to VisualVM the (ref-set ref 
> @ref) version spends most of its time in 
> clojure.lang.LockingTransaction$RetryEx. () while ensure gets basically 
> stuck (> 99%) at clojure.lang.LockingTransaction.tryWriteLock ().

On my machine, results don't look as bad, but ensure still has a
significantly worse bad case (the upper quantile), the best case
(lower quantile) is about on par with ref-set.
Disabling tiered compilation helps close the gap (possibly due to lock
straightening?) but ref-set still comes out ahead.

The tests run significantly faster on server compilation than on
tiered compilation and also run faster on clojure-1.9.0-alpha14, than
on -1.8.0

I'm on % java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

Here is a gist with my test program + output listings:
https://gist.github.com/bendlas/6e3b24bb639c248fdc47d192f5117c39

cc clojure-dev:
is this ready for a ticket? do we need any more information to show
what's going on?

-- 
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: Navigators and lenses

2017-03-09 Thread Nathan Marz
Edwin, these personal comments about me are extremely inappropriate. Your 
claim that I ignore the work of others is just plain wrong, and that you 
would make such comments out of the blue is truly incomprehensible.

You claim Specter is "deeply un-Clojure-y" without providing a single 
example. This makes your argument boil down to "I don't like the way 
Specter makes me feel", which is no different than the complaints 
non-Lispers make about Lisp's parentheses.

Specter's core is just a simple interface and a high-performance way of 
composing implementations of that interface together. Everything else in 
Specter (the navigators) is built on top of that interface. So if you only 
want to use the "lens-like" functionality, you can literally ignore 
everything else because it doesn't affect you in any way. Additionally, 
supporting those other use cases does not make the basic use cases more 
complex or verbose.

I've found that Clojure programmers find Specter to be very intuitive. What 
they have trouble grasping is the full scope with which Specter can be 
applied, because thinking about data structures in terms of navigation is a 
new mindset. This is exactly the blub paradox as famously written about by 
Paul Graham back in the day. 

Finally, suggestions that more research and experimentation is needed in 
this area must be paired with at least one example of how Specter is 
deficient. Otherwise, it's an empty discussion. 


On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote:
>
> puzzler,
>
> I guess I haven't said this, but I think it's worth saying that I have 
> nothing against Specter. Godspeed to people who want to use it. And I don't 
> think it should be judged against some other facility in another language; 
> human progress would cease if for every Y, Y has to be a better X than X. 
> Lenses, though, are one way that humans have tried to cope with accessing 
> and updating nested data structures, and they're worth thinking about. 
> Rich's hammock driven development talk influenced me powerfully because his 
> espoused methodology ran so counter to my code-first-think-later instincts, 
> and so I have the zeal of the converted with respect to the "do some 
> research" step of HDD.
>
> What you point out—the power and expressiveness of Specter—some people 
> might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
> with the 90% of situations where something like Specter might be used and 
> making them as ridiculously simple and Clojure-y as possible. That 90% of 
> usage maps to, in my experience, maybe 25% of the feature set of Specter. 
> (YMMV, of course.) I want to facilitate the writing of code that a typical 
> Clojure developer will intuitively understand.
>
> Edwin
>
> On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>>
>> Just finished reading through Racket's lens library to compare.  Specter 
>> can do everything that Racket's lens library can do, but the converse is 
>> not true.  Specter's navigators can do more than lenses.
>>
>> The lens-like navigators are the most obviously useful parts of Specter, 
>> and maybe for some people that's all they need and they would prefer to 
>> hide the other functionality.  If so, it looks to me like it would be 
>> trivial to build a lens library like Racket's out of Specter, and it would 
>> almost certainly be higher performance than the "obvious" implementation of 
>> lenses.
>>
>> But I don't agree at all with the claim that Specter is some sort of 
>> offbeat, ill-researched version of lenses.  It is something more advanced.  
>> If Nathan had constrained his thinking to these other approaches, Specter 
>> wouldn't have such richness of functionality and pragmatic performance 
>> considerations.  
>>
>>
>> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  
>> wrote:
>>
>>> Responsible adults sometimes needs to access and modify deeply nested 
 data structures
>>>
>>>
>>> So far, my experience has been that it is almost always better to build 
>>> a pair of flattening and unflattening transforms on the data. Especially 
>>> since you frequently want only one flattening, but potentially many 
>>> un-flattenings. The "unflattened" form (aka "documents") is usually an 
>>> end-point where data goes to die; assuming it isn't immediately displayed 
>>> on the screen.
>>>
>>> However, having said that, path-dependent / context-sensitive query is a 
>>> very rich and interesting space that does have meaningful utility, 
>>> especially in the context of graph-like datasets. This is especially true 
>>> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
>>> also interested in this sort of thing for programmable user-interface use 
>>> cases: Think text editors with multiple-cursors.
>>>
>>> I think experimentation is in order

>>>
>>> Agreed. Here's some starting points for pre-hammock reading/viewing 
>>> materials:
>>>
>>> *Tree Traversal *
>>>
>>>- XPath:

Re: ensure causes more contention than ref-set [Was: Ensure more concurrency]

2017-03-09 Thread Alex Miller
A ticket is fine. If someone wants to dig into it further, please feel free 
to add info to the ticket.

On Thursday, March 9, 2017 at 9:07:31 AM UTC-6, Bendlas wrote:
>
> 2017-03-09 12:34 GMT+01:00 'bertschi' via Clojure <
> clojure@googlegroups.com>: 
> > Thanks for your comments. As suggested I ran a small benchmark of both 
> > versions. Turns out that the difference between (ref-set ref @ref) and 
> > ensure is huge ... 
> > I'm running clojure 1.8.0 by the way. According to VisualVM the (ref-set 
> ref @ref) version spends most of its time in 
> clojure.lang.LockingTransaction$RetryEx. () while ensure gets 
> basically stuck (> 99%) at clojure.lang.LockingTransaction.tryWriteLock (). 
>
> On my machine, results don't look as bad, but ensure still has a 
> significantly worse bad case (the upper quantile), the best case 
> (lower quantile) is about on par with ref-set. 
> Disabling tiered compilation helps close the gap (possibly due to lock 
> straightening?) but ref-set still comes out ahead. 
>
> The tests run significantly faster on server compilation than on 
> tiered compilation and also run faster on clojure-1.9.0-alpha14, than 
> on -1.8.0 
>
> I'm on % java -version 
> openjdk version "1.8.0_121" 
> OpenJDK Runtime Environment (build 1.8.0_121-13) 
> OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) 
>
> Here is a gist with my test program + output listings: 
> https://gist.github.com/bendlas/6e3b24bb639c248fdc47d192f5117c39 
>
> cc clojure-dev: 
> is this ready for a ticket? do we need any more information to show 
> what's going on? 
>

-- 
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: Navigators and lenses

2017-03-09 Thread Edwin Watkeys
Nathan,

I am deeply sorry for offending you. Truly. It was not my intent. My entire 
argument can be boiled down to Specter reminds me of the Common Lisp LOOP 
macro. Is that like saying "I don't like parentheses"? Maybe.

Again, I apologize.

Edwin

On Thursday, March 9, 2017 at 10:15:55 AM UTC-5, Nathan Marz wrote:
>
> Edwin, these personal comments about me are extremely inappropriate. Your 
> claim that I ignore the work of others is just plain wrong, and that you 
> would make such comments out of the blue is truly incomprehensible.
>
> You claim Specter is "deeply un-Clojure-y" without providing a single 
> example. This makes your argument boil down to "I don't like the way 
> Specter makes me feel", which is no different than the complaints 
> non-Lispers make about Lisp's parentheses.
>
> Specter's core is just a simple interface and a high-performance way of 
> composing implementations of that interface together. Everything else in 
> Specter (the navigators) is built on top of that interface. So if you only 
> want to use the "lens-like" functionality, you can literally ignore 
> everything else because it doesn't affect you in any way. Additionally, 
> supporting those other use cases does not make the basic use cases more 
> complex or verbose.
>
> I've found that Clojure programmers find Specter to be very intuitive. 
> What they have trouble grasping is the full scope with which Specter can be 
> applied, because thinking about data structures in terms of navigation is a 
> new mindset. This is exactly the blub paradox as famously written about by 
> Paul Graham back in the day. 
>
> Finally, suggestions that more research and experimentation is needed in 
> this area must be paired with at least one example of how Specter is 
> deficient. Otherwise, it's an empty discussion. 
>
>
> On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote:
>>
>> puzzler,
>>
>> I guess I haven't said this, but I think it's worth saying that I have 
>> nothing against Specter. Godspeed to people who want to use it. And I don't 
>> think it should be judged against some other facility in another language; 
>> human progress would cease if for every Y, Y has to be a better X than X. 
>> Lenses, though, are one way that humans have tried to cope with accessing 
>> and updating nested data structures, and they're worth thinking about. 
>> Rich's hammock driven development talk influenced me powerfully because his 
>> espoused methodology ran so counter to my code-first-think-later instincts, 
>> and so I have the zeal of the converted with respect to the "do some 
>> research" step of HDD.
>>
>> What you point out—the power and expressiveness of Specter—some people 
>> might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
>> with the 90% of situations where something like Specter might be used and 
>> making them as ridiculously simple and Clojure-y as possible. That 90% of 
>> usage maps to, in my experience, maybe 25% of the feature set of Specter. 
>> (YMMV, of course.) I want to facilitate the writing of code that a typical 
>> Clojure developer will intuitively understand.
>>
>> Edwin
>>
>> On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>>>
>>> Just finished reading through Racket's lens library to compare.  Specter 
>>> can do everything that Racket's lens library can do, but the converse is 
>>> not true.  Specter's navigators can do more than lenses.
>>>
>>> The lens-like navigators are the most obviously useful parts of Specter, 
>>> and maybe for some people that's all they need and they would prefer to 
>>> hide the other functionality.  If so, it looks to me like it would be 
>>> trivial to build a lens library like Racket's out of Specter, and it would 
>>> almost certainly be higher performance than the "obvious" implementation of 
>>> lenses.
>>>
>>> But I don't agree at all with the claim that Specter is some sort of 
>>> offbeat, ill-researched version of lenses.  It is something more advanced.  
>>> If Nathan had constrained his thinking to these other approaches, Specter 
>>> wouldn't have such richness of functionality and pragmatic performance 
>>> considerations.  
>>>
>>>
>>> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  
>>> wrote:
>>>
 Responsible adults sometimes needs to access and modify deeply nested 
> data structures


 So far, my experience has been that it is almost always better to build 
 a pair of flattening and unflattening transforms on the data. Especially 
 since you frequently want only one flattening, but potentially many 
 un-flattenings. The "unflattened" form (aka "documents") is usually an 
 end-point where data goes to die; assuming it isn't immediately displayed 
 on the screen.

 However, having said that, path-dependent / context-sensitive query is 
 a very rich and interesting space that does have meaningful utility, 
 especially in the context of graph-lik

GSoC

2017-03-09 Thread Eric Campbell
Hi!

I am an undergraduate senior starting my PhD in Programming Languages next 
year. I am interested in working on some of the Typed Closure Projects 
listed here , the ClosureScript 
TypeChecker, Semantic Subtyping, and Extending Annotation Generation. 

Could I talk to someone about potentially working on one of these projects 
for the summer?

Thanks!
Eric

-- 
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: Vars as global thread-locals?

2017-03-09 Thread Ernesto Garcia
Hi Didier,

Thanks for your response, it helps for continuing to learn about the 
language.

As dynamic vars are implemented by using ThreadLocals, ThreadLocal is in 
this case a more primitive construct than dynamic vars, so I find it ok to 
use it if one just needs the ThreadLocal aspect, and not the dynamic 
scoping.

As a side-topic, when looking into the Var class implementation, I have 
seen that some fields are volatile, in particular the root value of the 
var. Does that mean that every time we access a var's root value, we are 
implicitly crossing a memory barrier, so a cross-processor synchronization 
primitive. Doesn't this hit performance? Or is access to vars not 
considered to happen frequently?

Ernesto


On Saturday, March 4, 2017 at 10:59:12 PM UTC+1, Didier wrote:

> Hum, you're having me question myself.
>
> See, I don't think dynamically scoped Vars are intended for anything in 
> particular, they are what they are. Yes, they are useful when you need to 
> pass configuration down a call stack, as long as you make sure you handle 
> the thread-boundaries along the way. They can also be used to share per 
> thread data throughout a thread's execution, which is what ThreadLocal in 
> java does. So basically, I see two use cases. One, you want shared read 
> only data accessible throughout a call stack (for that, they aren't as good 
> as true dynamics, because you'll need to manually handle the thread 
> boundaries). Or you want shared writable state per-thread, making this not 
> per-thread would be dangerous, and can be done if you re-bind it manually 
> across threads or when using constructs that does so like future.
>
> The reason they are made per-thread, and not truly dynamic, as in, taking 
> on the value down the stack no matter what, is because threads could 
> content on it, and it could cause bugs, so its made per-thread for safety. 
> Here's an example of such caveat:
>
> (def ^:dynamic *dd*)
>
> (binding [*dd* (atom "John")]
>   (let [a (future (reset! *dd* "Bob"))
> b (future (reset! *dd* "Mike"))]
> @*dd*))
>
> Run this many times, and *dd*'s value could be either Mike or Bob based on 
> which threads wins the race.
>
> So the limitation of dynamic scope are inherent to dynamic scoping where 
> you have threads. Clojure's attempt at solving this limitation is to make 
> them per-thread, with explicit cross thread management through (bound-fn). 
> After a few releases, Clojure decided to make future and a few other 
> constructs implicitly propagate the dynamic var across threads as that was 
> often what people were expecting. All to say, when using dynamic Vars in 
> Clojure, you must be thread aware and understand the caveats. There is no 
> better way that I'm aware of to handle dynamic scope in a multi-threaded 
> environment.
>
> Clojure has root bindings, which Java ThreadLocals does not have. Clojure 
> lets you say, if this thread does not have a value for the dynamic Var, 
> fetch the root value instead. This is really useful in the use case of read 
> only data, like configuration, because you can set a default config. You 
> can simulate this in Java with initialValue.
>
> Now, the initialValue lets you do one more thing, it can let you generate 
> per-thread values on get, without needing to set it. Such as setting a 
> random int on the first get, and subsequent get from that thread will from 
> then on return that same generated random int. In Clojure, this is what 
> I've seen for such use case:
>
> (def ^:dynamic *id*)
>
> (defmacro with-id [& body]
>   `(binding [*id* (rand-int 1)]
> ~@body))
>
> @(future (with-id (println (str "My request id is: " *id*))
>"Success"))
>
> It's not as convenient per-say, since you have to be explicit and call the 
> macro from each Thread before getting the value, but it solves the use case.
>
> Remember that ThreadLocals are more inconvenient to get though, since you 
> need to get the ThreadLocal and then get the value out of it. So in some 
> ways, Clojure dynamics can also be seen as more convenient.
>
> Up to now, I feel like there is nothing I can not do with a Clojure 
> Dynamic Var that I could with a ThreadLocal. They're not identical, but to 
> me, the two fulfills equal use cases. And since under the hood, Clojure 
> dynamic Vars are implemented with ThreadLocal, they should perform 
> similarly too.
>
> You say you can pass around references of ThreadLocals, but I'm not sure 
> what the point of that would be, like what use case would it allow? In 
> general, and even the Java doc page says so, you'll put the ThreadLocal in 
> a static variable, i.e., private static final ThreadLocal 
> threadId. At that point, it's equal to (def ^:dynamic threadId).
>
> Anyways, you can also do that in Clojure, you can pass around the Var such 
> as:
>
> (defn printVar [v]
>   (println @v))
>
> (with-local-vars [*threadId* 0]
>   (.start (Thread. (bound-fn [] (var-set *threadId

Re: Navigators and lenses

2017-03-09 Thread Didier
At this point, I feel like dismissing your library outright. But I'd like to 
reconsider and believe that you just fumbled to express your true intents.

Maybe try a do over? I'd like to know... Did you research Specter? Did you 
research Haskell lenses and racket lenses? Did you spend 2 months thinking 
about this? What were your thoughts? What did you see as issues in all of them, 
why is your approach better, or what different kind of trade offs does it make? 
Why should I care about it?

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


Re: Navigators and lenses

2017-03-09 Thread Brandon Bloom

>
> But I don't agree at all with the claim that Specter is some sort of 
> offbeat, ill-researched version of lenses.
>

Since you're responding to me specifically, I'd like to be clear that I 
never made that claim. I only said we need more experimentation. This is a 
sufficiently big enough area of ideas to warrant exploration of competing 
approaches.

Specter's navigators can do more than lenses.


I can't speak for anybody else, but when I say "lenses", I'm referring to 
the full range of constructs offered by Edward Kmett's lenses package for 
Haskell. See the stunningly confusing diagram in the docs: 
https://hackage.haskell.org/package/lens - This includes "traversals" and 
"folds" which allow richer transformations than a one-to-one "lens" 
mapping, like the navigators concept in specter.

Specter wouldn't have such richness of functionality and pragmatic 
> performance considerations
>

As I've said on Twitter, Nathan has done an absolutely wonderful job with 
both static (compilation) and dynamic (caching) optimization techniques in 
Specter. The Haskell lenses library gets a lot of the former from existing 
GHC wizardry, but the I'm not sure about the latter, since I'm not 
sophisticated enough with Haskell to tell.

-- 
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: Vars as global thread-locals?

2017-03-09 Thread Alex Miller
Regarding your last question, yes using volatiles has a performance impact, but 
is essential to both accomplish the var api and be thread-safe.

It is also possible to compile your code with aot and direct linking. In this 
case var lookups are replaced with a direct invocation (no var lookup).

-- 
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: Contribute Specter to Clojure core?

2017-03-09 Thread Gregg Reynolds
On Mar 4, 2017 12:35 AM, "Asim Jalis"  wrote:

What might be a Clojurey syntax for doing path navigation? In other words
how could get-in be extended so that it could parse nested vectors like it
parses nested maps? Thinking out aloud, an integer in the path when the
data structure at that level is a vector should treat the integer as an
index.

What about ALL? What would be Clojurey way of doing ALL? How about asterisk
*? Or maybe underscore _? Or nil?


looks like identity to me.

i'm still not very deep into specter, but it looks a lot like xslt, just
with a different syntax and processing strategy.

gregg

-- 
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: Vars as global thread-locals?

2017-03-09 Thread Ernesto Garcia
Thank you Alex!

-- 
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: Navigators and lenses

2017-03-09 Thread Mark Engelberg
On Mar 9, 2017 9:52 AM, "Brandon Bloom"  wrote:
>>
>
> Since you're responding to me specifically, I'd like to be clear that I
never made that claim. I only said we need more experimentation. This is a
sufficiently big enough area of ideas to warrant exploration of competing
approaches.

My comment wasn't intended as directed specifically at you.  Your list of
references was interesting and useful.  Thanks for posting them.

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


Source Code for Stuart Halloway's ETL Talk

2017-03-09 Thread Shaun Parker
Does anyone know if Stuart released the source code from his presentation 
*Simplifying 
ETL with Clojure and Datomic *? 
If not, is there any timetable on releasing it?

I just watched the presentation and am now hoping to review the source. Any 
help is greatly appreciated.

Cheers,
Shaun

-- 
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: [JOB] CLJ/CLJS Developer(FL/Remote) - Swarmify putting an end to video buffering

2017-03-09 Thread Nate B
  // , I have an acquaintance who has done some prototyping and dynamic 
applications with Heroku, Clojure, and ClojureScript if you're interested. 

His name's Jason, and he's pretty active on his Github: 
https://github.com/rjb25?tab=repositories

If you have a specific pain point you can aim him at, he's considering 3 
month contracts to try out Clojure companies. 

What do you think? 

Also, if not swarmify, where do you think someone in his position could 
look? 

On Friday, January 8, 2016 at 12:49:10 PM UTC-8, Nathan wrote:
>
> Looking for a mid to senior level developer with experience in Clojure and 
> Clojurescript to join our team and help put an end to video buffering and 
> failures. Would be joining an innovative early stage company with strong 
> venture backing and product already in production. Work on a solution that 
> improves video streaming which is forecast to be 90% of all Internet 
> traffic by 2018. 
>
> We need smart can-do team members who are able to take ownership of their 
> projects and deliver results. Work hard, play hard, and MOAR CAT VIDEOS for 
> all.
>
> The position is in SpaceCoast, FL, but open to remote work with occasional 
> onsite meetings.
>
> Full job description here: 
> https://swarmify.com/jobs/#op-58685-software-engineer
>
> You can apply through our website or send your resume directly to me: 
> nat...@swarmify.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.


Source Code for Stuart Halloway's ETL Talk

2017-03-09 Thread Alex Miller
He has not yet released it but he is still planning to do so.

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


Mixing [org.clojure/clojure "1.9.0-alpha14"] and [org.clojure/tools.analyzer.jvm "0.7.0"] breaks protocol resolution?

2017-03-09 Thread Paulo César Cuneo
Hi When im using [org.clojure/clojure "1.9.0-alpha14"] together with 
 [org.clojure/tools.analyzer.jvm "0.7.0"] .
It breaks reduce, may be i m misusing protocols, am i ?

What seems to be happening is imap-cons is receiving seq as o, so it cant 
match a proper case.
Guess it happens because java.util.List wins over java.util.Map$Entry in 
protocol resolution.
 
Odd things is, removing analyzer deps changes behavior.

(defn- imap-cons
  [^IPersistentMap this o]

#_(defproject cast-exception "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.9.0-alpha14"]
 [org.clojure/tools.analyzer.jvm "0.7.0"] 
 #_[org.clojure/algo.monads "0.1.6"]]
  :main ^:skip-aot cast-exception.core
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}})

(ns cast-exception.core
  (:gen-class))

(defrecord Some [a b])
(defprotocol IMap
  (-map [ _ ]))

(extend-type nil
  IMap
  (-map [ a ] a))

(extend-type Object
  IMap
  (-map [ a ] a))

(extend-type java.util.List
  IMap
  (-map [ a ]
(map -map a)))

(extend-type java.util.Map$Entry
  IMap
  (-map [ a ]
[(-map (first  a)) 
 (-map (second a))]))

(extend-type java.util.Map 
  IMap
  (-map [ a ]
(if (record? a)
  (into a (map #(-map %) (seq a)))
  (into (empty a) (map #(-map %) (seq a))

(let [a (->Some (quote b) 2)]
  (-map a))

Cheers.

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


Re: Mixing [org.clojure/clojure "1.9.0-alpha14"] and [org.clojure/tools.analyzer.jvm "0.7.0"] breaks protocol resolution?

2017-03-09 Thread Paulo César Cuneo
Nevermind, i was misusing protocols and have clashing interfaces in 
concrete object.


On Thursday, March 9, 2017 at 11:57:17 PM UTC-3, Paulo César Cuneo wrote:
>
> Hi When im using [org.clojure/clojure "1.9.0-alpha14"] together with 
>  [org.clojure/tools.analyzer.jvm "0.7.0"] .
> It breaks reduce, may be i m misusing protocols, am i ?
>
> What seems to be happening is imap-cons is receiving seq as o, so it cant 
> match a proper case.
> Guess it happens because java.util.List wins over java.util.Map$Entry in 
> protocol resolution.
>  
> Odd things is, removing analyzer deps changes behavior.
>
> (defn- imap-cons
>   [^IPersistentMap this o]
>
> #_(defproject cast-exception "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :dependencies [[org.clojure/clojure "1.9.0-alpha14"]
>  [org.clojure/tools.analyzer.jvm "0.7.0"] 
>  #_[org.clojure/algo.monads "0.1.6"]]
>   :main ^:skip-aot cast-exception.core
>   :target-path "target/%s"
>   :profiles {:uberjar {:aot :all}})
>
> (ns cast-exception.core
>   (:gen-class))
>
> (defrecord Some [a b])
> (defprotocol IMap
>   (-map [ _ ]))
>
> (extend-type nil
>   IMap
>   (-map [ a ] a))
>
> (extend-type Object
>   IMap
>   (-map [ a ] a))
>
> (extend-type java.util.List
>   IMap
>   (-map [ a ]
> (map -map a)))
>
> (extend-type java.util.Map$Entry
>   IMap
>   (-map [ a ]
> [(-map (first  a)) 
>  (-map (second a))]))
>
> (extend-type java.util.Map 
>   IMap
>   (-map [ a ]
> (if (record? a)
>   (into a (map #(-map %) (seq a)))
>   (into (empty a) (map #(-map %) (seq a))
>
> (let [a (->Some (quote b) 2)]
>   (-map a))
>
> Cheers.
>
>

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