Cognitect joins Nubank!

We are excited to announce that Cognitect is joining the Nubank family of companies: https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank Clojure remains independent, and development and stewardship will continue as it has, with more resources and a much larger sponsoring organization i

Re: Clojure Spec, performance and workflows

Thanks for your feedback. I've been anticipating this discussion, and my response here is directed to everyone, not just your problem. Using specs and instrument+generative testing is much different than the example-based testing that has happened thus far, and should deliver substantially grea

Re: Thoughts on clojure.spec

Kovas is right on the money here. Inherently when you make something ‘programmable’ generating correct programs for it is hard. I would say though, I frequently see people struggling to spec more complex logic are going directly to independent input generation. Thus, how will inputs be reasonab

Re: [ANN] Clojure 1.9.0-alpha4

To give people an idea of the update-in and seq destructuring improvements: (let [d3 {:a {:b {:c 2}}}] (dotimes [_ 10] (time (dotimes [_ 1000] (update-in d3 [:a :b :c] inc) ;;; 1.9 alpha3 ;; user=> "Elapsed time: 6489.189065 msecs" "Elapsed time: 6501

Re: clojure.spec generation question

You are not labeling your preds, so ::not-predicate is taken as the label for ::and-predicate etc. Also, tuples are not labeled: (require '[clojure.spec :as s]) (require '[clojure.spec.gen :as gen]) (s/def ::atom string?) (s/def ::predicate (s/or :not ::not-predicate

Re: clojure.spec

7f4df262ce16ce87351a04 > > On Monday, May 23, 2016 at 4:12:29 PM UTC+2, Rich Hickey wrote: > Introducing clojure.spec > > I'm happy to introduce today clojure.spec, a new core library and support for > data and function specifications in Clojure. > > Better communi

Re: clojure.spec

able for an alpha feature in *any* language. > > > On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote: > Thanks Rich, for this and your work in general. After 15 years of working > with Java, it has been a real joy to find clojure (let's face it, that pun >

Re: clojure.spec possible bug

This was fixed for alpha 3 > On May 26, 2016, at 10:08 AM, Georgi Danov wrote: > > I am trying to match sequences with fixed start and end but varying content. > After lots of experiments I start to suspect there is either bug, or severe > misunderstanding on my side. > Here is one example tha

Re: clojure.spec

If you name (register) your (sub)specs with s/def and you can reuse them as much as you like. (s/def ::argi (s/cat :i integer?)) (s/def ::fnii (s/fspec :args ::argi :ret integer?)) (s/conform ::fnii +) (s/valid? ::argi '(42)) However you are talking about calling ‘instrument’ so I don’t think yo

Re: clojure.spec

; > It would allow overriding a spec based on its context (any ancestor) while > suffix match would only allow overriding a spec based on its closer ancestors > (so one would still need to generate paths or suffixes to emulate that). > > Christophe > > On Wed, May 25, 2016 at

Re: [ANN] Clojure 1.9.0-alpha1

I’d advise everyone concerned/confused about the relationship between spec and data representations to please spend some more time trying to understand spec and, especially, dial back the rhetoric. I know what the Clojure philosophy is, and it’s not some triviality. specs are fundamentally code

Re: clojure.spec

Zh_s*3.x.sTxm9-E.NHr!?b5f0Ir2.u.+bof*-P.r.m_y**e0ntq.W+*.+?Urxe+Xp+/Q} > > #{:_Qi.Qj?dtMZh_s*3.x.sTxm9-E.NHr!?b5f0Ir2.u.+bof*-P.r.m_y**e0ntq.W+*.+?Urxe+Xp+/Q}] > [#{} #{}] [#{} #{}]) > > Reverse argument order to s/and and it works. > > On Monday, May 23, 2016 at 4:12:29 PM UTC+2,

Re: clojure.spec

an fn-returning function, *when instrumented*, should return instrumentation-wrapped fns, I don’t know. I’d be concerned about tracking them lest you can never unstrument them. > On May 25, 2016, at 5:57 PM, Rich Hickey wrote: > > In my mind, fspec is no different than fdef. > >

Re: clojure.spec

ind for fspec performing gen testing rather > than a traditional function contract wrapper a la racket/contract? > > Thanks, > Ambrose > > On Mon, May 23, 2016 at 5:20 PM, Rich Hickey wrote: > I did most of the design of spec in a (paper) notebook. > > The rationale t

Re: clojure.spec

user=> (s/def ::a (s/or :r (s/cat :a ::a) :k keyword?)) :user/a user=> (binding [s/*recursion-limit* 2] (map first (s/exercise ::a 10))) (((:B)) :? (:+/K) (:Xc_D.__.+HC/JaCD) ((:*3)) :gJ1z.o.+?.lC0/!-ZDN9 :D.-?I.q8.z/-5* (:F67jy+2M.bB_.h62Cp+?._X?b6gv4.x+7.Gz_6.v9Tt15/*) :!4J

Re: clojure.spec

actually better anyway. > > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote: > Ok. > > Thanks all who have worked on this, btw. It is incredibly timely for me and > is already great help for a work project. > > --Scott > > On Tue

Re: clojure.spec

Once you are talking about some cross-key predicate you wish to satisfy you are talking about another property of the map itself. So, you can use composition to provide further constraints on the map: (s/and (s/keys …) cross-cutting-pred) keys is not going to be the place for that kind of cross

Re: clojure.spec

:b ::b > :c ::c))) > (time > (count > (binding [s/*recursion-limit* 2] > (gen/sample (s/gen ::a) 3 > ;"Elapsed time: 50106.721779 msecs" > 3 > > Thanks, > Ambrose > > > On Tue, May 24, 2016 at 1:25 PM,

Re: clojure.spec

‘and' and ‘or’ are not currently supported in :opt > On May 24, 2016, at 1:45 PM, scott stackelhouse > wrote: > > I'm having a problem writing a spec for a map with some required keywords and > some optional keywords. The caveat here is that the optional keywords are > all or none... that i

Re: clojure.spec

And now, in the alpha release branching gens *are* lazy, so gen calls on recursive specs are fast. > On May 23, 2016, at 6:49 PM, Rich Hickey wrote: > > Currently gens are not lazy, so entire tree is generated. This is because a) > test.check isn’t lazy either and b) we want

Re: clojure.spec

spec :as s])) > >> > >> (s/gen integer?) > >> ;CompilerException java.lang.NoClassDefFoundError: > >> clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1) > >> > >> Thanks, > >> Ambrose > >> > >> On Mo

Re: clojure.spec

That one’s already fixed if you grab the latest. > On May 23, 2016, at 6:37 PM, Sean Corfield wrote: > > On 5/23/16, 2:29 PM, "Rich Hickey" richhic...@gmail.com> wrote: >> fdef will not add doc metadata (see rationale re: not putting more stuff in >> the n

Re: clojure.spec

fdef will not add doc metadata (see rationale re: not putting more stuff in the namespaces/vars), but specs will be present when you call ‘doc’. That doc enhancement was in a push later in the afternoon. https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9 > On May

Re: clojure.spec

I did most of the design of spec in a (paper) notebook. The rationale tries to capture the salient driving forces. If there is a specific question you have I’d be happy to answer. Rich > On May 23, 2016, at 4:11 PM, Ivan Reese wrote: > > Is there anywhere we can read anything about the design

clojure.spec

Introducing clojure.spec I'm happy to introduce today clojure.spec, a new core library and support for data and function specifications in Clojure. Better communication Clojure is a dynamic language, and thus far we have relied on documentation or external libraries to explain the use and beha

Re: Transducers are Coming

even?))) to leverage parallelism ? > > On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming >

Transducers are Coming

I pushed today the initial work on transducers. I describe transducers briefly in this blog post: http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming This work builds on the work done for reducers, bringing context-independent mapping, filtering etc to other areas, such as core.async

Re: T-shirts?

Official T shirts are finally available! http://clojure.org/swag Thanks for your support, Rich On Jul 29, 2013, at 5:27 PM, s...@ummon.com wrote: > Speaking as the person who "made" the 'Clojure = Simplicity' hoody/t-shirt, I > am more than happy to assign it to the clojure community if wante

Re: [ANN] Counterclockwise - Clojure plugin for Eclipse

Congratulations Laurent! That's fantastic. Thanks for all of your effort on CCW - it's an important contribution. Rich On Oct 10, 2013, at 9:36 AM, Laurent PETIT wrote: > Hi, a new version of Counterclockwise, the Clojure plugin for the > Eclipse IDE, has just been released. > > Hot new feat

[ANN] Cognitect

I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support of

Re: core.async

On Saturday, June 29, 2013 5:16:55 AM UTC-4, Thomas Heller wrote: > > Hey, > > this looks very interesting. However I'm a little concerned about the > semantics of >! and > https://gist.github.com/thheller/5890363 > > (ns thheller.async-test > (:use clojure.test) > (:require [clojure.core.a

Re: core.async

On Saturday, June 29, 2013 1:32:26 AM UTC-4, Brandon Bloom wrote: > > > CSP proper is amenable to certain kinds of automated correctness > analysis. > > No work has been done on that front for core.async as yet. > > Although a far cry from Go's race > detector

core.async

I've blogged a bit about the new core.async library: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html Please try it out. Thanks, Rich -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cloju

Re: Clojure generates unnecessary and slow type-checks

Could you please try your tests against master? Here, I went from 145ms to 85ms going from 1.5.1 to 1.6.0 master. If it's the same for you, someone can git bisect and figure out what's up. Thanks, Rich On Thursday, June 13, 2013 3:02:56 PM UTC-4, Leon Barrett wrote: > > Hi. I've been workin

Re: [ANN] Instaparse 1.0.0

That looks stunning - congrats and thanks! On Apr 9, 2013, at 1:18 AM, Mark Engelberg wrote: > Instaparse is an easy-to-use, feature-rich parser generator for Clojure. The > two stand-out features: > > 1. Converts standard EBNF notation for context-free grammars into an > executable parser.

Re: Clojure/West 2013 videos?

On Mar 25, 2013, at 1:52 PM, Phil Hagelberg wrote: > > Cedric Greevey writes: > >>> Outfits like InfoQ and Confreaks do a very good job, but >>> they use professional staff (who expect to be paid). >> >> And I'm guessing what they're doing is obsolescent, if not already >> obsolete, in that it

Re: STM - a request for "war stories"

On Dec 14, 2012, at 12:55 AM, Paul Butcher wrote: > On 14 Dec 2012, at 00:30, kovas boguta wrote: > >> My recommendation is either "Persistent Datastructures" or "Database as a >> Value" > > Interesting. I'd be interested to hear others thoughts on this. In particular > Rich's > > Rich - wh

Re: Proposed change to let-> syntax

he > Clojure world, but it's learnable. I'll add one more: qual-> ... short for > "qualified threading macro". Each clause is qualified by a test condition. > > Of course, there's always conde-> to borrow from miniKanren and core.logic. > The "

Re: Proposed change to let-> syntax

On Nov 30, 2012, at 4:53 PM, Sean Corfield wrote: > On Fri, Nov 30, 2012 at 7:37 AM, Rich Hickey wrote: > A) let-> becomes as-> > > Fine with that. > > B) test-> becomes cond-> > > Fine with that (because I can't think of anything better). > >

Re: Proposed change to let-> syntax

On Nov 30, 2012, at 1:49 PM, Steve Miner wrote: > I propose guard-> to avoid the cond-> confusion. > Yeah, that came up. Guards in other langs are short circuiting, just like cond. Another in that camp was gate-> -- You received this message because you are subscribed to the Google Groups "C

Re: Proposed change to let-> syntax

On Nov 30, 2012, at 1:15 PM, Alex Baranosky wrote: > I've got a utility function I've been using called `conditionally-transform` > which is a non-macro version of `test->`. I think both cond-> and if-> have > a similar problem in that, if you already understand if/cond/-> then it gives > you

Re: Proposed change to let-> syntax

I'm not satisfied with the names for the new threading macros either. The new names being considered for let->, test-> and when-> are: A) let-> becomes as-> reduces arg order and destructuring expectations. B) test-> becomes cond-> cond-> was the original name, and, protestations about not sh

Clojure turns 5

I released Clojure 5 years ago today. It's been a terrific ride so far. Thanks to everyone who contributes to making Clojure, and its community, great. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure

Re: ANN: codeq

On Oct 10, 2012, at 11:02 AM, Meikel Brandmeyer (kotarak) wrote: > Hi, > > Am Mittwoch, 10. Oktober 2012 16:27:37 UTC+2 schrieb Rich Hickey: > I released a little app today that imports Git repos into Datomic. My hope is > that it can be used as the underpinnings of some inte

ANN: codeq

I released a little app today that imports Git repos into Datomic. My hope is that it can be used as the underpinnings of some interesting Clojure tooling. More info here: http://blog.datomic.com/2012/10/codeq.html Rich -- You received this message because you are subscribed to the Google Gro

Re: ANN: a Clojure docs site, and github organization

On Oct 6, 2012, at 12:02 PM, Jay Fields wrote: > The CA process isn't what stops me from contributing, the post a patch > to Jira is what seems broken to me. I don't even remember how to > create a patch. Clojure is on github - we live in a fork & pull > request world, it's time for Clojure to ge

Re: Question about sets

On Sep 8, 2012, at 7:38 PM, Andy Fingerhut wrote: > Rich: > > I'm not sure what you mean by the not-fastest-path possible that exists in > today's Clojure code, so if you get a chance, see if the below is what you > mean. > > As far as I can tell (i.e. putting debug println's in the Java code

Re: Question about sets

I understand your frustration. But it is important to note that timeliness and feedback are a two-way street. There was a time when changes to Clojure were tried immediately by users, and I'd know within hours if not minutes if I'd introduced something that caused problems for someone. That mat

Re: edn

On Sep 10, 2012, at 8:44 AM, Ben Smith-Mannschott wrote: > On Mon, Sep 10, 2012 at 2:15 PM, Marko Topolnik > wrote: >>> Java has arrays, lists, maps and sets, so does Ruby and Erlang. >>> >>> If they were redundancies in these structures, can't see why these three >>> still >>> maintain this di

Re: edn

Would you mind taking specific requests for clarification to the issues page, so I don't lose track of them? https://github.com/richhickey/edn/issues Thanks, Rich On Sep 9, 2012, at 8:09 AM, Ben Smith-Mannschott wrote: > On Fri, Sep 7, 2012 at 3:01 AM, Rich Hickey wrote: >> I

Re: edn

On Sep 8, 2012, at 9:28 AM, Steven E. Harris wrote: > Michael Fogus writes: > >> Data formats do not exist in a vacuum. They are parsed by languages. >> Some may have a fine-grained distinction between lists, arrays/vectors >> and sets and some may not. > > The concern I have is for someone w

Re: Question about sets

take the value associated with the last occurrence of the same key. > All constructor functions explicitly say this in their doc strings. > > Andy > > On Sep 7, 2012, at 2:06 PM, Rich Hickey wrote: > >> >> On Sep 7, 2012, at 3:35 PM, Sean Corfield wrote: >>

Re: Question about sets

On Sep 7, 2012, at 3:35 PM, Sean Corfield wrote: > On Fri, Sep 7, 2012 at 10:49 AM, Rich Hickey wrote: >> I've added my feedback there >> (http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements) > > Thanx Rich! So the recommendation is: &g

Re: edn

I addressed this here: http://news.ycombinator.com/item?id=4489330 On Sep 7, 2012, at 2:36 AM, Elliot wrote: > On Thursday, September 6, 2012 8:31:59 PM UTC-7, Weber, Martin S wrote: > The question that's left for me is: why vectors and lists? I mean, from a > data format perspective, and a non

Re: Question about sets

Once again, thanks Andy! I've added my feedback there (http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements) Patches implementing that are welcome. Rich On Sep 5, 2012, at 1:57 PM, Andy Fingerhut wrote: > I've copied and pasted Mark's arguments to the Wiki page her

Re: edn

On Sep 7, 2012, at 4:36 AM, Ben Smith-Mannschott wrote: > On Fri, Sep 7, 2012 at 3:01 AM, Rich Hickey wrote: >> I've started to document a subset of Clojure's data format in an effort to >> get it more widely used as a data exchange format, e.g. as an alternative t

Re: edn

On Sep 7, 2012, at 12:33 AM, Daniel Pittman wrote: > On Thu, Sep 6, 2012 at 6:01 PM, Rich Hickey wrote: > >> I've started to document a subset of Clojure's data format in an effort to >> get it more widely used as a data exchange format, e.g. as an alternative to

Re: edn

On Sep 6, 2012, at 11:56 PM, David Nolen wrote: > On Thursday, September 6, 2012, Rich Hickey wrote: > I've started to document a subset of Clojure's data format in an effort to > get it more widely used as a data exchange format, e.g. as an alternative to > JSON. &

Re: edn

On Sep 6, 2012, at 9:52 PM, Weber, Martin S wrote: > Rich: >> On Sep 6, 2012, at 9:10 PM, Weber, Martin S wrote: >>> which problem other than "NIH" is edn solving? - given it's a subset of >>> clojure's data notation, it's not really native clojure either, so you >>> gotta convert to/fro. >> Of

Re: edn

On Sep 6, 2012, at 9:10 PM, Weber, Martin S wrote: > which problem other than "NIH" is edn solving? - given it's a subset of > clojure's data notation, it's not really native clojure either, so you gotta > convert to/fro. Of course it's native Clojure. Being a subset doesn't affect that. Cloju

edn

I've started to document a subset of Clojure's data format in an effort to get it more widely used as a data exchange format, e.g. as an alternative to JSON. Please have a look: https://github.com/richhickey/edn Rich -- You received this message because you are subscribed to the Google Groups

Re: Is the behavior of `+` platform-specific for Clojure and CLJS?

To expound: (+ "we" "er") is a user error. We rely on the runtime type system of the host to efficiently detect type errors. Unfortunately, the JS runtime does not consider that an error, thus it is not generating an exception. That is much different from there being semantics for (+ "we" "er")

Re: Clojure Sticker

You can now get official Clojure stickers here: http://clojure.org/swag I'll be adding T-shirts etc soon. Rich On Jul 19, 2012, at 3:13 PM, charlie wrote: > Yeah any sort of vector image should work for us > > On Wed, Jul 18, 2012 at 7:59 PM, Alex Kurilin wrote: > +1. A temporary workaround

Re: [ANN] Datomic Free Edition

Thanks. The links were fixed, you may need to refresh. On Jul 24, 2012, at 11:48 AM, Mark Engelberg wrote: > Sounds exciting. FYI, the links from the blog post to the pricing and > download pages don't seem to be working. > > -- > You received this message because you are subscribed to the Go

[ANN] Datomic Free Edition

We released a new edition of Datomic today that I think will be of interest to Clojure developers - Datomic Free Edition: http://blog.datomic.com/2012/07/datomic-free-edition.html This edition is oriented around making Datomic easier to get, and use, for open source and smaller production depl

Re: Why cannot "last" be fast on vector?

Wow, this thread was exhausting :) This reply is not to anyone in particular, just tagging on at the end (hint). It is quite easy to come up to some part of Clojure, with some need, and some current perspective, and find it unsatisfying. It certainly is not perfect. But a good presumption is th

Re: Clojure Sticker

No, you are not allowed to reproduce the Clojure logo and put it up for sale. I'd be happy to set up an official way to get stickers/shirts etc. Rich On Jun 11, 2012, at 6:23 PM, Sven Johansson wrote: > I've been trawling the internet for Clojure stickers before and > come up empty. If there'

Re: Reducers

3 4] (mapping inc)) < MISSING PAREN > > > under the heading "Reducers" > > > sincerely, > --Robert McIntyre, Dylan Holmes > > On Tue, May 15, 2012 at 1:58 PM, Rich Hickey wrote: >> I've written another post which goes into the reducers i

Re: Reducers

I've written another post which goes into the reducers in more detail: http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html Rich On May 10, 2012, at 1:26 PM, Christian Romney wrote: > > > On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote: > I can describe the background to

Re: Reducers

IMO, Nicolas' material is a distraction in understanding reducers, except as historical background. The reducers library is a rejection/avoidance of the primacy of recursively/generatively defined data structures and the operations thereon. I recommend, rather than reading about stream fusion,

Re: Reducers

This analogy is not quite right. > (fn [n] (vector n (+ n 1)) is not a reducing fn. Tt is a cons cell builder, and the Church encoding builds lists. The point of this library is to define map/filter etc *without* using lists/streams - not as input, not as output, not producing links/thunks etc

Reducers

I'm happy to have pushed [1] today the beginnings of a new Clojure library for higher-order manipulation of collections, based upon *reduce* and *fold*. Of course, Clojure already has Lisp's *reduce*, which corresponds to the traditional *foldl* of functional programming. *reduce* is based upon

Re: Boolean

You are reporting this to the wrong language group. The fact that Java: A) has a public constructor for Boolean (a type with only 2 possible instances) B) whose doc string says "Note: It is rarely appropriate to use this constructor." and then C) goes on to use it in some library functions (refl

Please announce library releases on the main Clojure group

Are you a Clojure library developer? Did you just cut a release of some sort? Did you mention it on the main Clojure group (clojure@googlegroups.com)? If not, you made a mistake. The group remains a primary means of staying informed about Clojure for thousands of people. Please include it in a

Please try the alphas and betas!

It was nice to get some feedback on the changes in 1.3. It was a bit frustrating though to get them after release, and especially to get them on code that has been available for over 16 months. This after regular Maven releases of alphas starting over a year ago and betas since June. It's a fair

Re: Clojure 1.3 "wonky" behavior

You should use 'do' for that kind of thing, not list. Rich On Oct 20, 2011, at 1:53 PM, Micah Martin wrote: > I recently tried to get Speclj running on Clojure 1.3 and came across the > following problem: > > (list > (declare ^:dynamic p) > (defn q [] @p)) > > (binding [p (atom 10)] > (q))

Re: Clojure 1.3 treatment of integers and longs

How can people toggle between the various commits I mentioned using Maven? Rich On Oct 23, 2011, at 9:52 PM, Stuart Sierra wrote: > As a reminder, you don't need Git to use the latest development version of > Clojure. Just set your Clojure dependency version to "1.4.0-master-SNAPSHOT" > and ad

Re: Clojure 1.3 treatment of integers and longs

Hi all, This reply is to the thread, not Luc specifically. Thanks everyone for your feedback and input. I have pushed 3 commits: 1) Fixes the inconsistency between the hash function used by Clojure maps (was .hashCode) and =. Thanks Paul for the report. 2) Changes core/hash to return the resu

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011

On Oct 21, 2011, at 5:37 PM, daly wrote: > Rich, > > My apologies that what I have said about nil punning came across > as criticism directed at you. It certainly didn't come across that way - no worries :-) Rich -- You received this message because you are subscribed to the Google Groups "

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011

This message is not specifically in reply to Tim, but to the thread in general. It can be very difficult to enumerate (or even remember :) all of the contending tradeoffs around something like Clojure's nil handling. The is no doubt nil punning is a form of complecting. But you don't completely

Re: Mailing List Decorum

he comments of > >> external blogs? Still, it feels to me that the ability to constructively > >> express and communicate *positive* opinion is a powerful source of energy > >> which can cultivate enthusiasm and a general positive attitude within any > >>

Mailing List Decorum

This is just a reminder. While in general our communication here is very good, occasionally it goes astray. These mailing lists are run by, and for, people who make things. Most messages should have one of these forms: I made something - here is my contribution I am trying to use the thing some

Re: Exception handling changes in Clojure 1.3.0

It's not a regression. It is a known breaking change. The change merely owned up the the fact that we cannot in fact communicate all actual errors through Java code, due to checked exceptions. This is an enduring problem with Java, and you are going to see it rear its ugly head in Java itself a

Re: ClojureScript and lein?

This thread is no longer about Clojure - please take it elsewhere. Thanks, Rich On Aug 30, 2011, at 8:54 PM, Ken Wesson wrote: > On Tue, Aug 30, 2011 at 2:19 PM, Phil Hagelberg wrote: >> On Tue, Aug 30, 2011 at 10:10 AM, Ken Wesson wrote: VirtualBox is free: http://www.virtualbox.org/ >

Re: ClojureScript Compile errors

:use … :only doesn't have the problems of full :use. Enhancement ticket and patch for :use … :only welcome. Note it must support :use … :only only, i.e. :only is required. Rich On Aug 9, 2011, at 10:01 AM, David Nolen wrote: > On Sat, Aug 6, 2011 at 5:30 PM, Rich Hickey wrote: >

Re: ClojureScript Compile errors

or ClojureScript names as it is in Clojure? On Friday, August 5, 2011 5:14:36 PM UTC-7, Rich Hickey wrote:On Aug 5, 2011, at 3:06 PM, David Nolen wrote: > On Fri, Aug 5, 2011 at 2:51 PM, Fogus wrote: > The following lines looks problematic: > >(ns mainpage >(:use

Re: ClojureScript Compile errors

On Aug 5, 2011, at 3:06 PM, David Nolen wrote: On Fri, Aug 5, 2011 at 2:51 PM, Fogus wrote: The following lines looks problematic: (ns mainpage (:use lib.dom-helpers)) That is, ClojureScript only supports the (ns foo (:require [a.b :as c])) form. Try changing your ns declaration ac

Re: clojurescript additional js dependencies

That said, it is our intention to look at minimizing the base footprint as far as we can, but that's not top priority at the moment. It is unlikely we can get all the way to zero, but I hope we can do better. Until then, we won't compare favorably on very small programs. But the fact is the core

Re: clojurescript interop problems

On Jul 31, 2011, at 11:00 PM, Jack Moffitt wrote: I'm having some trouble attempting to use interop with ClojureScript. I'm trying to translate examples from the Closure book into ClojureScript, and I keep getting stuck on various things. 1) When using goog.testing, it appears that I can't acc

Re: Problem with ClojureScript and Node.js

Could you please use quoting in your messages? Otherwise they have no context. Thanks, Rich On Jul 28, 2011, at 7:10 PM, Anthony Grimes wrote: Actually, it seems to be caused by this commit: https://github.com/clojure/clojurescript/commit/954e8529b1ec814f40af77d6035f90e93a9126ea If I chec

Re: Generated nodejs code from ClojureScript doesn't include some functions

On Jul 28, 2011, at 6:54 AM, Brenton wrote: Anthony, Did you try deleting the output directory where generated JavaScript files are stored? If core lib JavaScript files exist in this directory they will not be re-compiled. This is an ongoing source of problems and should probably work dif

Re: Bizarre ClojureScript issue

Could you please file a bug report with both your example, the JS code and the explanation? Thanks, Rich On Jul 27, 2011, at 9:48 PM, Anthony Grimes wrote: Hah! That was it! You, sir, are one clever fellow. Thank you very much. -- You received this message because you are subscribed to t

Re: Alright, fess up, who's unhappy with clojurescript?

On Jul 24, 11:19 am, James Keats wrote: > Alright, to be honest, I'm disappointed. > I'll make sure you get a refund then. Seriously, this is like being disappointed an action movie was an action movie instead of a comedy. Your expectations are a complete mismatch for the intentions of Clojure

Re: Future of clojure.contrib.core/-?> macro

On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: On 18 Apr 2011, at 17:47, Laurent PETIT wrote: The -?> and -?>> macros are currently inside "old", "soon to be deprecated" clojure contrib. I must confess that I don't even know what those macros do, so I have no opinion. However, I thin

Re: Unpredictable behavior of Protocol Extension

On Feb 28, 2011, at 8:32 AM, Chas Emerick wrote: I agree with your sentiment. This has been discussed before here: http://groups.google.com/group/clojure-dev/browse_frm/thread/fb3a0b03bf3ef8ca That discussion pretty quickly wandered into the weeds of whether this sort of usage of protocols

Re: locals clearing

On Jan 30, 6:08 am, Daniel Janus wrote: > Hi, > > I've recently heard about the locals clearing feature of Clojure 1.2 (from a > recent post by Ken Wesson), and decided to test-drive it. Here is a > contrived example: > > (defn garbage [] >   (make-array Byte/TYPE 10485760)) > > (defn -main [& a

Re: Funding 2011?

On Jan 4, 2011, at 11:10 AM, Daniel Werner wrote: Hi Rich, On 4 January 2011 06:31, Rich Hickey wrote: I was going to continue the funding effort, but have decided against it for the reasons given here: Regarding the "entitlement [...] as to what I do with my time", I believe

Re: Funding 2011?

On Nov 28, 2010, at 9:07 PM, Jeremy Dunck wrote: In Dec 2009, Rich asked the community to step up and support core development -- and the community came through. I'm interested in clojure, but not using it professionally yet. I was wondering if funding for 2011 has already been worked out, or

Re: Infinite recursion bug in clojure.lang.Keyword.intern()?

On Jan 3, 2011, at 5:43 PM, Eric Tschetter wrote: I started getting StackOverflow exceptions today around clojure.lang.Keyword (I'm running clojure 1.2.0, but the code doesn't seem to be different in github master). It is different in master, this was already fixed. https://github.com/clojur

Re: Speed of clojure hash map vs java hash map

On Dec 28, 2010, at 8:57 PM, Mark Engelberg wrote: Just for fun, I was curious to see what it would be like, performance-wise, to simulate a synchronized mutable hash map by putting a clojure hash map inside an atom, and making this accessible to Java code via the map interface. I didn't try t

  1   2   3   4   5   6   7   8   9   10   >