[ANN] clafka 0.2.2

[dan . stone16321]

A new version of https://github.com/mixradio/clafka has been released.

clafka is a library providing an idiomatic clojure api for kafka's 
SimpleConsumer and KafkaProducer. It is intended to be used as the basis 
for consumers whose needs are not met by the 
zookeeper consumer that is included with kafka itself.

Since the last announcement:

- A pooled client has been added so you can worry less about finding 
partition leaders.
- publish! and publish-ack! allow you to specify the partition to publish 
to.
- The consumer api is now based on a protocol (IBrokerClient). Both the 
SimpleConsumer and the PooledClient implement this interface.

As always, contributions are very welcome!

Cheers!

Dan

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Colin Fleming]

Note that IntelliJ will actually do Python and Clojure in the same (free,
OSS) IDE if you only need the community edition of Python, i.e. you don't
need support for frameworks like Django or the web stuff.

If you do need the Ultimate edition of IntelliJ, you can get free licences
for open source and/or academic work by applying to JetBrains.

On 7 August 2015 at 01:26, kirby urner  wrote:

>
> To recap this thread:  I started by looking at GitHub's Atom as an IDE for
> Asynchronous Learning Engine (ALE), a name I'm using for an
> Open Source project.  I'm interested in Clojure + Java + Python as
> an example "flight path" through our "curriculum space".
>
> Turns out Eclipse is a strong candidate if a single IDE is required.
>
> IntelliJ with Cursive is where I'm starting, great beginning!  I use
> PyCharm at work.
>
> I now have Python and Clojure both implementing a special kind
> of vector class using PyDev for Python and CounterClockwise
> for Clojure:
>
> http://mybizmo.blogspot.com/2015/08/eclipse-for-python-java-clojure.html
>
> Just screen shots at this point.
>
> I'm finding much to like in the ease of use department.
>
> Eclipse remains a strong contender though of course Emacs can do all this
> too.
>
> Kirby
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Anotating functions for pre-processing

[Shantanu Kumar]

Hi Georgi,

Have you seen this thread?
https://groups.google.com/forum/#!topic/clojure/0hKOFQXAwRc

Shantanu

On Wednesday, 5 August 2015 17:28:42 UTC+5:30, Georgi Danov wrote:
>
> Hi,
>  I have had good 6 months of fun with Clojure and have big appreciation 
> for it's way of doing things. Coming from the Java/Spring world however, I 
> still have this nagging desire to be able to annotate functions and have 
> some preprocessor pick up these annotations and decorate the code 
> accordingly. Let me illustrate it:
>
> In Java + Spring
> @Transactional
> public void someFunction(){...}
>
> the Spring core container has excellent support for preprocessors to 
> instrument this function with some advice.
>
> -
>
> I wish I could do that in Clojure:
>
> (defn ^:transactional someFunction [...] ...)
>
> and then have somehow means to decorate someFunction (yes, I am aware 
> there is no container)
>
> I have read some blog posts (about dependency injection in the context of 
> testing clojure) that discuss *alter-var-root,* but that looks like very 
> brutal approach.
>
> What would be the advice on that? I am even happy to go with solution that 
> involves some micro-container spring-like approach.
>
> Cheers
>

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

Size of Java serialized Clojure data structures

[icamts]

Hi all,
I opened this issue on github project prevayler-clj

https://github.com/klauswuestefeld/prevayler-clj/issues/1

because 1M short vectors, like this [:a1 1], forming the state of the 
prevayler, results in 1GB file size when serialized, one by one, with Java 
writeObject.

Is it possible? About 1kB for each PersistentVector? Further investigations 
demonstrated the same amount of vectors can be serialized in a 80MB file. 
So, what's going wrong in prevayler serialization?

Any suggestion is welcome. Thanks in advance.

Luca

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

REPL-Driven Techniques?

[Tim Visher]

Hi Everyone,

I'm taking part in an effort to introduce REPL-Driven Development at my 
shop. The shop has historically been based in PHP/Python/javascript and 
similar languages and most devs there have their workflows formed by that 
technology.

I'm used to using a REPL or REPL-connected editor to develop and debug code 
but I've always struggled to articulate exactly why and how I go about 
doing that, other than saying that it "tightens the feedback loop like 
nothing I've ever seen," which I think is descriptive yet still not 
particularly helpful.

I'm wondering if there's a collection of techniques somewhere online. I've 
spent some time googling for things like it but I'm coming up mostly empty.

I watched this years ago and it seems 
pertinent: https://www.youtube.com/watch?v=_B_4vhsmRRI

I also found Jay Field's RDD post which I had read before, but sort of just 
states the same thing I already said.

Some examples of techniques that aren't possible without a REPL

1. (def *foo* (arbitrary expression))

Modify a function definition to capture a var and then run what you're 
working on to have a value you can interact with as you continue to 
develop. This is also incredibly useful when debugging code because you can 
capture the args to a function and then work with and inspect them offline.

If you need to capture something in a let chain you can `_ (def …)` handily.

2. Interactively modify a function definition when you believe you have a 
solution and verify that it works immediately (no release!)

I think the thing that I find hard to express about this is that all the 
advice boils down to "You have the entirety of your language instantly at 
your disposal to debug and develop anything" which is both true and not 
very helpful if the tightest feedback loop you've used is TDD.

Any ideas?

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
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 1.7.28 - Optional Self Hosting

[David Nolen]

No. ClojureScript's macro system isn't going to change.

See
https://github.com/clojure/clojurescript/wiki/Bootstrapped-ClojureScript-FAQ
.

David

On Thu, Aug 6, 2015 at 11:27 PM, Matthew Molloy  wrote:

