Re: ANN: ClojureScript 0.0-3255 - pretty printer latest Closure Compiler / Library
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}
--
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
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 fer.ob...@gmail.com
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescr...@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: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?
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 al...@puredanger.com javascript: : 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 javascript: 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 javascript: 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 javascript:. 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?
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 al...@puredanger.com: 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: ANN: ClojureScript 0.0-3255 - pretty printer latest Closure Compiler / Library
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 dnolen...@gmail.com 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 rasp...@gmail.com 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 dnolen...@gmail.com 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 http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3255 - pretty printer latest Closure Compiler / Library
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 fer@gmail.com 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: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?
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: Why aren't libraries like clojure/(data.csv, ...) on clojars.org?
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 a...@puredanger.com: 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 al...@puredanger.com: 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 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
Re: separation of concerns w/o encapsulation
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 frankiec...@gmail.com 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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
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 gon...@gmail.com 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 dnolen...@gmail.com 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 rasp...@gmail.com 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 dnolen...@gmail.com 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
[ANN] PigPen 0.3.0 - Now with Cascading!
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: Opinion on take-while for stateful transducers
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- andre.r...@gmail.com 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
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
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?
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 http://clojure.org/metadata. 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.
Re: Embedded systems and transpiling Clojure to Nim
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.
Is it possible to annotate an anonymous type?
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: Embedded systems and transpiling Clojure to Nim
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.
New Functional Programming Job Opportunities
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.
Re: separation of concerns w/o encapsulation
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.
Re: Have a look at pretial and apply-to
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.
