Re: :keys and :or destructuring where defaults refer to one another

Quoting Michael's Gist: (let [{:keys [bar foo] :or {foo 1 bar (inc foo)}} {}] (assert (= foo 1)) (assert (= bar 2))) The main problem I see with this is that I'd expect the foo in :or to refer to any foo in the enclosing scope. As things stand, whether it does or not depend

Re: :keys and :or destructuring where defaults refer to one another

Common Lisp has a really well thought approach to parameter lambda lists. If you feel strongly about resolving this ambiguity and enforcing consistency around sequential binding in the destructuring syntax, perhaps that would be a good place to root a design you can flesh out in Jira. Here's a

Re: Status of lean runtime?

There's also Kiss, which at least has the potential to run as a fast-loading statically-typed Clojure variant. https://github.com/mikera/kiss Currently I still load clojure.core for bootstrap reasons, but that's not going to be necessary in the future (once kiss.core is complete). I may take a

Re: :keys and :or destructuring where defaults refer to one another

Yep, I spent some time playing with the macro and the macroexpand. It looks like a) it only works if the dependent keys come *before* the keys they depend on (ie the opposite of how you'd order, say, defs) b) this ordering arises entirely from the seq ordering of PersistentArrayMap (keys are stuc

Re: Status of lean runtime?

> > it runs like a dream > Possibly for you - unfortunately not for everyone. On 12 December 2014 at 12:04, Mark Derricutt wrote: > On 12 Dec 2014, at 9:11, Sean Corfield wrote: > > > I’m stunned that JetBrains don’t yet properly support Java 7 or Java 8 - > we’ve been on Java 8 for development

Re: Status of lean runtime?

On 12 December 2014 at 09:11, Sean Corfield wrote: > Java 6 has been EOL for nearly two years. Java 7’s EOL is currently just > four months away. Given that Clojure 1.7 is not yet "gold" and 1.8 will > likely be a year away (based on previous releases), it seems reasonable to > plan to drop Java

Re: :keys and :or destructuring where defaults refer to one another

Whenever you want to get insight in how a macro is rewriting your code, try evaluating your form quoted with macroexpand. Here's a gist with the macroexpansion each form. https://gist.github.com/aamedina/542b084d31d4e0c9a7a8 Hopefully the expansion makes things clear! On Thursday, December

Re: :keys and :or destructuring where defaults refer to one another

I wouldn't have expected either form to work actually; It's interesting that the first does. I would love someone else enlighten us on this, but my guess is that it's something not specified and that you shouldn't rely on. If you want to have optional argument defaults depend on each other, I r

Re: [ANN] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

I've read through the README, but I still don't feel like I understand what problem this library is trying to solve. Could you perhaps provide an example of something that's hard to do with just Component, and easy to do with BigBang? - James On 11 December 2014 at 17:31, JUAN ANTONIO Ruz wrote

:keys and :or destructuring where defaults refer to one another

If I make my defaults on a :keys :or destructuring depend on the values of other keys, I *can* get a compile-time error, depending on what order I give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727 Is this on-spec behavior? Should the former be allowed but not the latter? Shou

Re: Status of lean runtime?

On 12 Dec 2014, at 9:11, Sean Corfield wrote: > I’m stunned that JetBrains don’t yet properly support Java 7 or Java 8 - > we’ve been on Java 8 for development for ages and about half of our > production systems have been upgraded to Java 8 over the last three months. IntelliJ 14 ships with an

Re: Status of lean runtime?

On Dec 11, 2014, at 12:51 PM, Alex Miller wrote: > Ditto what Sean said. There's no decision yet but I plan to recommend > dropping Java 1.6 in Clojure 1.8. I expect we'll gather more input on it > before it happens though. On the subject of planning, perhaps this page needs updating to reflect

Re: Status of lean runtime?

Ditto what Sean said. There's no decision yet but I plan to recommend dropping Java 1.6 in Clojure 1.8. I expect we'll gather more input on it before it happens though. Alex On Thursday, December 11, 2014 2:11:28 PM UTC-6, Sean Corfield wrote: > > Java 6 has been EOL for nearly two years. Java

Re: Status of lean runtime?

Java 6 has been EOL for nearly two years. Java 7’s EOL is currently just four months away. Given that Clojure 1.7 is not yet "gold" and 1.8 will likely be a year away (based on previous releases), it seems reasonable to plan to drop Java 6 support three years after it was EOL’d. A quarter of Clo

Re: Status of lean runtime?

> > That said, Oxcart itself is pretty much dead unless something near my > lib-clojure proposal comes on the radar for Core. See > http://arrdem.com/2014/12/11/oxcart_going_forwards/ for more on this. I would also love to see this change, in particular because it would allow me to use parts of t

Re: Status of lean runtime?

> > In a future Clojure release (post 1.7) we will drop support for Java 1.6 > Please don't. That will mean that Cursive will be stuck on Clojure 1.7 until at least Java 9, and probably later. JDK 6 is still the only recommended JVM for running IntelliJ on the Mac due to significant bugs which pre

Re: [ANN] Clojure Videos (with options for Linux users)

Hello! If you're still interested, the LispCast core.async videos are out and available. They focus on the basics and would be a great introduction the Timothy Baldridge's videos. Rock on! Eric -- You received this message because you are subscribed t

[ANN] BigBang v0.1.1 - compose stuartsierra.component/system-update(s) in start invocation time

Hi folks, I wanted to share here BigBang, my library proposal in customization the way stuartsierra/component system starts. I'll copy here "*Why did I write this library*?" After trying to get working Aspect Oriented Programming and Reverse Dependency Injection in stuartuartsierra/component

Re: futures + refs

Excellent. IF the problem is that your write rate to couchdb can't keep up with the incoming tweet stream (which may be the case) try batching the writes to couch, i.e. instead of firing an update on every single tweet build up a larger batch in that loop, and once you hit a threshold (of your cho

Re: futures + refs

So HBC actually does that already--it dumps tweets into a LinkedBlockingQueue. Right now, I'm doing `(loop [tweet (.take queue)]...`, which, I think, essentially amounts to what you're suggesting, but I could be misunderstanding you. There's a distinct possibility that all the reconnections are ca

Re: futures + refs

Hi Sam, have you tried putting the incoming (hashtag,tweet) tuples into a queue and have another thread pull them out and upload them to couchdb? I'm unfamiliar with HBC, but I assume it has a callback-based API, so you should be able to have multiple callbacks/connections/streams feed the same q

Re: Status of lean runtime?

On 12/11/14 08:09, Alex Miller wrote: > I think Reid said he was planning to pickup Oxcart over the holidays > again. Oxcart really has different goals than Clojure and I don't > expect it to ever directly feed back into Clojure. I may pick Oxcart back up again over winter break. I'm curious what

futures + refs

I've got some code that's using Twitter's HoseBirdClient to pull tweets from the public stream, which I then preprocess and store with CouchDB. Right now, my HBC client is being forced to reconnect more than I'd like, which occasionally causes my app to hang, for reasons I'm not entirely clear

[ANN] Nginx-Clojure v0.3.0 Release!

0.3.0 (2014-12-11) 1. Discard: Directive clojure, clojure_code are no longer supported, use handler_type/content_handler_type, handler_name/content_handler_name, handler_code/content_handler_code instead. 2. Discard: Now handler_*** can not be used to declare a nginx worker initiali

Re: Status of lean runtime?

I also meant to mention that I built working version of the build profile stuff and got about halfway through an overhaul of the build system as well this past summer but it's never been in a form that was complete enough to make public anywhere. I expect that to re-surface as well. -- You rec

Re: Status of lean runtime?

I've done a fair amount of testing on fastload for Rich, as well as on the direct branch, which further extends some experimental work on static var invocation. Fastload does indeed reduce startup time by making var loading lazy. However, it also adds an additional check into the var invocation