> Hi David,
>
> Are macros supported directly within clojurescript then?  I'm having some
> trouble compiling a macro via defmacro.
>
> Matt
>
> On Saturday, August 1, 2015 at 1:52:23 AM UTC+8, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > Leiningen dependency information:
> >
> >
> > [org.clojure/clojurescript "1.7.28"]
> >
> >
> > ClojureScript now has a proper version number. This version number is
> > designed to reflect feature parity with Clojure.
> >
> >
> > The primary new feature of this release is optional
> > self hosting. ClojureScript can now run either on the JVM or directly on
> > JavaScript. Please refer to the docstrings in the new cljs.js
> > namespace for details on this functionality. cljs.js is designed to
> > enable new use cases (iOS, Android, interactive tutorials, snippet
> > sharing) not well served by the default compilation model.
> >
> >
> > The release also includes numerous bug fixes and enhancements.
> >
> >
> > This release also bumps the Clojure dependency to 1.7.0 and
> > tools.reader to 0.10.0-alpha3.
> >
> >
> > As always feedback welcome!
> >
> >
> > ## 1.7.28
> >
> >
> > ## Enhancements
> > * New namespace cljs.js provides analysis, compilation, and eval
> > * CLJS-1360: Refactor JS module processing to work with recent Google
> Closure compiler changes
> > * CLJS-1282: Add a :pprint option to the default reporter in cljs.test
> > * CLJS-1308: :analyze-path should be extended to take a vector of paths
> > * CLJS-1230: ES 2015 Module Processing
> > * CLJS-1231: AMD Module Processing
> > * CLJS-1092: CommonJS Module processing
> >
> >
> > ## Changes
> > * CLJS-1376: Printing in a tagged literal data form
> > * CLJS-836: Replace seq-based iterators with direct iterator for all
> non-seq collections that use SeqIterator
> > * CLJS-1367: Expose default-warning-handler and warning-enabled?
> > * CLJS-1267: Added the :end-test-all-vars and :end-test-vars events to
> have end events for all cljs.test api functions
> > * CLJS-1337: Move parse ns side-effects into a separate compiler pass
> > * CLJS-1247: Split out error printing from regular printing
> > * CLJS-1329: Support for reading #js tagged literals in bootstrap
> > * CLJS-1191: rebased patch Update clojure.walk to the current version on
> clojure
> > * CLJS-1321: remove getNamespace & getName method calls from defrecord
> > * CLJS-1281: Preserve test order
> > * CLJS-934: In the REPL return vars after defs
> >
> >
> > ## Fixes
> > * CLJS-1316 let does not detect invalid binding vector when it contains
> destructuring
> > * CLJS-1033: take a drop accept nil as n argument
> > * CLJS-1324: Compiler fails to raise warning/error when invoking a
> keyword without arguments
> > * CLJS-1352: cljs.js: Allow conditional readers
> > * CLJS-1348: meta is printing for def at REPL
> > * CLJS-1342: cljs.reader/read-string should throw Error when not called
> with string
> > * CLJS-1341: Fix CommonJS conversion bug
> > * CLJS-1333: Analyze meta on quoted symbols
> > * CLJS-1210: Javascript built-in arguments replaces nil arguments
> locally defined by let
> > * CLJS-1248: alter-meta! does not work on vars
> > * CLJS-1276: var equality differs from Clojure
> > * CLJS-1310: ns libspec error message misses :import
> > * CLJS-428: Added step to escape docstrings with */ and associated test
> > * CLJS-1331: Regex literal emits invalid JS
> > * CLJS-1338: NPE in confirm-var-exists if suffix is ".."
> > * CLJS-1319: Cannot locate module namespace when filename contains dash
> > * CLJS-1317: Incremental compilation issues for :nodejs target
> > * CLJS-1227 Raise error when if form has more than 4 statements
> > * CLJS-1306: Browser REPL :asset-path with leading slash breaks source
> map support
> > * CLJS-1290: :refer does not work with Closure JS namespaces
> > * CLJS-1307: Doc for ns missing
> > * CLJS-1301: local :foreign-libs are not picked up the first time
> browser REPL is started
>
> --
> 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.
>

-- 
Y

Re: Size of Java serialized Clojure data structures

[Gary Verhaegen]

You should probably look at Clojure-specific solutions, starting with EDN
(i.e. essentially pr-str), fressian, transit or nippy.

Clojure data structures have a lot of properties that can be exploited (we
only care about the abstract type and the actual data), so a serializer can
make a lot of assumptions that a generic Java solution can't.

On Friday, 7 August 2015, icamts  wrote:

> Hi all,
> I opened this issue on github project prevayler-clj
>
> https://github.com/klauswuestefeld/prevayler-clj/issues/1
>
> because 1M short vectors, like this [:a1 1], forming the state of the
> prevayler, results in 1GB file size when serialized, one by one, with Java
> writeObject.
>
> Is it possible? About 1kB for each PersistentVector? Further
> investigations demonstrated the same amount of vectors can be serialized in
> a 80MB file. So, what's going wrong in prevayler serialization?
>
> Any suggestion is welcome. Thanks in advance.
>
> Luca
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Gary Verhaegen]

Sorry for steering the discussion away from tooling, but have tou looked at
Racket and the research in teaching programming that's been going on around
it for the past ~20 years?

One of their findings was that beginning with functional programming (1
semester FP followed by 1 semester OOP) yielded better OOP prpgrammers than
a full year of OOP teaching. Some of them have recently branched out from
the original scheme-base syntax to a more python-like one. If you're
designing a curriculum for teaching FP and OOP I believe it's worth
investigating.

And to steer back towards tooling, you could then use DrRacket, which is a
fantastic beginner's editor with debugger and code analyzer integrated.

On Friday, 7 August 2015, Colin Fleming  wrote:

