Re: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?

[Alex Miller]

We could, but the benefits do not seem worth the effort to me.

On Monday, May 11, 2015 at 12:33:41 AM UTC-5, Jakub Holy wrote:
>
> Thank you, Alex. I understand and agree with the importance of publishing 
> to Maven Central but my question is why can't we publish *also* to Clojars? 
>
> --
> Forget software. Strive to make an impact, deliver a valuable change.
>
> (Vær så snill og hjelp meg med å forbedre norsken min – skriftlig og 
> muntlig. Takk!)
>
> Jakub Holy
> Solutions Engineer | +47 966 23 666
> Iterate AS | www.iterate.no
> The Lean Software Development Consultancy
> - http://theholyjava.wordpress.com/ -
> 11. mai 2015 07:19 skrev "Alex Miller" 
> >:
>
>> As usual, the answer is a combination of technical goals intertwined with 
>> history. Stuart Sierra is probably the one with the most knowledge of the 
>> history - it predates my involvement with Clojure in a deep way. Best link 
>> I see is: http://dev.clojure.org/pages/viewpage.action?pageId=950842. In 
>> summary, it was of primary importance to be available to the broader Java 
>> ecosystem and Maven central was already blessed and understood by that 
>> audience.
>>
>> This is also from a time when builds based on Maven, Ant, Gradle, etc 
>> were more common than the relatively new and less-featured Leiningen. Those 
>> tools already understood Maven Central but had to be configured to use 
>> Clojars. I'm unsure of the exact timeline, but I'm pretty sure Clojars 
>> predated Leiningen by a year or two.
>>
>> On Sunday, May 10, 2015 at 5:43:47 AM UTC-5, Jakub Holy wrote:
>>>
>>> This is essentially a question to Cognitect / developers of 
>>> the clojure/* libraries but I do not know of a better communication channel 
>>> than this one.
>>>
>>> To me, clojars is the one place to go to find out what libraries are 
>>> there and especially what is the latest version. It always surprises me 
>>> that some core libraries such as .e.g clojure.data.cvs aren't there. It is 
>>> annoying and difficult to remember that I have to search both clojars and 
>>> Maven Central. I think it would be really wonderful if these libraries too 
>>> could be on clojars. Or is there any reason why this cannot be the case?
>>>
>>> (I know there are sites for finding libraries such as Clojure Toolbox 
>>> but that is not really what I am asking for here.)
>>>
>>> Thank you!
>>>
>>> Best regards, Jakub Holy
>>>
>>  -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/kGwmWLRAUNo/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.

Re: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?

[Lars Andersen]

A while back I wrote some code for clj-refactor to help out when adding a 
new project dependency.  When you call this function, in emacs, you get a 
completing read of an artifact id, a completing read of available versions, 
and it then updates your project.clj and hotloads the new dependency into 
the repl.

Retrieving the required data from clojars was entirely trivial, but then I 
noticed the most important projects were missing, because they were hosted 
on Maven central!

Having all Clojure artifacts in one place would make it a lot easier to 
write programs consuming said artifacts.


On Monday, May 11, 2015 at 9:19:34 AM UTC+2, Alex Miller wrote:
>
> We could, but the benefits do not seem worth the effort to me.
>
> On Monday, May 11, 2015 at 12:33:41 AM UTC-5, Jakub Holy wrote:
>>
>> Thank you, Alex. I understand and agree with the importance of publishing 
>> to Maven Central but my question is why can't we publish *also* to Clojars? 
>>
>> --
>> Forget software. Strive to make an impact, deliver a valuable change.
>>
>> (Vær så snill og hjelp meg med å forbedre norsken min – skriftlig og 
>> muntlig. Takk!)
>>
>> Jakub Holy
>> Solutions Engineer | +47 966 23 666
>> Iterate AS | www.iterate.no
>> The Lean Software Development Consultancy
>> - http://theholyjava.wordpress.com/ -
>> 11. mai 2015 07:19 skrev "Alex Miller" :
>>
>>> As usual, the answer is a combination of technical goals intertwined 
>>> with history. Stuart Sierra is probably the one with the most knowledge of 
>>> the history - it predates my involvement with Clojure in a deep way. Best 
>>> link I see is: 
>>> http://dev.clojure.org/pages/viewpage.action?pageId=950842. In summary, 
>>> it was of primary importance to be available to the broader Java ecosystem 
>>> and Maven central was already blessed and understood by that audience.
>>>
>>> This is also from a time when builds based on Maven, Ant, Gradle, etc 
>>> were more common than the relatively new and less-featured Leiningen. Those 
>>> tools already understood Maven Central but had to be configured to use 
>>> Clojars. I'm unsure of the exact timeline, but I'm pretty sure Clojars 
>>> predated Leiningen by a year or two.
>>>
>>> On Sunday, May 10, 2015 at 5:43:47 AM UTC-5, Jakub Holy wrote:

 This is essentially a question to Cognitect / developers of 
 the clojure/* libraries but I do not know of a better communication 
 channel 
 than this one.

 To me, clojars is the one place to go to find out what libraries are 
 there and especially what is the latest version. It always surprises me 
 that some core libraries such as .e.g clojure.data.cvs aren't there. It is 
 annoying and difficult to remember that I have to search both clojars and 
 Maven Central. I think it would be really wonderful if these libraries too 
 could be on clojars. Or is there any reason why this cannot be the case?

 (I know there are sites for finding libraries such as Clojure Toolbox 
 but that is not really what I am asking for here.)

 Thank you!

 Best regards, Jakub Holy

>>>  -- 
>>> 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 a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/kGwmWLRAUNo/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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.

Re: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?

[Niels van Klaveren]

Code that does consume artifacts would never be complete with just adding maven 
central or having libraries duplicated on clojars. It should use the repo info 
from lein or maven to include local, snapshot and other external repositories, 
like lein ancient does.

-- 
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: ANN: ClojureScript 0.0-3255 - pretty printer & latest Closure Compiler / Library

[Max Gonzih]

On Sunday, May 10, 2015 at 11:24:54 PM UTC+2, Dmitri Sotnikov wrote:
> Is there possibly anything else missing in the package, figwheel doesn't 
> appear to find the repl ns.
> 
> 
> 
> 
> 
> lein figwheel
> Retrieving org/clojure/clojurescript/0.0-3269/clojurescript-0.0-3269.pom from 
> central
> Retrieving org/clojure/clojurescript/0.0-3269/clojurescript-0.0-3269.jar from 
> central
> Exception in thread "main" java.io.FileNotFoundException: Could not locate 
> cljs/repl__init.class or cljs/repl.clj on classpath: , 
> compiling:(figwheel_sidecar/repl.clj:1:1)
> 
> 
> On Sunday, May 10, 2015 at 10:20:13 AM UTC-4, David Nolen wrote:
> Just cut 0.0-3269 which adds the missing analysis and source map bits back 
> into the artifacts. It also cleans up :libs support and fixes a related 
> regression with Closure compatible libraries that follow classpath 
> conventions (like transit-js). Both :libs Closure libraries and classpath 
> aware Closure compatible libraries now enjoy REPL support.
> 
> 
> David
> 
> 
> On Sun, May 10, 2015 at 9:41 AM, David Nolen  wrote:
> 
> It appears there are still some important bits missing from the artifacts. 
> Working through the issues and will cut a release soon.
> 
> 
> David
> 
> 
> 
> 
> On Sun, May 10, 2015 at 12:22 AM, Rangel Spasov  wrote:
> 
> Hey guys,
> 
> 
> 0.0-3264 fails for me with:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> clojure.lang.ExceptionInfo: failed compiling 
> file:resources/public/js/compiled/out/cljs/core.cljs
> 
>  at clojure.core$ex_info.invoke (core.clj:4591)
> 
> Caused by: java.lang.IllegalArgumentException: No implementation of method: 
> :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
> 
>  at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:554)
> 
> 0.0-3255 seems fine. 
> 
> 
> @raspasov
> On Saturday, May 9, 2015 at 12:33:52 PM UTC-7, David Nolen wrote:
> Just released 0.0-3264, it fixes a critical issue where .js files were 
> missing from the artifacts due to the changed build. Also included are a 
> several fixes around the :libs feature, REPLs, and stack trace mapping.
> 
> 
> David
> 
> 
> 
> 
> On Fri, May 8, 2015 at 3:23 PM, David Nolen  wrote:
> 
> 
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-3255"]
> 
> 
> A big thanks goes out to Jonathan Boston and Shaun Lebron for this
> release. Thanks to their efforts ClojureScript now includes a full
> port of clojure.pprint under the cljs.pprint namespace. This was the
> last major namespace in need of porting to ClojureScript.
> 
> 
> The release also bumps several dependencies: Clojure 1.7.0-beta2,
> tools.reader 0.9.2, Closure Compiler v20150505, and Closure Library
> 0.0-20150505-021ed5b3.
> 
> 
> This release also fixes some regressions around async testing,
> docstring REPL support, arglist meta, and more.
> 
> 
> As always feedback welcome!
> 
> 
> ## 0.0-3255
> 
> 
> ### Changes
> * Update Closure Library dependency
> * CLJS-1252: Update Closure Compiler Dependency to v20150505
> * .clj -> .cljc for important analysis / compilation bits
> * add public cljs.compiler.api namespace
> * CLJS-1224: cljs.repl: Memoize stack frame mapping
> * depend on tools.reader 0.9.2
> 
> 
> ### Enhancements
> * add cljs.pprint/pp macro
> * CLJS-710: port clojure.pprint
> * CLJS-1178: Compiler does not know Math ns is not not-native
> * add getBasis methods to deftype and defrecord ctors a la Clojure JVM
> * support ^long and ^double type hints
> 
> 
> ### Fixes
> * fix cljs-1198 async testing regression
> * CLJS-1254: Update REPL browser agent detection CLJS-1253: Create/Use
>   new Closure Library Release
> * CLJS-1225: Variadic function with same name as parent function gives
>   runtime error in advanced compile mode.
> * CLJS-1246: Add cljs.core/record? predicate.
> * CLJS-1239: Make eduction variadic.
> * CLJS-1244: tagged-literal precondition check missing wrapping vector
> * CLJS-1243: Add TaggedLiteral type & related fns
> * CLJS-1240: Add cljs.core/var?
> * CLJS-1214: :arglists meta has needless quoting CLJS-1232: bad
>   arglists for doc, regression
> * CLJS-1212: Error in set ctor for > 8-entry map literal
> * CLJS-1218: Syntax quoting an alias created with :require-macros
>   throws ClassCastException
> * CLJS-1213: cljs.analyzer incorrectly marks all defs as tests when
>   eliding test metadata
> * CLJS-742: Compilation with :output-file option set fails
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 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
>

Re: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?

[Jakub Holy]

Is it so much effort? Isn't / couldn't it be a simple, automated step?

--
Forget software. Strive to make an impact, deliver a valuable change.

(Vær så snill og hjelp meg med å forbedre norsken min – skriftlig og
muntlig. Takk!)

Jakub Holy
Solutions Engineer | +47 966 23 666
Iterate AS | www.iterate.no
The Lean Software Development Consultancy
- http://theholyjava.wordpress.com/ -
11. mai 2015 09:19 skrev "Alex Miller" :

> We could, but the benefits do not seem worth the effort to me.
>
> On Monday, May 11, 2015 at 12:33:41 AM UTC-5, Jakub Holy wrote:
>>
>> Thank you, Alex. I understand and agree with the importance of publishing
>> to Maven Central but my question is why can't we publish *also* to Clojars?
>>
>> --
>> Forget software. Strive to make an impact, deliver a valuable change.
>>
>> (Vær så snill og hjelp meg med å forbedre norsken min – skriftlig og
>> muntlig. Takk!)
>>
>> Jakub Holy
>> Solutions Engineer | +47 966 23 666
>> Iterate AS | www.iterate.no
>> The Lean Software Development Consultancy
>> - http://theholyjava.wordpress.com/ -
>> 11. mai 2015 07:19 skrev "Alex Miller" :
>>
>>> As usual, the answer is a combination of technical goals intertwined
>>> with history. Stuart Sierra is probably the one with the most knowledge of
>>> the history - it predates my involvement with Clojure in a deep way. Best
>>> link I see is:
>>> http://dev.clojure.org/pages/viewpage.action?pageId=950842. In summary,
>>> it was of primary importance to be available to the broader Java ecosystem
>>> and Maven central was already blessed and understood by that audience.
>>>
>>> This is also from a time when builds based on Maven, Ant, Gradle, etc
>>> were more common than the relatively new and less-featured Leiningen. Those
>>> tools already understood Maven Central but had to be configured to use
>>> Clojars. I'm unsure of the exact timeline, but I'm pretty sure Clojars
>>> predated Leiningen by a year or two.
>>>
>>> On Sunday, May 10, 2015 at 5:43:47 AM UTC-5, Jakub Holy wrote:

 This is essentially a question to Cognitect / developers of
 the clojure/* libraries but I do not know of a better communication channel
 than this one.

 To me, clojars is the one place to go to find out what libraries are
 there and especially what is the latest version. It always surprises me
 that some core libraries such as .e.g clojure.data.cvs aren't there. It is
 annoying and difficult to remember that I have to search both clojars and
 Maven Central. I think it would be really wonderful if these libraries too
 could be on clojars. Or is there any reason why this cannot be the case?

 (I know there are sites for finding libraries such as Clojure Toolbox
 but that is not really what I am asking for here.)

 Thank you!

 Best regards, Jakub Holy

>>>  --
>>> 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 a topic in the
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/clojure/kGwmWLRAUNo/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/kGwmWLRAUNo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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 sub

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3255 - pretty printer & latest Closure Compiler / Library

[Ruslan Prokopchuk]

Thanks for the tip, `:libs ["lib"]` is more convenient and does not produce 
error.

понедельник, 11 мая 2015 г., 9:52:16 UTC+3 пользователь David Nolen написал:
> Enhancing :libs support was pretty finicky work so I'm not particularly 
> surprised by the regression. Looking into it. In the meantime you don't need 
> specify each library, `:libs ["lib"]` should suffice.
> 
> 
> David
> 
> 
> 
> On Mon, May 11, 2015 at 1:10 AM, Ruslan Prokopchuk  wrote:
> With 3269 I have the following error:
> 
> 
> 
> java.lang.IllegalArgumentException: 
> /home/ul/Projects/project1/lib/transformflatgeom.js is not a relative path
> 
>  at clojure.java.io$as_relative_path.invoke (io.clj:405)
> 
> 
> 
> config is:
> 
> 
> 
> :compiler     {
> 
> :output-to      "resources/public/js/dev.js"
> 
> :output-dir     "resources/public/js/dev"
> 
> :source-map     "resources/public/js/dev.js.map"
> 
> :libs           ["lib/simplegeometry.js" "lib/transformflatgeom.js"
> 
>                  "lib/scaleinteraction.js" "lib/translateinteraction.js"]
> 
> :cache-analysis true
> 
> :optimizations  :none
> 
> :pretty-print   true}
> 
> 
> 
> 
> 
> --
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> 
> ---
> 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescrip...@googlegroups.com.
> 
> To post to this group, send email to clojur...@googlegroups.com.
> 
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
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: separation of concerns w/o encapsulation

[Gary Verhaegen]

If your modules are becoming big and unwieldy, you can also take a step
toward (conceptual) OO and have your modules be separate entities that
communicate through message passing (i.e. objects, although probably closer
to Erlang's processes than Java objects). Messages are the key missing
piece of many OO languages; Clojure maps are really nice for that. You can
use core.async to establish communications between your modules, and
defining the interfaces becomes akin to defining a network protocol (though
with richly structured messages).

This way, each module is only exposed to what other modules send it, your
code is well decoupled and isolated, and when it keeps growing and it makes
sense to separate the code base into different processes, the refactoring
is, if not trivial, manageable.

Disclaimer: this is just an idea, I have not had the opportunity to
actually try it out on a real, reasonably complex codebase.

On Monday, 11 May 2015, Frank Castellucci  wrote:

> Brian
>
> One is better off thinking that avoidance, as per your note, is a
> *discipline* of *better practices. *As the architectural concepts of
> Separation of Concerns and Minimized Surface Areas were intended.
>
> Many languages attempt to enforce this notion in something called
> encapsulation. However; Encapsulation is buzz as it is subject to the
> pressures of the moment, including but not limited to:
>
>1. Market pressure for timely delivery - or "*Ef it, I'm just going to
>expose this one little thing for now...*"
>2. Introspection - If I can find it, I'll figure out how to get/set
>it. Especially easy through such things as:
>3. Byte Code Injection - In the case of Java, and,
>4. Easy work arounds - In the case of Clojure's  *(**def my-local
>#'ns/their-privates)*
>
> How to avoid it? Discipline and code reviews.
>
> Frank Castellucci
>
>
>
>
> On Friday, May 8, 2015 at 12:29:50 PM UTC-4, Brian Craft wrote:
>>
>> Talk on the list about encapsulation usually comes back to some variation
>> of "you don't need it when you have immutable data structures". But in the
>> long term I'm finding the problem of working w/o encapsulation is not the
>> danger of data being mutated under you. Rather, it's the danger of all the
>> module boundaries blurring over time, leading to the big ball of mud: a
>> very fragile code base where everything depends on everything else.
>>
>> E.g. if you model your application with a plain data structure which you
>> pass around to different modules, each concerned with a small part of that
>> data structure, the tendency over time is for every module to become
>> concerned with every part of that data structure.  Then you have no
>> separation, nothing is reusable, and the code is very fragile.
>>
>> How do you avoid this, practically? In OO it would be enforced with
>> encapsulation, so the next developer (which might be me, six months later)
>> trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here:
>> this module isn't supposed to depend on that piece of data".
>>
>  --
> 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: [ClojureScript] Re: ANN: ClojureScript 0.0-3255 - pretty printer & latest Closure Compiler / Library

[David Nolen]

As I said above, you must specify Clojure 1.7.0-beta2 as your Clojure
dependency.

On Mon, May 11, 2015 at 3:59 AM, Max Gonzih  wrote:

> On Sunday, May 10, 2015 at 11:24:54 PM UTC+2, Dmitri Sotnikov wrote:
> > Is there possibly anything else missing in the package, figwheel doesn't
> appear to find the repl ns.
> >
> >
> >
> >
> >
> > lein figwheel
> > Retrieving org/clojure/clojurescript/0.0-3269/clojurescript-0.0-3269.pom
> from central
> > Retrieving org/clojure/clojurescript/0.0-3269/clojurescript-0.0-3269.jar
> from central
> > Exception in thread "main" java.io.FileNotFoundException: Could not
> locate cljs/repl__init.class or cljs/repl.clj on classpath: ,
> compiling:(figwheel_sidecar/repl.clj:1:1)
> >
> >
> > On Sunday, May 10, 2015 at 10:20:13 AM UTC-4, David Nolen wrote:
> > Just cut 0.0-3269 which adds the missing analysis and source map bits
> back into the artifacts. It also cleans up :libs support and fixes a
> related regression with Closure compatible libraries that follow classpath
> conventions (like transit-js). Both :libs Closure libraries and classpath
> aware Closure compatible libraries now enjoy REPL support.
> >
> >
> > David
> >
> >
> > On Sun, May 10, 2015 at 9:41 AM, David Nolen 
> wrote:
> >
> > It appears there are still some important bits missing from the
> artifacts. Working through the issues and will cut a release soon.
> >
> >
> > David
> >
> >
> >
> >
> > On Sun, May 10, 2015 at 12:22 AM, Rangel Spasov 
> wrote:
> >
> > Hey guys,
> >
> >
> > 0.0-3264 fails for me with:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > clojure.lang.ExceptionInfo: failed compiling
> file:resources/public/js/compiled/out/cljs/core.cljs
> >
> >  at clojure.core$ex_info.invoke (core.clj:4591)
> >
> > Caused by: java.lang.IllegalArgumentException: No implementation of
> method: :make-reader of protocol: #'clojure.java.io/IOFactory found for
> class: nil
> >
> >  at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:554)
> >
> > 0.0-3255 seems fine.
> >
> >
> > @raspasov
> > On Saturday, May 9, 2015 at 12:33:52 PM UTC-7, David Nolen wrote:
> > Just released 0.0-3264, it fixes a critical issue where .js files were
> missing from the artifacts due to the changed build. Also included are a
> several fixes around the :libs feature, REPLs, and stack trace mapping.
> >
> >
> > David
> >
> >
> >
> >
> > On Fri, May 8, 2015 at 3:23 PM, David Nolen  wrote:
> >
> >
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > Leiningen dependency information:
> >
> >
> > [org.clojure/clojurescript "0.0-3255"]
> >
> >
> > A big thanks goes out to Jonathan Boston and Shaun Lebron for this
> > release. Thanks to their efforts ClojureScript now includes a full
> > port of clojure.pprint under the cljs.pprint namespace. This was the
> > last major namespace in need of porting to ClojureScript.
> >
> >
> > The release also bumps several dependencies: Clojure 1.7.0-beta2,
> > tools.reader 0.9.2, Closure Compiler v20150505, and Closure Library
> > 0.0-20150505-021ed5b3.
> >
> >
> > This release also fixes some regressions around async testing,
> > docstring REPL support, arglist meta, and more.
> >
> >
> > As always feedback welcome!
> >
> >
> > ## 0.0-3255
> >
> >
> > ### Changes
> > * Update Closure Library dependency
> > * CLJS-1252: Update Closure Compiler Dependency to v20150505
> > * .clj -> .cljc for important analysis / compilation bits
> > * add public cljs.compiler.api namespace
> > * CLJS-1224: cljs.repl: Memoize stack frame mapping
> > * depend on tools.reader 0.9.2
> >
> >
> > ### Enhancements
> > * add cljs.pprint/pp macro
> > * CLJS-710: port clojure.pprint
> > * CLJS-1178: Compiler does not know Math ns is not not-native
> > * add getBasis methods to deftype and defrecord ctors a la Clojure JVM
> > * support ^long and ^double type hints
> >
> >
> > ### Fixes
> > * fix cljs-1198 async testing regression
> > * CLJS-1254: Update REPL browser agent detection CLJS-1253: Create/Use
> >   new Closure Library Release
> > * CLJS-1225: Variadic function with same name as parent function gives
> >   runtime error in advanced compile mode.
> > * CLJS-1246: Add cljs.core/record? predicate.
> > * CLJS-1239: Make eduction variadic.
> > * CLJS-1244: tagged-literal precondition check missing wrapping vector
> > * CLJS-1243: Add TaggedLiteral type & related fns
> > * CLJS-1240: Add cljs.core/var?
> > * CLJS-1214: :arglists meta has needless quoting CLJS-1232: bad
> >   arglists for doc, regression
> > * CLJS-1212: Error in set ctor for > 8-entry map literal
> > * CLJS-1218: Syntax quoting an alias created with :require-macros
> >   throws ClassCastException
> > * CLJS-1213: cljs.analyzer incorrectly marks all defs as tests when
> >   eliding test metadata
> > * CLJS-742: Compilation with :output-file option set fails
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > You received this message because you

[ANN] PigPen 0.3.0 - Now with Cascading!

[Matt Bossenbroek]

I'm excited to announce the release of PigPen v0.3.0, which now includes 
support for Cascading.

PigPen is Map-Reduce for Clojure - you write idiomatic Clojure code, we 
compile it into an Apache Pig script or a Cascading flow that runs on 
Hadoop.

https://github.com/Netflix/PigPen

An RC build is currently available in Maven (0.3.0-rc.7). We've been using 
it at Netflix for a little over a month now with no issues, but we want to 
get it out in the wild before locking down the release.

There are a couple of breaking changes in this release, mostly just moving 
pig-specific functions into another namespace. Check out the release notes 
for more details.

Also new since the last major release: semi-joins, anti-joins, load-json, 
store-json, load-csv (RFC 4180), load-parquet, store-parquet, and load-avro 
(parquet & avro support not yet available for cascading).

A huge thanks to Piotr Kozikowski for contributing all of the Cascading 
work to the project.

For questions or complaints: pigpen-supp...@googlegroups.com

-Matt


ps. The PigPen name & logo aren't really ideal now that we've added another 
platform and plan to add more. Apparently we're only clever enough for one 
name & logo. If you've got an idea for a better name for the project, 
please let us know. :)

-- 
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: separation of concerns w/o encapsulation

[Brian Craft]

Thanks, everyone, this has been very helpful.

On Sunday, May 10, 2015 at 8:28:37 AM UTC-7, Stuart Sierra wrote:
>
> I find it's really the same as in any other language. Certainly if you 
> don't have any clearly-defined boundaries at all, you'll get a big ball of 
> mud.
>
> Encapsulation is about code organization and self-discipline. Define 
> module responsibilities and boundaries in your developer documentation. 
> Make it clear that X is not supposed to depend on Y. Enforce those 
> boundaries through code review and refactoring. Regularly review module 
> definitions to make sure they match the real requirements of the system.
>
> I developed Component[1] to help with one aspect of this problem. One 
> shared map defines the structure of the entire system, but each “module” is 
> only exposed to the subset of the system it needs.
>
> Other approaches: With a shared map, namespaced keywords can be a hint 
> that something is “private” to a particular module. Alternately, you could 
> establish the convention that elements of a shared data structure should 
> *only* be accessed via helper functions, and use public/private Vars to 
> enforce which aspects of a data structure are meant to be “public” to other 
> modules.
>
> –S
>
> [1]: https://github.com/stuartsierra/component
>
> On Friday, May 8, 2015 at 5:29:50 PM UTC+1, Brian Craft wrote:
>>
>> Talk on the list about encapsulation usually comes back to some variation 
>> of "you don't need it when you have immutable data structures". But in the 
>> long term I'm finding the problem of working w/o encapsulation is not the 
>> danger of data being mutated under you. Rather, it's the danger of all the 
>> module boundaries blurring over time, leading to the big ball of mud: a 
>> very fragile code base where everything depends on everything else.
>>
>> E.g. if you model your application with a plain data structure which you 
>> pass around to different modules, each concerned with a small part of that 
>> data structure, the tendency over time is for every module to become 
>> concerned with every part of that data structure.  Then you have no 
>> separation, nothing is reusable, and the code is very fragile.
>>
>> How do you avoid this, practically? In OO it would be enforced with 
>> encapsulation, so the next developer (which might be me, six months later) 
>> trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here: 
>> this module isn't supposed to depend on that piece of data".
>>
>

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

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Haskell Web Engineer at Front Row Education

http://functionaljobs.com/jobs/8823-haskell-web-engineer-at-front-row-education



Sr. Software Engineer at McGraw-Hill Education

http://functionaljobs.com/jobs/8822-sr-software-engineer-at-mcgraw-hill-education



Cheers,

Sean Murphy

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

Is it possible to annotate an anonymous type?

[Elric Erkose]

I've been using proxy to extend a java class. Recently the class added 
functionality which requires an annotation to enable.  Is there a way to 
annotate an anonymous type or do I need to switch to gen-class?

-- 
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: Have a look at pretial and apply-to

[Leon Grapenthin]

It seems like this brings a syntactical improvement at runtime performance 
cost. Are there more examples for compositional advantages or why would you 
prefer functions over macros for this?

E. g. I recently wrote myself arrow macros that return a functions which 
thread its only argument through the arrow - They could do the syntactical 
job at no cost here.

On Saturday, May 9, 2015 at 10:18:47 PM UTC+2, Herwig Hochleitner wrote:
>
> I've uploaded a proposal / working code in literate programming style to 
> github:
>
> https://gist.github.com/bendlas/0722a35ab274d659c507
>
> I'd be delighted if you took the time to read it through, maybe try it out 
> and tell me what you think of it.
>
> This is not strictly a proposal for core just now, and I know how wary the 
> community is with such things, but this fits so well, I just had to give it 
> a chance to take a hold in the language. For an example, look at the 
> benchmarking code at the end of the gist.
> So if this passes by someone at cognitect, please add a comment on whether 
> you'd consider these operations for inclusion.
>
> 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: Opinion on take-while for stateful transducers

[Steve Miner]

Not an expert, but I’ll throw out an alternative approach that might work for 
you.  I think it’s simpler to use a transducer that calls functions rather than 
trying to transform an existing transducer to do the cutoff.

(defn take-while-accumulating [accf init pred2]
   (fn [rf]
 (let [vstate (volatile! init)]
   (fn
 ([] (rf))
 ([result] (rf result))
 ([result input]
  (if (pred2 @vstate input)
(do (vswap! vstate accf input)
(rf result input))
(reduced result)))

accf is like a reducing function: takes two args, state and input, and returns 
new state of the “accumulation”.  init is the initial state of the 
accumulation.  pred2 is a predicate taking two args, the accumulation state and 
the new input.  The process stops when pred2 returns false.

;; distinct
(into [] (take-while-accumulating conj #{} (complement contains?)) '(1 2 3 4 2 
5 6))
;;=> [1 2 3 4]

;; dedupe
(into [] (take-while-accumulating (fn [r x] x) ::void not=) '(1 2 1 3 4 4 5 6))
;;=> [1 2 1 3 4]

;; monotonically increasing
(into [] (take-while-accumulating max 0 <=) '(1 2 3 4 4 1 5 6))
[1 2 3 4 4]


Steve Miner
stevemi...@gmail.com


  

On May 9, 2015, at 6:28 PM, Andy-  wrote:

> (defn take-while-xf
>  
> "Takes a transducer and returns a transducer that will immediately finish (ie
>   call (reduced)) when the transducer did not call the reducing function and
>   just returned the result. Only really useful with stateful transducers.
>   Otherwise you'd use take-while."
> 
> [xf]
> 

-- 
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: Embedded systems and transpiling Clojure to Nim

[John Gabriele]

Alan, there was an attempt at compiling Clojure to C, 
https://github.com/schani/clojurec , but it hasn't been updated in a while.


On Thursday, April 30, 2015 at 11:00:02 PM UTC-4, Alan Moore wrote:
>
> All,
>
> I just ran across Nim (previously Nimrod) which is a garbage collected 
> systems programming language that looks like a suitable target for 
> transpiling Clojure. See:
>
> http://nim-lang.org/
>
> My goal in looking at this is to have Clojure available in native code on 
> real-time embedded systems which is what I work on in my day job. It seemed 
> like targeting LLVM was the way forward with this goal but I have not heard 
> of any progress in this area and it feels large and foreboding. Obviously 
> targeting LLVM gives you a lot beyond just native code but it is limited in 
> the processors it supports. We use Freescale PPC processors which neither 
> LLVM nor most Javascript engines support, or if they do, they do so in a 
> very limited way - e.g. only certain procs, etc.
>
> Having a compiler toolchain that resolves down to C, small executables and 
> no/few dependencies is a huge advantage for using something like Nim.
>
> Is this of interest to anyone else? I'd like to get a proof of concept 
> started. Advice on porting Clojure to other languages would be greatly 
> appreciated :-)
>
> Alan
>
>

-- 
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: Embedded systems and transpiling Clojure to Nim

[Paul deGrandis]

Hi Alan,

Yep, you can cross compile the output from Terra - you can even set it up 
to output compilations dynamically for any platform you want.  Replacing 
LuaJIT with Lua would just be a matter of changing the library that you 
link when building Terra itself.  As Timothy pointed out, Pixie is just 
going to be C, so you should be able to cross-compile the base for whatever 
platform you need (someone recently blogged about putting Pixie on the 
Raspberry Pi).

Cheers,
Paul

-- 
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: Embedded systems and transpiling Clojure to Nim

[Tyler Anderson]

I really like nim from just tinkering here and there. If i was looking to 
do what you are i'd go with nim or ocaml. 

Since i'm not exactly the most helpful person here i'd suggest you contact 
Dennis Felsing his blog is http://hookrace.net/
and his github is https://github.com/def-   he'd be able to tell you just 
how viable this path is.

-- 
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: Have a look at pretial and apply-to

[Herwig Hochleitner]

The compositional advantage with cojure's convention collection-arg first
is pretty much the point. -> is to pretial, what ->> is to partial. The
improvement is more than syntactical: pretial lets you swap out or
preprocess whole arms of the computation at the value level. Macro's don't
help with this.

Sure, the microbenchmark shows a 15% slowdown against rigidly inlining the
operations, which seems reasonable to me for an additional degree of
freedom.
Certainly, for all of my setup code, I'm willing to pay those 15%, just to
save my pinkie those shift hits and to be able to display 2 pages of code
side-by-side (yeah, I know, real programmers aren't afraid of writing more
than 80 characters ;-)

In my workflow, examples are plenty, whenever I work with data trees, more
than one level deep. Like Om app states, systems of stuartsierra's
components or even just xml processing.
Often I find myself passing something amounting to #(-> ...) into those
update fns, that `would` let me pass additional args, but I can't use them,
simply because I want to schedule more than a single update function. So
there, apply-to and pretial are the missing pieces to retrofit those
additional arguments for the update steps.​

I haven't seen your arrow macros. How are they different from clojure's?

-- 
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: What does ^:internal mean?

[Mischov]

To answer your question, ^:internal is shorthand meaning "set the :internal 
key of the object's metadata to true".

You can read more about metadata here .

On Sunday, May 10, 2015 at 2:00:10 PM UTC-5, piast...@gmail.com wrote:
>
>
> What does ^:internal mean in this context? 
>
>
>
>
>
>
>
>

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