> Note that IntelliJ will actually do Python and Clojure in the same (free,
> OSS) IDE if you only need the community edition of Python, i.e. you don't
> need support for frameworks like Django or the web stuff.
>
> If you do need the Ultimate edition of IntelliJ, you can get free licences
> for open source and/or academic work by applying to JetBrains.
>
> On 7 August 2015 at 01:26, kirby urner  > wrote:
>
>>
>> To recap this thread:  I started by looking at GitHub's Atom as an IDE
>> for
>> Asynchronous Learning Engine (ALE), a name I'm using for an
>> Open Source project.  I'm interested in Clojure + Java + Python as
>> an example "flight path" through our "curriculum space".
>>
>> Turns out Eclipse is a strong candidate if a single IDE is required.
>>
>> IntelliJ with Cursive is where I'm starting, great beginning!  I use
>> PyCharm at work.
>>
>> I now have Python and Clojure both implementing a special kind
>> of vector class using PyDev for Python and CounterClockwise
>> for Clojure:
>>
>> http://mybizmo.blogspot.com/2015/08/eclipse-for-python-java-clojure.html
>>
>> Just screen shots at this point.
>>
>> I'm finding much to like in the ease of use department.
>>
>> Eclipse remains a strong contender though of course Emacs can do all this
>> too.
>>
>> Kirby
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> 
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: New version of core.async?

[Sean Johnson]

Alex,

+1

Glad to hear you're going to get a new core.async out. That's huge. In 
particular the old tools.analyzer.jvm dependency seems to be causing lots 
of problems using core.async in bigger projects that use other macro 
powered libraries.

Cheers,
Sean


On Thursday, August 6, 2015 at 7:43:49 AM UTC-4, Alex Miller wrote:
>
> I don't know about that particular ticket but I expect to spend some time 
> on async in the near future and get a release out.

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

Clojure beyond Java 6 ?

[Morten Christensen]

I am new to Clojure which I am evaluating using Clojure for a Java 8 based 
framework with code in clojure, java and possibly other jvm based languages 
that all need to interoperate.

Clojure has many smart features which I like but there is at least one 
drawback. I could be wrong (?) but it appears to me that feature-wise it is 
limited to a legacy version of java - Java version 6 from 2008.

Happily Clojure tolerate running under Java 7/8 but I have found no 
specific support for Java 7/8 features. In particular there is no support 
for NIO 2.0 or interoperability support for @FunctionalInterface, 
java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc. 

I could do my own Clojure wrapper for NIO 2 but it seems to be quite hard 
for that particular tech (other people in the community have tried without 
being 100% complete and could not find anything that is actively 
maintained). All the other stuff seems like something that need in Clojure 
itself along with invokedynamic and other optimizations. 

Is there any plans for actively supporting Java 7/8 ?

/Morten

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

Clojure beyond Java 6 ?

[Alex Miller]

The plan for Clojure 1.8 is to retain Java 1.6 support. After that, it is 
something we will continue evaluating.

It is possible in some cases to provide jdk-specific features as is done with 
the fork/join library and a few other things. If you have a specific 
enhancement request, feel free to file a jira.

Alex

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

Re: Size of Java serialized Clojure data structures

[icamts]

Yes. I suggested nippy. The question is about the size of Java serialized 
Clojure data structures. Can a two element vector be 1kB in size? Why 
serialization in my REPL experiment (see the code following the link in my 
previous mail) produces a 80MB byte buffer while prevayler logs are 1GB?

Il giorno venerdì 7 agosto 2015 13:51:45 UTC+2, Gary Verhaegen ha scritto:
>
> You should probably look at Clojure-specific solutions, starting with EDN 
> (i.e. essentially pr-str), fressian, transit or nippy.
>
> Clojure data structures have a lot of properties that can be exploited (we 
> only care about the abstract type and the actual data), so a serializer can 
> make a lot of assumptions that a generic Java solution can't.
>
>>
>>

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

Atoms, reference to itself cause StackOverflowError

[Simone Mosciatti]

Hi all,

I noticed this behaviour that I was not expecting:

simo@simo:~$ lein repl
nREPL server started on port 42010 on host 127.0.0.1 - 
nrepl://127.0.0.1:42010
REPL-y 0.3.5, nREPL 0.2.6
Clojure 1.6.0
OpenJDK 64-Bit Server VM 1.7.0_79-b14
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (def a (atom {}))
#'user/a
user=> (swap! a assoc :self a)

StackOverflowError   java.util.regex.Pattern$GroupHead.match 
(Pattern.java:4556)
user=> (swap! a assoc :test :ok)

StackOverflowError   java.lang.Character.codePointAt (Character.java:4668)
user=> a

StackOverflowError   java.util.regex.Pattern$Curly.match0 
(Pattern.java:4148)
user=> (def b (atom {}))
#'user/b
user=> (swap! b assoc :test :ok)
{:test :ok}

It is something expected or I should open a bug report ?

Greets

Simone

-- 
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: Atoms, reference to itself cause StackOverflowError

[Stuart Sierra]

Hi Simone,

The stack overflow here is caused by the REPL trying to print a circular 
reference. `swap!` always returns the new value of the Atom, and the REPL 
tries to print it.

If you don't print the Atom, this self-reference can still work:

user=> (def a (atom {}))
#'user/a
user=> (do (swap! a assoc :self a) nil)
nil
user=> (= a (:self @a))
true

–S


On Friday, August 7, 2015 at 9:42:05 AM UTC-4, Simone Mosciatti wrote:
>
> Hi all,
>
> I noticed this behaviour that I was not expecting:
>
> simo@simo:~$ lein repl
> nREPL server started on port 42010 on host 127.0.0.1 - nrepl://
> 127.0.0.1:42010
> REPL-y 0.3.5, nREPL 0.2.6
> Clojure 1.6.0
> OpenJDK 64-Bit Server VM 1.7.0_79-b14
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (def a (atom {}))
> #'user/a
> user=> (swap! a assoc :self a)
>
> StackOverflowError   java.util.regex.Pattern$GroupHead.match 
> (Pattern.java:4556)
> user=> (swap! a assoc :test :ok)
>
> StackOverflowError   java.lang.Character.codePointAt (Character.java:4668)
> user=> a
>
> StackOverflowError   java.util.regex.Pattern$Curly.match0 
> (Pattern.java:4148)
> user=> (def b (atom {}))
> #'user/b
> user=> (swap! b assoc :test :ok)
> {:test :ok}
>
> It is something expected or I should open a bug report ?
>
> Greets
>
> Simone
>

-- 
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: Atoms, reference to itself cause StackOverflowError

[Simone Mosciatti]

Thank you :)

Extremely clear !

On Friday, August 7, 2015 at 3:48:14 PM UTC+2, Stuart Sierra wrote:
>
> Hi Simone,
>
> The stack overflow here is caused by the REPL trying to print a circular 
> reference. `swap!` always returns the new value of the Atom, and the REPL 
> tries to print it.
>
> If you don't print the Atom, this self-reference can still work:
>
> user=> (def a (atom {}))
> #'user/a
> user=> (do (swap! a assoc :self a) nil)
> nil
> user=> (= a (:self @a))
> true
>
> –S
>
>
> On Friday, August 7, 2015 at 9:42:05 AM UTC-4, Simone Mosciatti wrote:
>>
>> Hi all,
>>
>> I noticed this behaviour that I was not expecting:
>>
>> simo@simo:~$ lein repl
>> nREPL server started on port 42010 on host 127.0.0.1 - nrepl://
>> 127.0.0.1:42010
>> REPL-y 0.3.5, nREPL 0.2.6
>> Clojure 1.6.0
>> OpenJDK 64-Bit Server VM 1.7.0_79-b14
>> Docs: (doc function-name-here)
>>   (find-doc "part-of-name-here")
>>   Source: (source function-name-here)
>>  Javadoc: (javadoc java-object-or-class-here)
>> Exit: Control+D or (exit) or (quit)
>>  Results: Stored in vars *1, *2, *3, an exception in *e
>>
>> user=> (def a (atom {}))
>> #'user/a
>> user=> (swap! a assoc :self a)
>>
>> StackOverflowError   java.util.regex.Pattern$GroupHead.match 
>> (Pattern.java:4556)
>> user=> (swap! a assoc :test :ok)
>>
>> StackOverflowError   java.lang.Character.codePointAt (Character.java:4668)
>> user=> a
>>
>> StackOverflowError   java.util.regex.Pattern$Curly.match0 
>> (Pattern.java:4148)
>> user=> (def b (atom {}))
>> #'user/b
>> user=> (swap! b assoc :test :ok)
>> {:test :ok}
>>
>> It is something expected or I should open a bug report ?
>>
>> Greets
>>
>> Simone
>>
>

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

On Fri, Aug 7, 2015 at 5:02 AM, Gary Verhaegen 
wrote:

> Sorry for steering the discussion away from tooling, but have tou looked
> at Racket and the research in teaching programming that's been going on
> around it for the past ~20 years?
>
> One of their findings was that beginning with functional programming (1
> semester FP followed by 1 semester OOP) yielded better OOP prpgrammers than
> a full year of OOP teaching. Some of them have recently branched out from
> the original scheme-base syntax to a more python-like one. If you're
> designing a curriculum for teaching FP and OOP I believe it's worth
> investigating.
>
> And to steer back towards tooling, you could then use DrRacket, which is a
> fantastic beginner's editor with debugger and code analyzer integrated.
>
>
Thanks for these thoughts.

By way of background...

Yes, I checked into DrScheme / PLT before it became Racket.  At the time I
was on a pilgrimage, away from my commercial bread and butter language, the
lowly Xbase, and seeking "computer graphics" (so I could do more geometry
on the side).  I went to Java then Scheme, then became enamored of J which
I suppose is functional (its heritage is APL).  Then Python (while still
earning my bread and butter with Xbase i.e. VFP9).

We stereotype kid-newcomers to programming as demanding to "write games"
but that's putting words in their mouths, a lot of 'em anyway, as many'd be
just as happy with some fancy visuals, both moving and still.  Fractals (as
in Mandelbrots and Mandelbulbs) fit here.

A language like Mathematica can provide 2D and 3D visuals. Our school had
pre-OST (O'Reilly) roots in working with Wolfram, round tripping those
notebooks twixt calc students and their teachers (this was before I
joined).

But in using a dedicated ray tracer (in this curriculum, POV-Ray) you're
less confined to "mathematical" topics i.e. go ahead and do photo-realistic
art (plus it's free, which Mathematica only is on a Pi, right?).

So in my Python for kid-newcomers, my back end has been

(A)  for 2D:  POV-Ray, the free ray tracer (povray.org, CompuServ license)
and
(B)  for 3D:  a lot of Visual Python (vpython.org) -- once it came down the
pike, with VRML before that (the Ux is quite similar -- rotate colorful
shapes in real time, that your program defined).

Here's a summary of how I'd mix 'em for my classrooms in Portland Oregon
(often under the auspices of saturdayacademy.org):

http://www.4dsolutions.net/ocn/pymath.html

The individual stills you get from a POV-Ray may be strung together into
movies ("cartoons" lets call 'em).

So I'm really explaining the movie industry and the fact of "render farms"
behind rendered movies like Shrek and Toy Story.  For kid-newcommers, this
information is relevant as most of 'em are already avid movie and TV
program consumers -- and we want them to be makers of same (active not just
passive -- both produce *and* consume).

Back to your points:

Saying good grounding in FP makes for better OOP programmers does indeed
sound credible.

But in a way that can be a matter of style i.e Python may be used to
emphasize immutability, or to create a bog of mushy objects all secretly
connected underground by tendrils.  Python is like clay in that way.

So for example, with my Quadrays (a defrecord in Clojure), when I negate
one, I could have had it "stay the same vector, just now facing the other
way" i.e. give it mutable state.

But if direction can change and yet we say it's "the same", then what
*can't* change?  It gets messy when you let "the same things" mutate.

So I of course don't do it that way.

The VectorOps protocol is about returning new immutable Quadrays (or XYZ
vectors), Clojure style.  -v1 creates a new Vector, versus changing the
state of v1.

Saying FP -> OOP is a useful pattern maybe somewhat subversive of what's
preached in the strict FP camp?

Some of the most theological say you won't need a life after FP, i.e. why
would we even bother with an OOP language?  Would anyone still care for
them?  Saying FP makes good OOP coders begs the question of whether we want
any OOP coders.  Some FPers are eager to stomp 'em out perhaps?  That's
extremist, I agree.

Realistically, the two camps are meeting in the middle as Python can be
used in FP-ish ways, plus there's Hy, which overlays a LISP syntax,
targeting the same VM. https://github.com/hylang/hy

That Clojure shares a JVM with OOP's Java is the ultimate truce, right?  So
we could just make it more a circle or spiral (of styles more than just
languages) and go FP -> OOP -> FP -> OOP... in some kind of chaotic
oscillation. Isn't that what we mean by "inter-op" already?  :-D

Kirby

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

Re: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

On Fri, Aug 7, 2015 at 7:29 AM, kirby urner  wrote:

>
> So in my Python for kid-newcomers, my back end has been
>
> (A)  for 2D:  POV-Ray, the free ray tracer (povray.org, CompuServ
> license) and
> (B)  for 3D:  a lot of Visual Python (vpython.org) -- once it came down
> the pike, with VRML before that (the Ux is quite similar -- rotate colorful
> shapes in real time, that your program defined).
>
>
Actually (quick addendum), POV-Ray does stellar 3D stills... it's the Time
dimension that gets between 2D and 3D (as I'm leaving out a true Z given
screens are really flat).  With VPython as with VRML you have that
"twirling a polyhedron with a mouse" experience, whereas in 2D, it's a
"still life".

Kirby

-- 
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: Clojure beyond Java 6 ?

[James Reeves]

Java 6 can be thought of as the minimum version of the JVM that Clojure
supports.

Regarding NIO2, it's worth pointing out that Clojure itself only has
minimal wrapping around blocking streams, and nothing for NIO1. Using Java
APIs directly in Clojure is not uncommon.

Incidentally, java.lang.AutoCloseable should already be compatible with
clojure.core/with-open.

A cleaner way of interacting with Java's lambdas would be nice, but I
haven't come across any difficulties personally as of yet.

- James


On 7 August 2015 at 12:27, Morten Christensen  wrote:

> I am new to Clojure which I am evaluating using Clojure for a Java 8 based
> framework with code in clojure, java and possibly other jvm based languages
> that all need to interoperate.
>
> Clojure has many smart features which I like but there is at least one
> drawback. I could be wrong (?) but it appears to me that feature-wise it is
> limited to a legacy version of java - Java version 6 from 2008.
>
> Happily Clojure tolerate running under Java 7/8 but I have found no
> specific support for Java 7/8 features. In particular there is no support
> for NIO 2.0 or interoperability support for @FunctionalInterface,
> java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc.
>
> I could do my own Clojure wrapper for NIO 2 but it seems to be quite hard
> for that particular tech (other people in the community have tried without
> being 100% complete and could not find anything that is actively
> maintained). All the other stuff seems like something that need in Clojure
> itself along with invokedynamic and other optimizations.
>
> Is there any plans for actively supporting Java 7/8 ?
>
> /Morten
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[ANN] Neanderthal 0.3.0 with GPU matrix operations released

[Dragan Djuric]

New and noteworthy:
1. GPU engine now available (OpenCL 2.0 required, works superfast on AMD 
Radeons and FirePros)
2. Support for pluggable engines and datastructures (so pure Java engine 
would be relatively easy to add)

*** New, very detailed tutorials with benchmarks available ** Discuss 
at https://news.ycombinator.com/item?id=10022776 
*

http://neanderthal.uncomplicate.org

-- 
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: Clojure beyond Java 6 ?

[James Elliott]

This fact has become hugely important for me, as it allowed me to host my 
Clojure-based lighting control system inside Cycling ’74’s Max visual 
data-flow environment for music, synthesis and video. Their Java 
integration on the Mac currently requires the use of the legacy Apple VM, 
which is Java 1.6. I had to fork a couple of libraries Afterglow depends on 
(the ones which included Java source) in order to get them to compile Java 
1.6 compatible classes, but once I had done that, everything worked, and it 
opened the system up to a focused audience of exactly the kind of motivated 
tinkerers that it is aimed at.

I don’t know if or when Cycling ‘74 are going to update MXJ, their Max to 
Java bridge, to be compatible with Oracle JVMs, so I am relieved to hear 
that Clojure is planning to remain compatible with Java 1.6 for a while.

On Friday, August 7, 2015 at 7:51:49 AM UTC-5, Alex Miller wrote:
>
> The plan for Clojure 1.8 is to retain Java 1.6 support. After that, it is 
> something we will continue evaluating.
>
> It is possible in some cases to provide jdk-specific features as is done 
> with the fork/join library and a few other things. If you have a specific 
> enhancement request, feel free to file a jira.
>
> Alex
>
>

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

Re: ANN: ClojureScript 1.7.28 - Optional Self Hosting

[Matthew Molloy]

Sorry, what I meant was can bootstrapped ClojureScript do (:require-macros ...) 
without the JVM.  Perhaps you can clarify that FAQ to say that.

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

Clojure Truck Factor

[Guilherme Avelino]

As part of my PhD research on code authorship, we calculated the Truck 
Factor (TF) of some popular GitHub repositories.

As you probably know, the Truck (or Bus) Factor designates the minimal 
number of developers that have to be hit by a truck (or quit) before a 
project is incapacitated. In our work, we consider that a system is in 
trouble if more than 50% of its files become orphan (i.e., without a main 
author).

More details on our work in this preprint: https://peerj.com/preprints/1233

We calculated the TF for *Clojure* and obtained a value of *2*.

The developers responsible for this TF are:

Rich Hickey - author of 58% of the files
Stuart Halloway - author of 27% of the files

To validate our results, we would like to ask *Clojure* developers the 
following three brief questions:

(a) Do you agree that the listed developers are the main developers of 
*Clojure*?

(b) Do you agree that *Clojure* will be in trouble if the listed developers 
leave the project (e.g., if they win in the lottery, to be less morbid)?

(c) Does *Clojure* have some characteristics that would attenuate the loss 
of the listed developers (e.g., detailed documentation)?

Thanks in advance for your collaboration,

Guilherme Avelino
PhD Student
Applied Software Engineering Group (ASERG)
UFMG, Brazil
http://aserg.labsoft.dcc.ufmg.br/

-- 
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: Clojure Truck Factor

[Alex Miller]

Hi Guilherme,

As the language creator and owner, Rich is obviously a critical part of the 
team that directs and maintains Clojure and if he was no longer involved 
there would be a significant impact. That said, Clojure is backed by a 
company (Cognitect) and a community of 10k's of developers and there are 
many people intimately familiar with both the codebase and the language. 
Being backed by a company mitigates a significant amount of risk.

As to your actual study, I don't know that I agree with your methodology or 
conclusions. Over long lifetimes, open source projects often go through a 
series of primary maintainers and key contributors do not always have the 
same footprint as the initial developers (just as a matter of how code 
grows). I also don't think you can truly run "experiments" on something 
like this without taking a large open-source project with a large community 
and actually removing key developers to see what would happen. My 
expectation is that there would obviously be an impact in direction and 
velocity of development but that the project would survive just fine if the 
community is large enough.

Alex
 

On Friday, August 7, 2015 at 11:21:40 AM UTC-5, Guilherme Avelino wrote:
>
> As part of my PhD research on code authorship, we calculated the Truck 
> Factor (TF) of some popular GitHub repositories.
>
> As you probably know, the Truck (or Bus) Factor designates the minimal 
> number of developers that have to be hit by a truck (or quit) before a 
> project is incapacitated. In our work, we consider that a system is in 
> trouble if more than 50% of its files become orphan (i.e., without a main 
> author).
>
> More details on our work in this preprint: 
> https://peerj.com/preprints/1233
>
> We calculated the TF for *Clojure* and obtained a value of *2*.
>
> The developers responsible for this TF are:
>
> Rich Hickey - author of 58% of the files
> Stuart Halloway - author of 27% of the files
>
> To validate our results, we would like to ask *Clojure* developers the 
> following three brief questions:
>
> (a) Do you agree that the listed developers are the main developers of 
> *Clojure*?
>
> (b) Do you agree that *Clojure* will be in trouble if the listed 
> developers leave the project (e.g., if they win in the lottery, to be less 
> morbid)?
>
> (c) Does *Clojure* have some characteristics that would attenuate the 
> loss of the listed developers (e.g., detailed documentation)?
>
> Thanks in advance for your collaboration,
>
> Guilherme Avelino
> PhD Student
> Applied Software Engineering Group (ASERG)
> UFMG, Brazil
> http://aserg.labsoft.dcc.ufmg.br/
>

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

0.1.0 core.async release?

[Kyle R. Burton]

Is there a new release planned for core.async anytime in the near future?

The docs show some functionality that's not in the current release [1].
Specifically offer! [2] which looks like it's slated for 0.1.0 (love to
switch to that from alts+timeout).

Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)

Regards,

Kyle



[1] https://github.com/clojure/core.async shows Latest release:
0.1.346.0-17112a-alpha
[2] http://clojure.github.io/core.async/#clojure.core.async/offer!

-- 
Twitter: @kyleburton
Github: https://github.com/kyleburton
Blog: http://asymmetrical-view.com/
Fun: http://snapclean.me/

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

(fail promise exception)

[William la Forge]

A future fails when it throws an exception. How to do that with a future?

It looks like (fail future exception) does not do the 
trick: http://dev.clojure.org/display/design/Promises

-- 
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: (fail promise exception)

[Francis Avila]

Futures automatically capture exceptions raised in their bodies and reraise 
them when the future is derefed. Promises also throw exceptions when 
derefed.

Unlike promises, futures are created with the code that delivers their 
value, so calling fail and deliver explicitly on a future makes no sense.

Think of futures as a thin wrapper around a promise which spawns a thread, 
runs the code, and to the wrapped promise either delivers the result of the 
code or calls (fail private-promise raised-exception) for you.

On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote:
>
> A future fails when it throws an exception. How to do that with a future?
>
> It looks like (fail future exception) does not do the trick: 
> http://dev.clojure.org/display/design/Promises
>
>

-- 
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: (fail promise exception)

[William la Forge]

Sorry, I meant to ask how to fail with a promise? It seems that there is no 
fail method.

On Friday, August 7, 2015 at 4:52:47 PM UTC-4, Francis Avila wrote:
>
> Futures automatically capture exceptions raised in their bodies and 
> reraise them when the future is derefed. Promises also throw exceptions 
> when derefed.
>
> Unlike promises, futures are created with the code that delivers their 
> value, so calling fail and deliver explicitly on a future makes no sense.
>
> Think of futures as a thin wrapper around a promise which spawns a thread, 
> runs the code, and to the wrapped promise either delivers the result of the 
> code or calls (fail private-promise raised-exception) for you.
>
> On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote:
>>
>> A future fails when it throws an exception. How to do that with a future?
>>
>> It looks like (fail future exception) does not do the trick: 
>> http://dev.clojure.org/display/design/Promises
>>
>>

-- 
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: 0.1.0 core.async release?

[Alex Miller]

I don't where the 0.1.0 number is coming from, but yes there are plans to 
do a round of work on core.async and release in the near future.

On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:
>
> Is there a new release planned for core.async anytime in the near future?
>
> The docs show some functionality that's not in the current release [1].  
> Specifically offer! [2] which looks like it's slated for 0.1.0 (love to 
> switch to that from alts+timeout).
>
> Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)
>
> Regards,
>
> Kyle
>
>
>
> [1] https://github.com/clojure/core.async shows Latest release: 
> 0.1.346.0-17112a-alpha
> [2] http://clojure.github.io/core.async/#clojure.core.async/offer!
>
> -- 
> Twitter: @kyleburton
> Github: https://github.com/kyleburton
> Blog: http://asymmetrical-view.com/
> Fun: http://snapclean.me/
>

-- 
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: (fail promise exception)

[Francis Avila]

Huh, I was sure I had done this before, but I misremembered, I was using my 
own promise that rethrew Throwable instances on deref (and it was in 
clojurescript!)

Clojure promises have no notion of failure, only realized/not-realized. You 
need to deliver a sentinel type or value and check for it on deref, or 
implement your own promise type which does it for you. (It's not that 
hard: 
https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6803
 
)

On Friday, August 7, 2015 at 4:09:39 PM UTC-5, William la Forge wrote:
>
> Sorry, I meant to ask how to fail with a promise? It seems that there is 
> no fail method.
>
> On Friday, August 7, 2015 at 4:52:47 PM UTC-4, Francis Avila wrote:
>>
>> Futures automatically capture exceptions raised in their bodies and 
>> reraise them when the future is derefed. Promises also throw exceptions 
>> when derefed.
>>
>> Unlike promises, futures are created with the code that delivers their 
>> value, so calling fail and deliver explicitly on a future makes no sense.
>>
>> Think of futures as a thin wrapper around a promise which spawns a 
>> thread, runs the code, and to the wrapped promise either delivers the 
>> result of the code or calls (fail private-promise raised-exception) for you.
>>
>> On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote:
>>>
>>> A future fails when it throws an exception. How to do that with a future?
>>>
>>> It looks like (fail future exception) does not do the trick: 
>>> http://dev.clojure.org/display/design/Promises
>>>
>>>

-- 
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: (fail promise exception)

[William la Forge]

Still a newbie here, about to release my first Clojure project. But that 
clojure blob will take some digging on my part. I use a gummed up 
dereference function that checks for Throwable in the meantime. 

My goal right now is to become a Dtomic freelancer. So much to learn! Which 
is why I'm doing projects. Only way I know to become proficient! So yeah, I 
need to get to the point where I can roll my own. Similarly, my first 
project builds on the send method, but I really need to get to the point 
where I can roll my own agent.
 
In any case, thanks Francis. I can only promise more dumb questions in the 
future. ;-)

On Friday, August 7, 2015 at 5:24:24 PM UTC-4, Francis Avila wrote:
>
> Huh, I was sure I had done this before, but I misremembered, I was using 
> my own promise that rethrew Throwable instances on deref (and it was in 
> clojurescript!)
>
> Clojure promises have no notion of failure, only realized/not-realized. 
> You need to deliver a sentinel type or value and check for it on deref, or 
> implement your own promise type which does it for you. (It's not that hard: 
> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6803
>  
> )
>
> On Friday, August 7, 2015 at 4:09:39 PM UTC-5, William la Forge wrote:
>>
>> Sorry, I meant to ask how to fail with a promise? It seems that there is 
>> no fail method.
>>
>> On Friday, August 7, 2015 at 4:52:47 PM UTC-4, Francis Avila wrote:
>>>
>>> Futures automatically capture exceptions raised in their bodies and 
>>> reraise them when the future is derefed. Promises also throw exceptions 
>>> when derefed.
>>>
>>> Unlike promises, futures are created with the code that delivers their 
>>> value, so calling fail and deliver explicitly on a future makes no sense.
>>>
>>> Think of futures as a thin wrapper around a promise which spawns a 
>>> thread, runs the code, and to the wrapped promise either delivers the 
>>> result of the code or calls (fail private-promise raised-exception) for you.
>>>
>>> On Friday, August 7, 2015 at 2:14:30 PM UTC-5, William la Forge wrote:

 A future fails when it throws an exception. How to do that with a 
 future?

 It looks like (fail future exception) does not do the trick: 
 http://dev.clojure.org/display/design/Promises



-- 
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: 0.1.0 core.async release?

[Daniel Compton]

The version in the project.clj file is 0.1.0-SNAPSHOT, that'll probably be
it.
On Sat, 8 Aug 2015 at 9:12 AM Alex Miller  wrote:

> I don't where the 0.1.0 number is coming from, but yes there are plans to
> do a round of work on core.async and release in the near future.
>
>
> On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:
>>
>> Is there a new release planned for core.async anytime in the near future?
>>
>> The docs show some functionality that's not in the current release [1].
>> Specifically offer! [2] which looks like it's slated for 0.1.0 (love to
>> switch to that from alts+timeout).
>>
>> Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)
>>
>> Regards,
>>
>> Kyle
>>
>>
>>
>> [1] https://github.com/clojure/core.async shows Latest release:
>> 0.1.346.0-17112a-alpha
>> [2] http://clojure.github.io/core.async/#clojure.core.async/offer!
>>
>> --
>> Twitter: @kyleburton
>> Github: https://github.com/kyleburton
>> Blog: http://asymmetrical-view.com/
>> Fun: http://snapclean.me/
>>
> --
> 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.
>
-- 
--
Daniel

-- 
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: Size of Java serialized Clojure data structures

[Alan Malloy]

You must be doing something wrong, or describing your method badly, because 
the vector [:a1 1] doesn't take nearly that much space in my experiments. 
The first object you write to a stream requires quite a bit of overhead, 
but after that future objects are relatively cheap. Here's an example you 
can try yourself:

user> (def baos (ByteArrayOutputStream.))
user> (def oos (ObjectOutputStream. baos))
user> (.writeObject oos [:a1 1])
user> (.size baos)
671
user> (.writeObject oos [:a1 1])
user> (.size baos)
719
user> (.writeObject oos [:a1 1])
user> (.size baos)
767
user> (.writeObject oos [:x 2])
user> (.size baos)
845

So the first write takes around 600 bytes of overhead, and each write of 
[:a1 1] takes around 40-50 bytes. Writing a new vector with two different 
objects takes more, because it can't reuse references to constants like 
:a1, but it is still just 80 bytes. Nowhere near 1KB per small vector.

On Friday, August 7, 2015 at 6:31:46 AM UTC-7, icamts wrote:
>
> Yes. I suggested nippy. The question is about the size of Java serialized 
> Clojure data structures. Can a two element vector be 1kB in size? Why 
> serialization in my REPL experiment (see the code following the link in my 
> previous mail) produces a 80MB byte buffer while prevayler logs are 1GB?
>
> Il giorno venerdì 7 agosto 2015 13:51:45 UTC+2, Gary Verhaegen ha scritto:
>>
>> You should probably look at Clojure-specific solutions, starting with EDN 
>> (i.e. essentially pr-str), fressian, transit or nippy.
>>
>> Clojure data structures have a lot of properties that can be exploited 
>> (we only care about the abstract type and the actual data), so a serializer 
>> can make a lot of assumptions that a generic Java solution can't.
>>
>>>
>>>

-- 
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: 0.1.0 core.async release?

[Sean Corfield]

Clojure contrib projects are built via pom.xml so that’s where you should look 
for version information.

The project.clj file is a convenience for the developers/maintainers and has 
nothing to do with the actual project version (although some 
developers/maintainers try to keep their project.clj in sync).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From:   on behalf of Daniel Compton
Reply-To:  
Date:  Friday, August 7, 2015 at 3:50 PM
To:  Clojure
Subject:  Re: 0.1.0 core.async release?

The version in the project.clj file is 0.1.0-SNAPSHOT, that'll probably be it. 
On Sat, 8 Aug 2015 at 9:12 AM Alex Miller  wrote:
I don't where the 0.1.0 number is coming from, but yes there are plans to do a 
round of work on core.async and release in the near future.


On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:
Is there a new release planned for core.async anytime in the near future?

The docs show some functionality that's not in the current release [1].  
Specifically offer! [2] which looks like it's slated for 0.1.0 (love to switch 
to that from alts+timeout).

Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)

Regards,

Kyle



[1] https://github.com/clojure/core.async shows Latest release: 
0.1.346.0-17112a-alpha
[2] http://clojure.github.io/core.async/#clojure.core.async/offer!

-- 
Twitter: @kyleburton
Github: https://github.com/kyleburton
Blog: http://asymmetrical-view.com/
Fun: http://snapclean.me/
-- 
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.
-- 
--
Daniel
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: 0.1.0 core.async release?

[Mikera]

Has anyone found a good way to automatically keep project.clj in sync with 
the official pom.xml? Maybe using the clojure-maven-plugin or similar?

I do this too for a number of libraries, but it's always a manual task and 
prone to error at present

On Saturday, 8 August 2015 07:45:41 UTC+8, Sean Corfield wrote:
>
> Clojure contrib projects are built via pom.xml so that’s where you should 
> look for version information.
>
> The project.clj file is a convenience for the developers/maintainers and 
> has nothing to do with the actual project version (although some 
> developers/maintainers try to keep their project.clj in sync).
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> From: > on behalf of Daniel Compton
> Reply-To: >
> Date: Friday, August 7, 2015 at 3:50 PM
> To: Clojure
> Subject: Re: 0.1.0 core.async release?
>
> The version in the project.clj file is 0.1.0-SNAPSHOT, that'll probably be 
> it. 
> On Sat, 8 Aug 2015 at 9:12 AM Alex Miller  > wrote:
>
>> I don't where the 0.1.0 number is coming from, but yes there are plans to 
>> do a round of work on core.async and release in the near future.
>>
>>
>> On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:
>>>
>>> Is there a new release planned for core.async anytime in the near future?
>>>
>>> The docs show some functionality that's not in the current release [1].  
>>> Specifically offer! [2] which looks like it's slated for 0.1.0 (love to 
>>> switch to that from alts+timeout).
>>>
>>> Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)
>>>
>>> Regards,
>>>
>>> Kyle
>>>
>>>
>>>
>>> [1] https://github.com/clojure/core.async shows Latest release: 
>>> 0.1.346.0-17112a-alpha
>>> [2] http://clojure.github.io/core.async/#clojure.core.async/offer!
>>>
>>> -- 
>>> Twitter: @kyleburton
>>> Github: https://github.com/kyleburton
>>> Blog: http://asymmetrical-view.com/
>>> Fun: http://snapclean.me/
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> --
> Daniel
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/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.