Strange Loop call for presentations

[Alex Miller]

Hello Clojurians.hope some of you can submit to this conference:


CALL FOR SPEAKERS
Strange Loop Conference
St. Louis, Oct. 14-15, 2010
http://strangeloop2010.com

The Strange Loop conference is now holding an open call for
presentations
and workshops.  Strange Loop is a developer-run software conference
focusing on "what's next" in the world of software development.

Strange Loop focuses on the following technical areas (examples
shown):
* Alternative languages - Groovy, Ruby, Python, Clojure, Scala, F#,
Erlang
* Big data / NoSQL - Cassandra, Hadoop, HBase, CouchDB, MongoDB, Riak,
Neo4J
* Concurrency and distributed systems - actors, STM, ZooKeeper, Chef,
Akka
* Web - Javascript, jQuery, HTML 5, security, semantic web, RDFa
* Mobile - iPhone, Android, WebOS
* Open source - popular or interesting open source libraries

You can find the full call for presentations here:
http://strangeloop2010.com/pages/38735

For a list of already confirmed speakers see the following list:
http://strangeloop2010.com/speakers

To register, go here:
https://regonline.com/strangeloop2010

The call for presentations closes on July 9th, 2010.

Thanks,
Alex Miller

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

Re: core.async pub/sub

[Alex Miller]

There is a broadcast fn in the lab namespace 
(https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/lab.clj)
 
that does this and I believe David Nolen has created a different variant in 
some of his stuff. The lab one is experimental and would welcome feedback 
on it.

Alex

On Tuesday, July 9, 2013 6:46:21 PM UTC-5, Thomas Heller wrote:
>
> Hey,
>
> I'm doing some core.async tests and want to create a basic pub/sub model. 
> Messages are >! on one channel and >! to many others.
>
> (deftest ^:wip async-test2
>  
>   (let [subscribers (atom [])
> events (chan 100)]
>  
> (go (loop []
>   (when-let [ev ( (doseq [c @subscribers]
>   (alt!
>[[c ev]] :sent
>:default nil ;; could "force" unsubscribe c?
>))
> (recur
>  
> (let [s1 (chan 1)
>   s2 (chan 100)
> r1 (atom [])
>   r2 (atom [])]
> (swap! subscribers conj s1 s2)
> ;; simulated slow reader
>   (go (loop []
> (when-let [ev (   (swap! r1 conj ev)
>   (   (recur 
> ;; good reader
>   (go (loop []
> (when-let [ev (   (swap! r2 conj ev)
>   (recur
> (  (when (< i 100)
>(>! events i)
>(recur (inc i))
>  
>   (close! events)
> (Thread/sleep 25)
> (pprint @r1)
>   (pprint @r2))
> ))
>
>
> In this example the s1 subscriber will loose almost all messages since he 
> cannot keep up (and buffer is too small). I choose to alt!/:default to drop 
> messages, since I don't want any subscriber to block others. How do you 
> guys deal with slow-readers?
>
> I don't really have a specific problem but I wonder if there are any plans 
> for some built-in pub/sub mechanisms for core.async. Seems like a very 
> common pattern.
>
> Anyways, core.async is nice!
>
> Cheers,
> /thomas
>
>
>

-- 
-- 
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/groups/opt_out.

Re: core.async: communicating termination

[Alex Miller]

I haven't been in any discussions about this with the team, so it's 
entirely possible I am ignorant of some established future direction... but

- "closed?" seems useful to me. (It may also be useful to ask "drained?" 
(closed + empty).)
- >! returning an indicator of success also seems useful. However, since it 
executes asynchronously, I suspect adding that functionality may not be 
feasible (or may be feasible but incur a synchronization or complexity cost 
that is unacceptable). 

If you'd like to file a ticket at http://dev.clojure.org/jira/browse/ASYNC 
that would help to track the request. 

With respect to other strategies for dealing with this:

1) You could simply ignore the producer. If no one is requesting new 
values, the producer will not be run and no thread time should be consumed 
(there is of course heap being used). Not really recommending this but it's 
an option!

2) You could create a control channel for the producer (and other 
interested processes) that could transmit a stop message. Then alts! on the 
control channel in combination with the >! so that you're waiting on either 
the need to stop or the ability to put a new value in the channel.

Alex


On Thursday, July 11, 2013 7:16:56 AM UTC-5, vemv wrote:
>
> Consider a happy, oblivious producer of values:
>
> (def c (chan 42))
>
> (go (while true (>! c (rand
>
> It doesn't know where/now the channel is consumed (which part of the point 
> of channels/queues). However, we *do* know that at some point, nobody 
> will need the result of our producing, so we should stop our activity.
>
> It seems to me that a natural way to tell the producer to stop is to close 
> the channel. However:
>
> * there's nothing like a clojure.core.async/chan-closed? fn, AFAICT
> * The >! fn unconditionally returns nil, whether the channel is open or 
> not. Only the blocking nature of the call can potentially vary - which is 
> not particularly useful for the purpose.
>
> What would be an adequate way to indicate termination? Just telling the 
> producer to stop (e.g. (reset! keep-producing false)) would break the 
> indirection one gains by using channels.
>
> What if >! returned true/false depending on whether the value was put 
> (because the channel was open)?
>

-- 
-- 
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/groups/opt_out.

Re: T-shirts?

[Alex Miller]

It may take me a couple weeks but I will see what I can do from the 
"sanctioned" camp.

Alex


On Sunday, July 28, 2013 5:22:21 PM UTC-5, Isaac Wagner wrote:
>
> There was a discussion a while ago about stickers which led to 
> http://clojure.org/swag. Could we get some sanctioned T-shirts as well? 
> There are a few Clojure shirts on Zazzle, but what I would be interested in 
> is some black, grey, and white shirts with nothing but a big Clojure logo 
> on the front and I would love to buy them in a way that supports Clojure.
>
> Isaac
>

-- 
-- 
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/groups/opt_out.

Re: Clojure cheatsheets with several flavors of tooltips

[Alex Miller]

I updated the cheatsheet on clojure.org to the latest version (no 
tooltips). I don't have enough access to add the additional assets that 
would make that possible.

Alex

On Thursday, August 8, 2013 2:13:24 PM UTC-4, Andy Fingerhut wrote:
>
> It is relatively easy (with help from the right person with permission to 
> update clojure.org/cheatsheet) to update the non-tooltip version of the 
> cheatsheet there.
>
> When last they checked for me some months ago, it was less easy to enable 
> the tooltip version of the cheatsheet at clojure.org/cheatsheet.
>
> On the plus side, the link to the other versions of the cheatsheet is now 
> at the top of the page rather than the bottom, so it should be easier for 
> people to find.
>
> Andy
>
>
> On Thu, Aug 8, 2013 at 1:46 AM, Jakub Holy 
> > wrote:
>
>> Hi Andy, 
>>
>> This cheatsheet of yours is wonderful! 
>>
>> Are there any chances of getting it to clojure.org/cheatsheet? It is a 
>> shame that the cheatsheet at clojure.org is only for Clj 1.4 and doesn't 
>> have the beautiful tooltips.
>>
>> Thank you, Jakub
>>
>>
>> On Monday, April 23, 2012 8:35:12 PM UTC+2, Andy Fingerhut wrote:
>>>
>>> The tooltip version of the Clojure/Java cheatsheet is not published at 
>>> [1] just yet, but hopefully we can figure out how to make that happen in a 
>>> while:
>>>
>>> [1] http://clojure.org/cheatsheet
>>>
>>> There is an updated link at the bottom of that page called "Download 
>>> other versions" that leads to [2]:
>>>
>>> [2] http://jafingerhut.github.com
>>>
>>> Page [2] has links to 5 different variations of the cheatsheet, and I 
>>> plan for it to be the long term home for where I publish cheatsheets (in 
>>> addition to [1]).  They differ only in whether they have tooltips, how the 
>>> tooltip is implemented, and whether the tooltip includes a 1-line summary 
>>> of what ClojureDocs.org contained at a recent snapshot time.  It does not 
>>> query ClojureDocs.org every time it displays a tooltip.  That would slow 
>>> down the tooltip display, and likely be too much load on ClojureDocs.org.
>>>
>>> There are also links on that page to the Github repository containing 
>>> the source that generated the cheatsheets, and to the PDF versions.
>>>
>>> Note: It is free and quick to create an account on ClojureDocs.org, and 
>>> you don't even need to create an account if you have an OpenID account on 
>>> Google, Yahoo, or myOpenId.  Just click "log in" in the upper right corner 
>>> of [3], and you can edit examples and see alsos, too.  Don't be dismayed 
>>> thinking that you must write special markup to create examples.  In most 
>>> cases, all it takes is copying and pasting a REPL session, with some 
>>> editing to add comments if it helps understanding what is going on.  The 
>>> color highlighting is automatically added by the web server.
>>>
>>> [3] http://clojuredocs.org
>>>
>>> Andy
>>>
>>>  -- 
>> -- 
>> 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/groups/opt_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/groups/opt_out.

Clojure community office hours - Friday Aug 16

[Alex Miller]

Hello all,

Recently I've been doing various Clojure community related things. In the
interest of opening another avenue for interaction, I've scheduled some
office hours for questions or conversations about Clojure or its
surrounding processes.

In scope:
- Newbie questions about Clojure
- Clojure Confluence (http://dev.clojure.org)
- Clojure JIRA tickets and patches (http://dev.clojure.org/jira)
- Clojure web site (http://clojure.org)
- Clojure conference (Clojure/conj, Clojure/West, or others)
- Clojure user groups
- Things that bug you about Clojure, or Relevance, or any of the things
above

You can of course also email me as well or ask here or (as appropriate) on
clojure-dev.

There are several 20 minute slots available - see: http://ohr.me/1d4m9Uj to
schedule. Will adjust in future based on how things go.

Alex Miller
Relevance, Inc.

-- 
-- 
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/groups/opt_out.

Clojure ticket update

[Alex Miller]

Hello all,

Wanted to update on a few things:

1) A bunch of tickets went through final review this week and were
committed to Clojure master (aka 1.6.0-master-SNAPSHOT). If you want to try
these out on your code base, that would be great. (help with
snapshots
)

CLJ-1205  - Update Maven build
for Nexus 2.4
CLJ-850  - Hinting the arg
vector of a primitive-taking fn with a non-primitive type results in
AbstractMethodError when invoked
CLJ-1202  - protocol fns with
dashes may get compiled into property access when used higher order
CLJ-1171  - Compiler macro for
clojure.core/instance? disregards lexical shadows on class names
CLJ-1175  - NPE in
clojure.lang.Delay/deref
CLJ-1161  - sources jar has
bad versions.properties resource
CLJ-1121  - -> and ->> have
unexpected behavior when combined with unusual macros
CLJ-196  - *file* returns
"NO_SOURCE_PATH", but the doc says it should be nil
CLJ-1160  - reducers/mapcat
ignores Reduced
CLJ-1154  - Compile.java
closes out preventing java from reporting exceptions
CLJ-1193  - bigint, biginteger
throw on double values outside of long range

2) Tickets that have been vetted for the next release and await patches can
be found on the CLJ Needs
Patchfilter.
If you want to help in making Clojure better, these tickets are the
farthest in the pipeline.

CLJ-1058  - StackOverflowError
on exception in reducef for PersistentHashMap fold
CLJ-701  - Compiler loses
'loop's return type in some cases
CLJ-1190  - Javadoc for public
Java API

Thanks,
Alex

Check out these links to learn more about the Clojure ticket process:
- JIRA Workflow  -
process, activities, etc
- Creating Tickets

- Developing 
Patches
- Contributing  -
lotsa links

-- 
-- 
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/groups/opt_out.

ANN: CFP for Strata 2014

[Alex Miller]

I have no involvement with this conference but thought some people in the
Clojure world might be interested in submitting talks about big data,
analytics, data science, machine learning, etc.

http://strataconf.com/strata2014/public/cfp/283

CFP closes: Sept 16th, 2013
Notification: Oct, 2013
Conference: Feb 11-13, 2014 - Santa Clara, CA

-- 
-- 
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/groups/opt_out.

CFP: CodeMash - Jan 7-10, 2014 - Sandusky, OH

[Alex Miller]

(no affiliation, just passing this along)

CodeMash is a large multi-technology conference in a giant water park with
a great secondary track for kids. It is my opinion that they need some more
Clojure submissions. :)

CFP closes Friday, Sept 6th. http://codemash.org/submissions

-- 
-- 
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/groups/opt_out.

Re: Eval vs the repl

[Alex Miller]

I think you may be tripping over this 
bug: http://dev.clojure.org/jira/browse/CLJ-1184

which is waiting for Rich's approval to go into 1.6.

Alex

On Wednesday, August 28, 2013 11:13:54 AM UTC-5, Jamie Brandon wrote:
>
> I had previously assumed that the clojure repl effectively just did 
> (eval (read-string input)). That doesn't seem to be the case eg: 
>
> user> [do (inc 1)] 
> CompilerException java.lang.RuntimeException: Unable to resolve 
> symbol: do in this context, compiling:(NO_SOURCE_PATH:1:1) 
> user> (eval '[do (inc 1)]) 
> 2 
> nil 
> user> (load-string "[do (inc 1)]") 
> 2 
> nil 
>
> user> ^{:line 11, :column 20} [] 
> [] 
> nil 
> user> (eval ^{:line 11, :column 20} []) 
> ClassCastException java.lang.Long cannot be cast to java.lang.Integer 
> clojure.lang.Compiler.eval (Compiler.java:6597) 
> user> (load-string "^{:line 11, :column 20} []") 
> ClassCastException java.lang.Long cannot be cast to java.lang.Integer 
> clojure.lang.Compiler.eval (Compiler.java:6597) 
>
> What can I do to eval a string in the same way that the repl does? 
>

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

Re: Java Metadata Wrapper

[Alex Miller]

In some cases you could proxy and add IMeta that way.


On Friday, August 30, 2013 2:16:26 PM UTC-5, JvJ wrote:
>
> I've noticed that, when doing a lot of Java interop, it's impossible to 
> attach metadata to most Java objects, since they don't implement the IMeta 
> interface.  A workaround for this would be to do something like put every 
> Java object in a single-element list and attach metadata to the list, but 
> this is annoying.  Would it be possible (or even useful) to create some 
> kind of generic IMeta structure that can wrap other Java objects and have 
> them act like normal, except for the added metadata (or even other 
> Clojure-esque features)?
>

-- 
-- 
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/groups/opt_out.

Clojure JIRA votes

[Alex Miller]

A comment from Andy F on another thread prompted me to write this. There
has been a lot going on in jira land lately and I promise that I will soon
write lots more about it.

In the process  of
getting things moving a bit I've been trying to ferret out what tickets are
most important and/or desired. The best tool I have for this is votes and
watches in JIRA .

In particular, I look at both absolute counts and the weighted vote
reportthat
Andy has automated. The weighted vote decreases weight based on the
number of votes a user makes (so more votes means each vote counts less).

There are many tickets that look at corner cases or extensions to
"complete" the core library functions (adding 0 arity support to a function
for example). I would love to fix all of those but I put a higher priority
on fixing problems that are actually affecting people's work first. Please
vote on things that are affecting you and "spend" your votes wisely!

If you'd like to vote or browse, sign up
here.
To actually contribute patches you must be a
contributor.
Lots more links here 
.

I have created some semi-standard labels (doc'ed at the end of Creating
Tickets ) and
updated many of the existing tickets. You can search for those labels or
just by keyword to find open things. For example, here is a search for open
CLJ tickets about
errormsgs
(one
of the labels).

If you have questions about any of this, I'm happy to answer them.

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/groups/opt_out.

Re: Possible bug in LockingTransaction

[Alex Miller]

I have not gone to look at the code but the description certainly sounds 
like a recipe for a bug. 

If you can a) create a reproducible case and b) check that it happens on 
1.5 as well we would greatly appreciate a ticket:

Create a jira account 
- http://dev.clojure.org/jira/secure/Signup!default.jspa
Then create a jira ticket 
- http://dev.clojure.org/display/community/Creating+Tickets

Thanks,
Alex


On Wednesday, September 11, 2013 1:47:56 AM UTC-5, Brandon Ibach wrote:
>
> I have found what appears to be a bug in LockingTransaction, albeit one 
> that probably wouldn't occur often.  But, I suppose that's a given for a 
> previously undiscovered problem in oft-used code that hasn't changed for 
> some while. :)
>
> I'm using the Clojure 1.4 library strictly from Java code and I have a 
> fairly simple transaction which dispatches an action to an agent (send, not 
> send-off).  When called from a JUnit test, such that we jump right in to 
> things, skipping some of the initialization we normally do in our app, I 
> get a ConcurrentModificationException from inside Locktransaction.run() 
> while it is iterating through the "actions" list, dispatching the actions 
> after committing the transaction.
>
> Based on some debugging, here's what seems to be happening:
>
> 1. My transaction is run, dispatching an action to an agent.
> 2. The transaction completes and is successfully committed.
> 3. LockingTransaction does post-commit cleanup, freeing locks and putting 
> a stop() to the transaction, which nulls the transaction's Info object 
> reference.
> 4. Notifications are sent and we start iterating the list of actions to be 
> dispatched.
> 5. The run() method calls Agent.dispatchAction().  Because the thread's 
> transaction is no longer "running" (due to the Info object being null) and 
> no action is being processed on the thread (so its "nested" vector is 
> null), the action is enqueue()d with the agent.
> 6. As part of the enqueue process, the action is consed onto the agent's 
> ActionQueue.  Here's where the unique circumstances come into play.
>a. At this point, we haven't really interacted with the Clojure 
> runtime, specifically the RT class, so its initiation machinery kicks in.
>b. Down in the depths, it executes a transaction to add a library to 
> its list of loaded libraries.
>c. The still-existing-but-not-running thread-local transaction, with 
> its existing action list intact, fires up, runs and commits.
>d. The post-commit stuff runs, including a nested attempt to dispatch 
> that same action, again, which apparently succeeds.
>e. The action list is cleared before exiting the run() method.
> 7. Upon returning way back up the stack to our 
> not-quite-finished-post-processing transaction, we continue iterating the 
> now-cleared action list, which promptly throws the 
> ConcurrentModificationException.
>
> A quick perusal of the LockingTransaction code shows that the only 
> interaction with the action list is adding an item to it in the enqueue() 
> method, iterating it in the post-processing section of run() and clearing 
> it in the "finally" clause of that section, so it's easy to see how a 
> transaction started by any of the action-dispatching machinery would cause 
> problems.  Any such activity in the actions themselves would not be an 
> issue, since they'd occur on other threads, but the dispatch stuff all runs 
> on the same thread.  The few moving parts that occur in this code seem 
> fairly safe, as long as the runtime is already initialized, but if that 
> occurs during this phase, I think all bets are off.
>
> Does this analysis seem sound?  If so, is there a more formal process for 
> filing this as a bug?  I can probably create a nice, compact example to 
> reproduce it.
>
> Thanks!
>
> -Brandon :)
>

-- 
-- 
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/groups/opt_out.

Re: new ClojureDocs experiment

[Alex Miller]

Hey all,

Lee Hinman (dakrone) is the current primary maintainer. There was a good 
discussion about clojuredocs last year at the conj unsessions and I think 
the primary driving note that came out of that was that it would be useful 
to have the concept of version in the database (that is, examples are tied 
to versions). That was going to drive some changes in the data model. 

I talked to him recently about the state of clojuredocs. I know he's been 
pretty busy lately with a new job. I believe he thinks the service API and 
doc extractor are in pretty good shape. The major areas that need work are 
figuring out how to store the data in a database (I think he's just 
indexing right now with Elasticsearch) and actually creating the front end 
(preferably in Clojure of course) that used the existing API. If it was 
desirable to use Datomic, I suspect we could probably work that out. :) 

If someone was interested in working on these areas, help would be greatly 
appreciated! This is an awesome opportunity to work on a greenfield Clojure 
web app that would be used by the community. It would be helpful if we had 
one or more point people who had the time and enough experience to organize 
and lead such an effort. I'm sure Lee would be amenable to that based on 
our conversation.

Alex


On Wednesday, September 11, 2013 3:42:40 AM UTC-5, xavriley wrote:
>
> I've just picked up on this thread but I've spent quite a bit of time 
> barking up this tree.
>
> There are three repos that power the old version of the site
>
> https://github.com/zk/clojuredocs - the Rails 2 frontend
> https://github.com/zk/clojuredocs-analyzer - the clojure analyzer that 
> extracts data from Clojure Core and other projects
> https://github.com/zk/cd-wsapi - the API that handles CLI integration
>
> I've got a pull request sitting there for the analyzer which makes it work 
> with Clojure 1.5.1
>
> https://github.com/zk/clojuredocs-analyzer/pulls
>
> But I've not had any response from the maintainers yet. I've tried 
> catching them on IRC but I haven't heard anything since I submitted the PR.
>
> I could just host a fork of Clojuredocs myself with 1.5.1 but I think 
> that's the wrong way to do this. I have had some success in forking the 
> project for Overtone documentation and Core.logic docs which you can see 
> here:
>
> http://overtone-docs.herokuapp.com/
> http://corelogicdocs.herokuapp.com/
>
> So it's entirely possible to work with what's there. I'll try getting in 
> touch with dakrone to see if we can make this update happen.
>
>
>
> On Wednesday, September 11, 2013 8:57:21 AM UTC+1, Colin Fleming wrote:
>>
>> Something that I've always wondered - why is ClojureDocs not updated? 
>> I've never tried to contribute to it - is it particularly difficult? Is it 
>> impossible for users to add support for new Clojure versions? If so, who 
>> runs it? Could it be turned over to the community?
>>
>>
>> On 11 September 2013 17:55, Steven Degutis  wrote:
>>
>>> All very good points.
>>>
>>> One of my assumptions was that people don't use wikis simply because
>>> it's Yet Another Account to sign up for, so this being hosted on
>>> github would be a much lower barrier-to-entry for contributing
>>> examples. But I'm not sure that's a valid assumption for anyone
>>> besides just me.
>>>
>>> And I wasn't suggesting that the structure be edited. I was imagining
>>> an unwritten rule where only examples would be edited/added, and the
>>> rest of the structure of each page remain the same. That would make
>>> parsing the wiki partially manageable. But I'm not sure how realistic
>>> that is in practice.
>>>
>>> Thanks for your feedback.
>>>
>>> -Steven
>>>
>>> On Wed, Sep 11, 2013 at 12:39 AM, John Gabriele  
>>> wrote:
>>> > On Sunday, September 8, 2013 4:07:33 AM UTC-4, Steven Degutis wrote:
>>> >>
>>> >>
>>> >> https://github.com/sdegutis/clojuredocs/wiki
>>> >>
>>> >> {snip}
>>> >>
>>> >> Thoughts?
>>> >>
>>> > Hi Steven,
>>> >
>>> > This is a nice piece of work. Thank you.
>>> >
>>> > Some thoughts:
>>> >
>>> >   * Wikis are difficult to keep nice. And, seemingly contradictory to 
>>> that,
>>> > it's difficult to find contributors.
>>> >
>>> >   * There is already a Clojure wiki,
>>> > , but it does not 
>>> see many
>>> > updates.
>>> >
>>> >   * I really like clojuredocs.org's clean (and enforced) separation of
>>> > examples, see-also, and comments.
>>> >
>>> >   * Although github's wiki feature is handy, for a pure wiki there are
>>> > better solutions, IMO (for example, my favorite is
>>> > [gitit](http://www.gitit.net/)).
>>> >
>>> >   * I think some of the work necessary to replace/rewrite 
>>> clojuredocs.org
>>> > has already been done by dakrone. Dunno the status of it though.
>>> >
>>> >   * I think it's worthwhile to pull docstrings directly from Clojure 
>>> itself.
>>> > Fixing docstring typos in a wiki is nice, but I'd rather see fixed the
>>> > actual source docstrings 

Re: finding retained head

[Alex Miller]

I have nothing to add for the problem itself (sorry) but am very interested 
in the *process* of answering this question. Presuming there are things to 
document here, I would love to see someone create a wiki page (on 
http://dev.clojure.org/display/community/Home)  or a clojure-doc note or 
some place to capture tips and techniques for debugging problems like this.

Alex


On Wednesday, September 11, 2013 10:59:50 AM UTC-5, Brian Craft wrote:
>
> This appears to have no effect on the problem. I tested with 
> jdbc/transaction, and with Sean's simple example:
>
> user=> (defn f [g] (g))
> #'user/f
> user=> (defn t1 [n c] (f (fn [] (dorun (map identity c)
> #'user/t1
> user=> (t1 0 (range 100))
> java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0)
> user=> (defn t2 [n c] (f (fn [] (doseq [x c] (identity x)
> #'user/t2
> user=> (defn t1 [n c] (f (^:once fn* [] (dorun (map identity c)
> #'user/t1
> user=> (t1 0 (range 100))
> java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0)
>
>
>
> On Wednesday, September 11, 2013 7:39:48 AM UTC-7, Christophe Grand wrote:
>>
>> ^:once on fn* (not fn, the fn macro doesn't propagate metadata) instructs 
>> the commielr to clear closed-overs ASAP. It follows that you can't call 
>> such a function twice because it forgets its closed-overs.
>>
>>
>> On Wed, Sep 11, 2013 at 4:36 PM, Brian Craft  wrote:
>>
>>> ugh. Can't find documentation for this. What does it do?
>>>
>>> On Wednesday, September 11, 2013 2:22:56 AM UTC-7, Christophe Grand 
>>> wrote:
>>>

 On Wed, Sep 11, 2013 at 6:00 AM, Brian Craft wrote:

> (defmacro transaction
>   [& body]
>   `(transaction* (fn [] ~@body)))
>
> I'm not sure how to avoid that. The anonymous function created here 
> doesn't take parameters.
>

 The fix for this is:
 (defmacro transaction
   [& body]
   `(transaction* (^:once fn* [] ~@body)))

 It should be the default for all one-shot fns.

 Christophe

 -- 
 On Clojure http://clj-me.cgrand.net/
 Clojure Programming http://clojurebook.com
 Training, Consulting & Contracting http://lambdanext.eu/ 
  
>>>
>>
>>
>> -- 
>> On Clojure http://clj-me.cgrand.net/
>> Clojure Programming http://clojurebook.com
>> Training, Consulting & Contracting http://lambdanext.eu/ 
>>  
>

-- 
-- 
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/groups/opt_out.

Re: The Eclipse Public License is not a good license

[Alex Miller]

There are no plans to change the license. 


On Wednesday, September 11, 2013 8:41:04 AM UTC-5, Kalinni Gorzkis wrote:
>
> I think that Clojure should switch to a better license with similar spirit 
> like Apache 2.0, BSD, or MIT.
> While the EPL doesn't have the evil "copyleft" requirement of GPL, and 
> therefore allows and encourages commercial uses of the code, it has a 
> requirement that makes it incompatible with the GPL: If you create modified 
> versions of EPL-covered software, you must slap your name (or any other 
> identity) on it. In my humble opinion, this restriction isn't justified. 
> (All, or most, creators of modified versions will do that anyway). It may 
> have been chosen uncarefully. Other permissive licenses better fulfill Rich 
> Hickey's spirit.

-- 
-- 
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/groups/opt_out.

[ANN] Clojure/West 2015 Call for Presentations

[Alex Miller]

Hello Clojure fans!

We will be returning to Portland (same theater as 2013) for Clojure/West
this year on April 20-22nd and workshops on the weekend prior. We currently
plan to have tickets on sale Monday - see http://twitter.com/clojurewest
and http://clojurewest.org for more info and last minute details.

However, the Call for Presentations is open now! We are accepting
submissions until Feb. 11th in the general areas of core language,
libraries, tools, experience reports, ideas, and fun (although it's all
pretty fun when it's Clojure right?).

https://cognitect.wufoo.com/forms/clojurewest-2015-call-for-presentations/

Speakers receive free admission, $550 stipend, and up to 4 room nights at
the conference hotel (Embassy Suites Downtown Portland). Sessions are 40
minutes long. Multiple submissions are allowed, although we'd prefer no
more than three. Beginner or foundational level talks are welcome!

If you are mulling over multiple ideas, need feedback, or just aren't sure
whether something is a good idea, please feel free to send an email to
eve...@cognitect.com and we will get back to you as soon as possible.

If your company is interested in sponsoring Clojure/West, please check out
the prospectus at http://clojurewest.org/sponsorship and let us know. We've
had an amazing initial response - thanks if you've already contacted us.

Also, we will be running an opportunity grant program again for
Clojure/West with travel grants and tickets for qualified applicants. More
to come in the next few weeks on that.

Hope to see everyone there!
Alex Miller and Lynn Grogan

-- 
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] Clojure/West 2015 Call for Presentations

[Alex Miller]

Just to be clear, "Clojure" should be read in a big tent way here to include 
ClojureScript and anything Clojure-related of course. ClojureScript talks 
desired!!

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] Clojure 1.7.0-alpha5 now available

[Alex Miller]

Just to follow up on this, Tom reported to me on Twitter that the box 
giving slow results was bad and the regression was not repeatable on 
another box.

Alex

On Monday, January 12, 2015 at 12:37:05 PM UTC-6, tcrayford wrote:
>
> I said this already on twitter, but I see heavy (5-10x slower) perf 
> regressions on my benchmark suite from 1.7-alpha5 vs 1.6. I am trying the 
> other alphas now - I have a comprehensive benchmark suite that takes 4 
> hours or so to run, and it's a bit backed up right now (I only have one box 
> to run it on). I'm also going to point YourKit at 1.7-alpha5 soon on the 
> worst regressing benchmarks (not all of them have such heavy regressions, 
> and a few benchmarks are dramatically faster) and see what happens - will 
> report back here once I have something more to say.
>
>

-- 
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] Clojure 1.7.0-alpha5 now available

[Alex Miller]

I am actively working on an updated set of patches, hopefully for inclusion in 
the next alpha.

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.

[ANN] Clojure/West 2015 Registration Open

[Alex Miller]

## Registration ##

Tickets are on sale now for Clojure/West 2015 - Apr 20-22 in Portland,
Oregon!
- Register: http://clojurewest2015.eventbrite.com
- Early bird - $275 (and going fast)
- Regular - $350

## Workshops ##

We will also have workshops on the weekend prior to Clojure/West (Apr
18-19th).
- Info: http://www.clojurewest.org/training
- Clojure Intro Lab - Alex Miller & Katherine Fellows (Apr 18-19th, $300)
- ClojureScript - David Nolen (Apr 18th, $400)
- Macros - Colin Jones (Apr 19th 9-11 am, $150)
- Om - David Nolen (Apr 19th 12:30-2:30 pm, $150)
- core.async - Luke VanderHart (Apr 19th 3-5 pm, $150)

## CFP ##

The Clojure/West CFP is still open till Feb 11th. We will be accepting
talks in several categories: Language, Library, Tools, Experience Report,
Ideas and Fun. Talks will be 40 minutes in length (including Q&A). We're
always open to reviewing proposals before the deadline (email
eve...@cognitect.com).

All speakers receive a conference ticket, up to 4 nights lodging at the
conference hotel and airfare stipend (U.S. Airfare or up to $550
international).

## Sponsorship ##

Thank you to our first group of sponsors! SparX, Factual, Mayvenn, Quintype
and Simple! You can find this year's prospectus on the Clojure/West website
if you're interested.  Email us at eve...@cognitect.com for more
information.

## Opportunity Grants ##

We will have Opportunity Grants available for community members who would
not be able to attend the conference for financial reasons. More info
coming soon.

Let us know if you have any questions...

- Alex Miller and Lynn Grogan at eve...@cognitect.com

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

Re: Switched map for record and got slower

[Alex Miller]

On Wednesday, January 28, 2015 at 2:07:07 PM UTC-6, Fluid Dynamics wrote:
>
> On Wednesday, January 28, 2015 at 1:59:49 PM UTC-5, Marshall 
> Bockrath-Vandegrift wrote:
>>
>> At the very least, all the places where you switched to method/property 
>> syntax now require runtime reflection. Try leaving those as they were, or 
>> switching to using the keyword as the function (which is somewhat more 
>> idiomatic).  You could instead hint the appropriate object type in each 
>> function, but part of the benefit of records is that most code should be 
>> agnostic as to whether it has a plain map or a record.
>>
>
> Another thing that changed is that units went from returning a vector to 
> returning a lazy seq, which makes random access go from constant to linear 
> time. That could be affecting things too. 
>

You could avoid this part of the change by using mapv instead of map. 

-- 
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/West 2015 - CFP and Opportunity Grants

[Alex Miller]

Hello all,

The Clojure/West CFP ends this Wednesday and we are still looking for more
proposals!
* Feb 11th - CFP closes
* Feb 27th - notifications to speakers
* Sessions will be published soon after this
* Speakers receive free admission, air (limited for international), and
hotel for the conference
* Submit:
https://cognitect.wufoo.com/forms/clojurewest-2015-call-for-presentations/
* Questions and early feedback: eve...@cognitect.com

Clojure/West opportunity grant applications are now being accepted as well.
Similar to what we did at Clojure/conj, opportunity grants provide travel,
hotel, and ticket assistance for members of underrepresented groups in the
Clojure community.
* Feb 27th - application close
* Mar 13th - notification happens on a rolling basis, but completes by this
date
* Submit: http://clojurewest.org/opportunity

Additionally, we are open for:
* Sponsorship - http://clojurewest.org/sponsorship
* Registration - https://clojurewest2015.eventbrite.com (both conf and
training)

Hope to see you there!
- Alex Miller and Lynn Grogan

-- 
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: Extending the LispReader with "embeded language lorms"

[Alex Miller]

Hi Henrik,

There is a long-standing philosophical position in Clojure that it should 
not be possible to write programs that cannot be read by other users. 
Because of this position, I do not believe there is any chance of this 
moving forward in Clojure itself.

Tagged literals allow creating new data that can still be read and 
interpreted even if a reader is not available so they give a certain 
measure of this capability without crossing that line.

Alex



On Tuesday, February 10, 2015 at 6:03:56 AM UTC-6, henrik42 wrote:
>
> @Luc: I see your points. Thanks for the reply.
>
> Just to make it clear: all I suggest is to integrate 
>
> https://github.com/henrik42/extended-lisp-reader/blob/master/src/extended_lisp_reader/core.clj
> into clojure.core - i.e. make #[...]-forms and the delegation to user code 
> "official".
> The rest of my lib is just examples of how this feature *could* be used.
>
> So we're talking about ~15 lines of code.
>
> But again - this might open up a way that we do not want to go in the end.
>
> Time will tell.
>
>
>

-- 
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: How to create jar for data.int-map

[Alex Miller]

The first line of the readme for the project 
(https://github.com/clojure/data.int-map) has the Leiningen jar dependency 
info on it:

[org.clojure/data.int-map "0.1.0"]

Also, the 'mvn package' command should have worked since that's how 
releases get built. That was a bug in the pom dependencies and I have 
updated it to match the version in project.clj.




On Thursday, February 19, 2015 at 5:39:22 AM UTC-6, Cecil Westerhof wrote:
>
> 2015-02-19 11:58 GMT+01:00 Michael Griffiths  >:
>
>> Clojure and Clojure contrib libraries are uploaded to Sonatype when 
>> released. e.g. 
>> https://oss.sonatype.org/content/groups/public/org/clojure/data.int-map/
>>  
>> There should be both a jar with sources and jar without sources for each 
>> released version of each lib.
>>
>  
> ​Thanks. I think information like this should be easier to find. I like 
> Clojure, but sometimes it is difficult to find things.
>
>>
> -- 
> Cecil Westerhof
>  

-- 
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/West 2015 Speakers

[Alex Miller]

Clojure/West will take place Apr 20-22 in Portland, OR.
Register here: http://clojurewest2015.eventbrite.com

We have now posted the majority of the Clojure/West speakers:
http://clojurewest.org/speakers

In particular, I want to highlight our keynote speaker, Melanie Mitchell,
who worked for a while with Douglas Hofstadter and has written a number of
excellent books. She will talking about her recent research integrating
deep networks and analogy-making.

Other talks:
- Boot Can Build It - Alan Dipert, Micha Niskin
- Clojure at Scale - Anthony Marcar
- Clojure, Sound, and Wearable Technology - Boris Kourtoukov
- Building CircleCI's Frontend With Om - Brandon Bloom
- Developing ClojureScript with Figwheel - Bruce Hauman
- Strange Coop: How Clojure saved my chickens from the evil racoons -
Christopher Small
- Debugging Clojure code with Cursive - Colin Fleming
- Generating Art in Many Worlds - Dan Lidral-Porter
- Exploring Programming Clojure in Other Human Languages - Elango Cheran
- Adapting Clojure to an introductory CS classroom.  - Elena Machkasova
- HoneySQL: SQL Queries as Clojure Data Structures - Fumiko Hanreich
- Purely Random - Gary Fredericks
- Composing interactive applications with Zelkova - James MacAulay
- Design and Prototype a Language in Clojure - Jeanine Adkisson
- Life of a Clojure Expression: a quick tour of Clojure internals - John
Hume
- Clojure Parallelism: Beyond Futures - Leon Barrett
- The ReactJS Landscape - Luke VanderHart
- Well I wouldn't want to make a *dys*functional game - Morgan Mullaney
- Domain Specific Type Systems - Nathan Sorenson
- One Binder to Rule Them All: Introduction to Trapperkeeper - Nathaniel
Smith, Ruth Linehan
- Responsive Grids with Garden & Clojurescript - Priyatam Mudivarti
- Programming Clojure, Smalltalk-style - Robert Krahn
- Staying SAFE: a Foundation for Clojure Applications - Ron Toland
- Simulant in anger; an experience report - Ryan Neufeld
- Pattern Matching in Clojure: Best Practices - Sean Johnson
- Data Science on Clojure - Soren Macbeth
- Games and 3D Graphics in Arcadia - Timothy Gardner, Ramsey Nasser
- Creating Beautiful Spreadsheets with Data and Templates - Tom Faulhaber
- Composable Healthcare - Tyler Tallman
- The Joys and Pains to Write a Clojure Curriculum for Beginners - Yoko
Harada
- Everything Will Flow - Zach Tellman
- No-strings mobile app development for Clojure - Zachary Kim

Hope to see you there!

-- 
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] EuroClojure 2015

[Alex Miller]

EuroClojure has been a great conference for Clojure for several years - big
thanks to Marco Abis and the community for all of their hard work.

To ensure the continued excellence and growth of the conference, we are
excited that EuroClojure has joined the Cognitect ecosystem. Marco has been
helping us and will continue to help make this conference awesome and
importantly to preserve the unique style of EuroClojure.

We want to thank him for creating the vibrant community event it has
already become. EuroClojure now joins Clojure/conj (in the fall) and
Clojure/West (April 20-22, Portland, OR) in our lineup.

We’re working on an exact date and location for EuroClojure 2015, and
should be able to announce that within the week so stay tuned. Marco and
the Cognitect folks are all excited about this and looking forward to
seeing you all this summer.

Contact us at eve...@cognitect.com for questions or to learn more about
this.

-- 
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] Dunaj project, an alternative core API for Clojure

[Alex Miller]

I'm happy to see experiments if we can learn something useful. Can't really 
judge more till the posts are out. Seems perfectly possible that something 
promising could get a design page and move towards inclusion in some way.

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: How to persist a value while doing do-seq

[Alex Miller]

For the particular use case of removing duplicates there is a new dedupe in 
Clojure 1.7:

http://crossclj.info/fun/clojure.core/dedupe.html

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: Who's using Clojure?

[Alex Miller]

I can confirm that there are a lot of companies training existing devs in 
Clojure. I pretty regularly conduct training classes (for Cognitect) at 
companies in this position, usually for 15-25 devs. Most commonly those devs 
are coming from Java or Ruby. Some of those are well-known Clojure companies 
but many are not. 

I don't track any numbers on it but anecdotally I am seeing a lot more Clojure 
job ads this year than last.

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: Risk of unsafe publishing of LazyTransformer?

[Alex Miller]

Hi Sébastien,

Most publication in LazyTransformer is handled via the synchronized seq() 
method. However, LazyTransformer is being replaced as part 
of http://dev.clojure.org/jira/browse/CLJ-1669 so probably moot.

Alex



On Monday, March 9, 2015 at 5:40:11 PM UTC-5, Sébastien Bocq wrote:
>
> Hello,
>
> I noticed that LazyTransformer [1] implements mutable state without any 
> volatile or final modifier to guard its fields (it might not be an isolated 
> case in the core library e.g. SeqIterator.java).
>
> Isn't such class subject to unsafe publication?
>
>
> For example, considering only this part of the implementation:
>
> public final class LazyTransformer extends ... {
>
>  IStepper stepper;
>  Object first = null;
>  LazyTransformer rest = null;
>
>  public LazyTransformer(IStepper stepper){
>this.stepper = stepper; 
>  } 
>
>  public static LazyTransformer create(IFn xform, Object coll){
>return new LazyTransformer(new Stepper(xform, RT.iter(coll)));
>  } 
>   ... 
>
>  public Object first(){
>if(stepper != null)
>  seq();
>if(rest == null)
>  return null;
>return first; 
>  }
>
>  public ISeq next(){
>if(stepper != null)
>  seq(); 
>if(rest == null)
>  return null;
>return rest.seq(); 
>   }
>   ..
> }
>
> If LazyTransformer/create is called in in one thread and then another 
> thread calls 'first' or 'next' on the new object then I would say there's a 
> chance the second thread sees stepper == null. A real use case could be one 
> thread calling (dedup) [2], which creates lazy sequence with (sequence 
> 
>  
> (dedupe 
> )
>  
> coll), and then another thread iterates through the sequence, which I 
> suppose relies on 'first' and 'next'.
>
> To me it looks like the exact same situation as the one discussed on the 
> Java concurrency-interest here:
>
> http://jsr166-concurrency.10961.n7.nabble.com/Safe-publishing-strategy-tt12126.html
>
> I can't believe I'm the first to be worried by this so maybe I overlooked 
> something. But if I'm not wrong or if there is any doubt, next to 
> refactoring the code to use immutable classes with only final fields (my 
> preferred approach), wouldn't it be safer to declare at least 'stepper' as 
> volatile to prevent any of risk of nasty concurrency issue?
>
> Thanks,
> Sébastien
>
> [1] 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazyTransformer.java
> [2] http://crossclj.info/fun/clojure.core/dedupe.html
>

-- 
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: [GSoC] Mentors contact information

[Alex Miller]

On Monday, March 9, 2015 at 2:25:56 PM UTC-5, Christopher Medrela wrote:
>
> Hello! 
>
> My name is Christopher Medrela. I'm interested in participating in GSoC 
> this year. I've looked at the ideas page and I think that I'd like to work 
> at:
>
> * source metadata information model (mentored by Alex Miller)
>

a...@puredanger.com
 

> * or one of typed clojure projects (mentored by Ambrose Bonnaire-Sergeant).
>
> Could you share with me contact information to these mentors?
>
> Best regards!
>

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

Better outputs produced by the REPL

[Alex Miller]

Try print-str and println-str.

Also see http://clojure.org/cheatsheet for a handy reference.

-- 
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] EuroClojure 2015

[Alex Miller]

We’re pleased to announce that EuroClojure 2015 will be held June 25-26 in
Barcelona, Spain. Thanks again to Marco and the Clojure community, and
we’re looking forward to seeing you all there. Details including
registration, sponsorship, and the call for presentations are forthcoming;
you can check out euroclojure.org or @euroclojure
 for updates!

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: Edn, Fressian, Transit: which of these formats have a future?

[Alex Miller]

Hi Ryan,

To answer the big question, all of these data formats are in active use at 
Cognitect and while I make no promises, I expect them all to be alive and 
active for the knowable future. Each of them targets a different niche but 
all of them share the qualities of transmitting extensible typed values.

edn is the best choice for human-readable data. It is however, less 
efficient to transmit and depends on writing a high-performance parser - 
this is a high bar in some language environments. edn is most attractive 
right now to Clojure users b/c of its proximity to Clojure itself. While it 
has many advantages as an extensible readable literal data format, it's an 
uphill battle to sell that against other data formats that already have 
greater mindshare and tooling in other language communities.

fressian is the highest performance option - it takes full advantage of a 
number of compression tricks and has support for arbitrary user-extensible 
caching. Again, it requires a fair amount of effort to write a fressian 
library though so it's probably best for JVM-oriented endpoints right now. 
By seeking greatest performance, fressian also makes tradeoffs that narrow 
its range of use and interest group.

transit is a pragmatic midpoint between these two. It focuses, like 
fressian, on program-to-program data transmission however, the data can be 
made readable (like edn) via the json-verbose mode. Like fressian, transit 
contains caching capabilities but they are more limited and not 
user-extensible.  transit is designed primarily to have the most 
high-quality implementations per lowest effort - effectively shooting for 
greater reach than either edn or fressian by lower the bar to 
implementation. The bar is lowered by reusing high-performance parser for 
either JSON or messagepack which exist in a large number of languages. Of 
particular importance is leveraging the very high performance JSON parsers 
available in JavaScript runtimes, making transit viable as a browser-side 
endpoint for a fraction of the effort required to write a high performance 
edn or fressian endpoint. As transit explicitly seeks reach and 
portability, it is naturally the format with the broadest potential usage.

Hopefully that lays out the landscape a bit more. With respect to support, 
all of these formats are supported by Cognitect. Like everyone else, we're 
managing priorities across a large number of projects. Filing issues is 
great, voting on issues is great, reports like this are great. External 
tooling is welcome (like pretty printers, etc). Because we use these 
projects inside internal Cognitect projects and products, we do not 
currently have a community contribution model for most of these as there 
may be impacts that are not publicly visible. That could change in the 
future.

I am not an expert on everything you mention below but at a glance it looks 
like on-point feedback and I will raise it with the appropriate people and 
we can follow back here or on the relevant issues as needed.

Thanks,
Alex

On Sunday, March 15, 2015 at 8:40:21 PM UTC-5, Ryan Schmitt wrote:
>
> I'm the author of dynamic-object 
> , an open source library that 
> makes Clojure's data modeling power available to Java programmers. This 
> includes features like serialization and deserialization. I'll copy this 
> small usage example from the README to give you a sense of how it works:
>
> public interface Album extends DynamicObject {
>   @Key(":artist") String getArtist();
>   @Key(":album")  String getAlbum();
>   @Key(":tracks") int getTracks();
>   @Key(":year")   int getYear();
> }
>
>
> String edn = "{:artist \"Meshuggah\", :album \"Chaosphere\", :tracks 8, :year 
> 1998}";Album album = DynamicObject.deserialize(edn, Album.class);
> album.getArtist(); // => "Meshuggah"
>
>
> dynamic-object has always been opinionated about using Edn as the primary 
> data language on the wire, for a number of reasons. For a long time, I also 
> thought about adding Fressian support to dynamic-object, and I've recently 
> done so on an experimental basis. (It looks like this 
> .)
>  
> Some time after I initially released dynamic-object, Transit was also 
> released, with support for various encodings (JSON, JSON-Verbose, 
> MessagePack).
>
> In working (to different extents) with these data languages, I've had some 
> apprehensions about all of them.
>
>- There is a lack of tooling available for Edn, such as validators and 
>pretty-printers. I spent a while looking for an Edn equivalent of python 
>-mjson.tool and never found one. Clojure's built-in pprint function does 
>not work out-of-the-box to pretty print arbitrary values, and also appears 
>to handle some data structures, such as records, incorrectly. (pprint 
> omits

Re: Who's using Clojure?

[Alex Miller]

I added you to http://clojure.org/companies.

On Monday, March 16, 2015 at 2:54:01 PM UTC-5, Matt Owen wrote:
>
> We're using Clojure at Chartbeat.
>
> On Tuesday, April 19, 2011 at 10:38:14 AM UTC-4, Damien wrote:
>>
>> Hi Everyone,
>>
>> I'm on a mission: introducing Clojure in my company, which is a big 
>> consulting company like many others.
>>
>> I started talking about Clojure to my manager yesterday.
>> I was prepared to talk about all the technical benefits and he was 
>> interested.
>> I still have a long way to go but I think that was a good start.
>>
>> However I need to figure out how to answer to one of his questions: who 
>> is using Clojure?
>>
>> Obviously I know each of you is using Clojure, that makes almost 5,000 
>> people.
>> I know there is Relevance and Clojure/core.
>> I read about BackType or FlightCaster using Clojure.
>>
>> But, let's face it, that doesn't give me a killer answer.
>>
>> What could help is a list of success stories, a bit like MongoDB 
>> published here:
>> http://www.mongodb.org/display/DOCS/Production+Deployments
>>
>> Is there a place where I could find this kind of information for Clojure?
>>
>> Thanks
>>
>> -- 
>> Damien Lepage
>> http://damienlepage.com
>>
>>

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

Re: [GSoC] Source meta information model proposal

[Alex Miller]

Tom lovingly maintains autodoc and the Clojure projects' automated doc 
generation with it. But it mostly just continues doing what it does.

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

Re: [GSoC] Source meta information model proposal

[Alex Miller]

Hey all, 

Responding here to several things from both Reid and Francesco. I wanted to 
step back slightly to set some context. I proposed the project that Chris 
has posted and some of the points that Reid brought up are really source 
from my proposal so I wanted to take the blame as it were for anything in 
the original proposal that sucked - not his fault. :) 

My intention in the proposal was not that it necessarily capture everything 
but really convey the core idea. I expected that working through all the 
details *is* the project and would be done as an iterative process talking 
to me and other experts (like Reid and Francesco!!). I should also mention 
that another student has already submitted a proposal to GSOC for this 
project and only one student can work on it. I'm still not exactly sure how 
that is supposed to get resolved.

Anyhow, more comments below. I may also try to dig out some of the longer 
form work I've done on this since it seems to have interest now.

On Tuesday, March 17, 2015 at 9:07:00 AM UTC-5, Francesco Bellomi wrote:
>
> Hi Christopher,
>
> I'm Francesco, the maintainer of crossclj.info
>
> I think it's a very interesting project. Some comments on your proposal:
>
> 1) I think the information model is by far most important deliverable. I 
> agree with Reid that a sound "coordinate system" is very important
>

Totally agreed, and I've said this to both Chris and the other student. 

I do not think what's on the proposal page captures many of the important 
aspects of the problem. Even focusing just on vars ignores what I consider 
to be equally important pieces like records and protocols. I think it's 
important to capture the parts of the source that are needed to *use* a 
project, either as a consumer or as an extender. Some of these fringes are 
particularly the places where the various existing indexers vary.

The coordinate system is particularly important and tricky and I think 
keeping multiple serialization formats (text-based and Datomic-backed are 
two reasonably different targets) in mind is a good way to avoid tailoring 
it to closely to your output needs (html pages). This is indeed the part 
I've spent the most time hammocking on. I know you guys have as well.
 

> 2) The toolchain you want to implement is in part already there. 
> Almost all the metadata you list in your current model are already 
> extracted by codox; codox already separates the extraction phase from the 
> output phase, so you could simply implement the "indexing library" by 
> providing a different output module, in order to generate your model 
> instead of HTML; the internal representation used by codox is already 
> (somehow) a list of namespaces, each one with a list of vars; codox has a 
> rich set of tools (lein plugin, etc.) which would be immediately reusable. 
> Outputting JSON instead of EDN is a one-liner with Cheshire.
>

I don't think JSON is a valuable serialization target. :)  I'd defer any 
notion of toolchain until there is some consensus on model.

3) I'm not sure about the choice of storing "artifact coordinates" as part 
> of a namespace's metadata. Currently it's not the case, the publishing 
> recipe is kept separated (say, in project.clj or in a POM file), and a 
> namespace at runtime has no notion of its coordinates. I think it's the 
> same for all JVM languages. Are we providing extra flexibility, or are we 
> simply complecting two different kind of information?
>

Yeah, that doesn't make sense to me either. I think versioning needs to 
happen at a higher level that can sync up with maven coords. 

>
> 4) One relevant use case is IDE integration: IDEs cannot evaluate source 
> code at runtime in order to generate the relevant metadata (it's not safe), 
> so having this kind of static info would be really useful, ie. for 
> providing users hints on vars generated by macros
>
> Francesco
>
>
>  
>
>
> On Monday, March 16, 2015 at 7:53:53 PM UTC+1, Christopher Medrela wrote:
>>
>> Hello! My name is Christopher Medrela and I'd like to work at "source 
>> metadata
>> information model" project mentored by Alex Miller at Google Summer of 
>> Code. I
>> hope that this mailing list is the right place to discuss such projects 
>> (if I'm
>> wrong, correct 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: [GSoC] Source meta information model proposal

[Alex Miller]

I'm answering these out of order, sorry. :)

On Tuesday, March 17, 2015 at 12:40:53 AM UTC-5, Reid McKenzie wrote:
>
> Hey Christopher,
>
> I'm Reid, the Grimoire maintainer.
> I'm delighted to see that someone besides myself and Alex is interested in 
> this project and I wish you the best in your GSoC application.
>
> I'm somewhat concerned in reading your proposal that while you claim the 
> proposed data structure represents a "minimal superset of the other 
> documentation engines", it is by no means a superset of the lib-grimoire 
> infrastructure.
> In fact the proposed "list of defs, list of namespaces" fails entirely to 
> address the issues with multiple versions of multiple artifacts on multiple 
> platforms that I've spent the last four releases of Grimoire and 
> lib-grimoire wrangling.
>

Agreed, I think addressing versioning is a critical aspect.
 

> The Thing structure and list/walk/read/write API I've provided via 
> lib-grimoire seem to solve these issues at least in my work of trying to 
> build a general documentation engine behind Grimoire so that I can just add 
> artifacts left and right.
>

I haven't looked at this yet, but I think that's a requirement for this.
 

> If I wanted to build a system like Grimoire where the fundamental 
> navigation is entirely `group -> artifact -> version -> platform -> ns -> 
> def` hierarchical decent, why would I choose your representation over the 
> representation already present and usable in lib-grimoire?
> I note with some entertainment that there exists a set of namespaces 
> duplicated between ClojureScript's Clojure and ClojureScript sources.
> For these namespaces and the defs therein, CrossClj.info incorrectly 
> displays the Clojure namespaces when doing a qualified symbol lookup.
> Grimoire used to have the same issue until I asked David Nolen and he said 
> that's a bug.
> You absolutely need the platform to disambiguate what definition and 
> source you're looking at.
>

That's interesting. I suspect the new reader conditional and cljc portable 
file extension will further complicate this.
 

> If I wanted to display the documentation for all the forks of 
> `org.clojure/clojure`, how could I get all of that into your system?
> All the forks have defs in the namespace `clojure.core`.
> How do you propose to tell them apart?
> You have to have the Maven artifactid and groupid.
>

Yes.
 

> Multiple versions of a single artifact?
> Now you need the Maven version as well.
>

Yes.
 

> Now we've encoded all the same information that lib-grimoire already does.
> Why would I agree to use this pair of lists structure and then reconstruct 
> a hierarchy from node data when I could use a fundamentally hierarchical 
> structure for instance the one proposed [here](
> https://github.com/clojure-grimoire/lib-grimoire/issues/9)?
> [by my metrics](http://conj.io/heatmap 
> ),
>  
> the most-visited URLs on Grimoire specify a single def or other content 
> precisely.
> Why would I want to adopt a data format which does not inherently 
> represent this common case of documentation being a lookup when as above I 
> could build or use one that does?
> That you discard these datums with no discussion is worrysome to say the 
> least since I found that they were needed and was forced to invent them 
> after I had done without them for some time.
>

Like I said in the other mail, Chris (or whoever does this project) is 
going to start with less context than you or I. The project hasn't started 
yet and I expect this kind of feedback to be incorporated.
 

> I agree that there is a lot of duplicated code between the various 
> documentation systems.
> Most of it has to do with finding namespaces on the classpath, loading 
> them and documenting them.
> Thankfully we already have `clojure.tools.namespace` which is supposed to 
> solve this problem.
> Currently `clojure.tools.namespace` can't find ClojureScript namespaces.
> As I recall, codox ducks this limitation by implementing its own classpath 
> searching code.
> (apologies to Stuart Sierra who I bugged about patching this a while back.)
>

If stuff like this needs to be built, I think that's a perfectly adequate 
sub-goal for the project.
 

> Your goal of "Building a repl plugin that will search statically across 
> the code accessible by the project so you can query all artifacts without 
> actually loading them." could use some clarification.
> It took me longer than I care to admit to realize you were talking about 
> browsing _documentation_ via some packaged documentation structure(s) 
> before the user actually loads code.
>
> Since the novel work you propose is really a documentation distribution 
> convention, you should say more about that.
> Are you suggesting that every artifact package a "doc.edn" file?
> Is this an open research question you don't have an answer to yet?
>

I do

Re: Clojure Logo Licensing

[Alex Miller]

Rich generally does not approve any use of the Clojure logo if:

a) it's for commercial use (anything that involves collecting money)
b) any modification or inclusion of the logo in other logos
c) any use of the logo or "Clojure" where there could be confusion about 
whether something is "official" 

That's all pretty normal trademark usage stuff. Beyond that, things get a 
bit murkier, and I think this falls in that category. What might be best is 
if we (Cognitect) just send you some stickers, which we would be happy to 
do for a such a thing. 

Can you drop me a note at alex.mil...@cognitect.com and I'll work with you 
on that?

Alex


On Thursday, March 19, 2015 at 4:01:14 PM UTC-5, Uday Verma wrote:
>
> Hello All,
>
> Please accept my apologies in advance if this is not the right channel to 
> ask this question.
>
> I wanted to get some Clojure stickers printed for my upcoming 
> Clojure(script) workshop at Mission Creek Tech Innovation Conference[1].
>
> I see that the clojure-swag[2] has some stickers, but they don't seem 
> close to the quality that sticker mule[3] delivers (sheets vs. shape cut 
> stickers).
>
> I was just wondering if I can get the Clojure logo stickers printed 
> through sticker mule and if there would be any potential legal issues if I 
> do so.
>
> Any help would be greatly appreciated.
>
> Thanks,
> Uday
>
> [1] https://github.com/verma/mcti-clojure-workshop
> [2] http://clojure.org/swag
> [3] https://www.stickermule.com/
>

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

Re: [GSoC] Source meta information model proposal

[Alex Miller]

Chris (and anyone else), Daniel mentioned to me in a note that it is ok for 
multiple students to submit a proposal for the same project. We do not know 
how many spots we will be given as an organization and whether particular 
students will meet whatever guidelines are set out by Google. So I think I 
was a bit incorrect in my understanding of the process and you would still 
be welcome to submit a proposal with the caveat that there are no 
guarantees that any particular proposal will move forward.

Alex

On Wednesday, March 18, 2015 at 3:28:41 PM UTC-5, Christopher Medrela wrote:
>
> Hello! Alex decided to proceed with Richard. Therefore, I'd like to find 
> some
> other project. I'm glad to see so much feedback and I'd really like to 
> reply to
> all your feedback but there is not much time to the end of application 
> period
> and therefore I will focus exclusively on the another project. I hope that
> yours feedback will be helpful for Richard (and the entire community). If
> that's not the case and I've wasted your time, I'm really sorry.
>

-- 
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: Support for IBM JVM?

[Alex Miller]

You are welcome to file a jira ticket for this problem in the system and a 
patch would be welcome if it seems like an issue in the tests (assuming 
things that should not be assumed across JDKs). The percentage of users on 
IBM JDK is very small so it is not the highest priority platform, but I 
don't know of any reason that Clojure itself would have issues on it.

Alex

On Thursday, March 19, 2015 at 11:03:12 AM UTC-5, Thomas wrote:
>
> FYI: At IBM we are suppose to only the IBM JVM and not other version due 
> to legal reason.
>
> Thomas
>

-- 
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] clojure.math.combinatorics 0.1.0

[Alex Miller]

Hey Mark,

This latest release broke all the Clojure 1.2.0 and 1.2.1 builds for 
math.combinatorics 
(http://build.clojure.org/job/math.combinatorics-test-matrix/129/), I think 
due to using an assert arity that didn't exist then? We should either 
change the min version for the test matrix or modify the code to make it 
compatible. I can take care of the former for you if needed.

Alex

On Tuesday, March 17, 2015 at 10:58:45 PM UTC-5, puzzler wrote:
>
> For a while now, the permutations function in the combinatorics library 
> has had special handling for lists with duplicate items.
>
> Example: (permutations [1 2 3]) -> ((1 2 3) (1 3 2) (2 1 3) (2 3 1) (3 1 
> 2) (3 2 1))
> Example: (permutations [1 1 2]) -> ((1 1 2) (1 2 1) (2 1 1))
>
> The new release, version 0.1.0 extends this intelligent handling of 
> duplicate items to combinations and subsets.
>
> There are straightforward computations for counting permutations, 
> combinations, and subsets of n distinct items -- so straightforward it 
> never seemed worth adding to the library.  However, now with the special 
> handling of duplicates, it seems very natural to want to know things like:
>
> (count-permutations [1 1 1 2 2 2]) -> 20  ;not 6!
>
> So I've added count-permutations, count-combinations, and count-subsets 
> which do the obvious things for lists with no duplicates, but for lists 
> with duplicates, computes the count taking into account the special 
> handling of lists with duplicates.  It computes these counts directly, not 
> by iterating through the actual stream of permutations/combinations/subsets.
>
> Similarly, there is now a way to compute the nth 
> permutation/combination/subset without iterating through the result stream.
>
> I've also added two new permutation-related functions:
> drop-permutations lets you efficiently skip over some number of 
> permutations before starting the stream of results.
>
> permutation-index is like nth-permutation in reverse - from a scrambled 
> sortable collection, it will tell you how far into the lexicographic stream 
> of permutations it is located (computed directly without iterating through 
> the stream).
>
> So now you can easily find out in the blink of an eye, for example, that
> "clojurecombinatoricsrocks" is the 169001484919860315564th permutation 
> (0-based) of "abeiijklmnrrrsstu"
>
> Didn't your life feel empty before learning that important fact?
>
> Enjoy the new functionality!
>
> https://github.com/clojure/math.combinatorics
>
> --Mark Engelberg
>

-- 
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: Support for IBM JVM?

[Alex Miller]

Thomas,

I would like to get the build working for IBM JDK at some point but it's 
not a super high priority. For your needs, you should be able to just 
disable the tests that are failing if you are doing your own build of 
Clojure on the IBM JDK. 

Alex

On Thursday, March 19, 2015 at 11:40:59 PM UTC-5, Andy Fingerhut wrote:
>
> Created a ticket: http://dev.clojure.org/jira/browse/CLJ-1678
>
> It appears there is no bug here.  Some Clojure tests were written with 
> particular constants that have equal .hashCode values, to test Clojure's 
> code generation for case expressions when hashCode values collide.  
> Somewhere between IBM JDK 1.6 and 1.7 the hashCode for the BigInteger value 
> used in those tests changed.
>
> Andy
>
> On Thu, Mar 19, 2015 at 4:08 PM, Alex Miller  > wrote:
>
>> You are welcome to file a jira ticket for this problem in the system and 
>> a patch would be welcome if it seems like an issue in the tests (assuming 
>> things that should not be assumed across JDKs). The percentage of users on 
>> IBM JDK is very small so it is not the highest priority platform, but I 
>> don't know of any reason that Clojure itself would have issues on it.
>>
>> Alex
>>
>>
>> On Thursday, March 19, 2015 at 11:03:12 AM UTC-5, Thomas wrote:
>>>
>>> FYI: At IBM we are suppose to only the IBM JVM and not other version due 
>>> to legal reason.
>>>
>>> Thomas
>>>
>>  -- 
>> 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.

Eclipse Public License

[Alex Miller]

Thanks Mike!

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

Clojure 1.7.0-alpha6 is now available.

Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
- Leiningen: [org.clojure/clojure "1.7.0-alpha6"]

Regression fixes from previous alphas (and one from 1.6):

1) CLJ-1544 was rolled back and will be investigated for a future release.
2) CLJ-1637 fixed regression with vec on MapEntry
3) CLJ-1663 fixed regression in classloader (affected Cursive)
4) CLJ-1638 fixed regression with removed PersistentVector.create(List)
method
5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for
literal nil arg
6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that
prevented update

Some highlights new in alpha6:

## Transducer-related changes:

The LazyTransformer introduced to create lazy transforming sequences has
been
replaced with a TransformingIterator. This was done to simplify the code
around transformations and to make certain use cases around eduction more
efficient.

## Faster reduce, iterator, and sequence paths

A lot of work has been done across a set of tickets to improve the ability
of
collections to provide more efficient reduce or iterator performance, and
also to
make common sequence generators create faster sequence and reduce paths. You
should see significant performance in many reduce-related paths (this
includes
reduce, transduce, into, and anything else built on reduce).

Many of those changes also have beneficial sequence performance, so you may
see
some benefits even in code that does not use transducers.

* Most uses of SeqIterator have now been replaced with iterators that
directly walk
the underlying source for improved efficiency. This includes maps, sets,
records, etc.
* repeat - now returns a faster sequence with a fast reduce path
* cycle - now returns a faster sequence with a fast reduce path
* iterate - now returns a faster sequence with a fast reduce path
* range - (did not quite make it in, but coming soon...)
* keys - iterates directly over the keys of a map, without seq or MapEntry
allocation
* vals - iterates directly over the vals of a map, without seq or MapEntry
allocation
* iterator-seq - now creates a chunked sequence when previously it was
unchunked
* vec and set - were not changed in this release but were set up in a
previous alpha
  to take advantage of the reduce and iterator changes above

## Reader conditionals

Reader Conditionals is a new capability to support portable code that
can run on multiple Clojure platforms with only small changes. In
particular, this feature aims to support the increasingly common case
of libraries targeting both Clojure and ClojureScript.

Code intended to be common across multiple platforms should use a new
supported file extension: ".cljc". When requested to load a namespace,
the platform-specific file extension (.clj, .cljs) will be checked
prior to .cljc.

A new reader form can be used to specify "reader conditional" code in
cljc files (and *only* cljc files). Each platform defines a feature
identifying the platform (:clj, :cljs, :cljr). The reader conditional
specifies code that is read conditionally based on the feature/

Form #? takes a list of alternating feature and expression. These are
checked like cond and the selected expression is read and returned. Other
branches are unread. If no branch is selected, the reader reads nothing
(not nil, but literally as if reading ""). An optional ":default" branch
can be used as a fallthrough.

Reader conditional with 2 features and a default:

#?(:clj Double/NaN
   :cljsjs/NaN
   :default nil)

There is also a reader conditional splicing form. The evaluated expression
should be sequential and will be spliced into the surrounded code, similar
to unqoute-splicing.

For example:

   [1 2 #?@(:clj [3 4] :cljs [5 6])]

This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript,
and [1 2] on any other platform.

Additionally, the reader can now be invoked with options for the features
to use and how to interpret reader conditionals. By default, reader
conditionals
are not allowed, but that can be turned on, or a "preserve" mode can be
used to
preserve all branches (most likely useful for tooling or source transforms).

In the preserve mode, the reader conditional itself and any tagged literals
within the unselected branches are returned as tagged literal data.

For more information, see:
http://dev.clojure.org/display/design/Reader+Conditionals

Two important side notes:
- Clojure dependencies have been updated and you must re-run antsetup.sh if
you
build Clojure locally with ant.
- The equivalent ClojureScript support for reader conditionals is not yet
available
but is a top priority to release as soon as possible... stay tuned.

## Printing as data

There have been enhancements in how the REPL prints values without a
print-method, specifically Throwable and the fallthrough Object case.
Both cases now print in a tagged literal data form that can be read
by the reader.

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

In case anyone is curious about the path from here to a final release, the 
remaining items on the 1.7 list can always be found here:

http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10519

The main "feature" things to be done before a beta are optimized range and 
the socket repl (which is undergoing a bit of a refactor in its 
conception). However, I am prioritizing the completion of reader 
conditionals for tools.reader and ClojureScript first.

After that, it's just a matter of working any issues or regressions down to 
release. The more people that try alpha6 and give feedback (positive or 
negative), the faster we can know what if anything needs to be done before 
release, so your assistance is welcomed!! Please give it a shot on your own 
project or library.

Because a lot of performance-related changes went into alpha6, I'm also 
interested in feedback related to that (good or bad).

Thanks,
Alex


On Tuesday, March 31, 2015 at 11:51:13 AM UTC-5, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

As I mentioned in the change log, the current repl chooses to continue 
printing exceptions with no change. But if you print an exception yourself 
with, for example, (println *e), you should see it. Currently you'll see 
that printed without any pretty-printing - there will likely still be some 
changes around the exception printing before release.

On Tuesday, March 31, 2015 at 12:40:31 PM UTC-5, Geraldo Lopes de Souza 
wrote:
>
> Hi,
>
> The fancy printing of exceptions is not working for me. 
>
> Ubuntu 14.04.2 LTS
> java version "1.8.0_40"
> plain clojure jar or lein 2.5.1
> gnome terminal
>
> Regards,
>
> Geraldo
>
> On Tuesday, March 31, 2015 at 1:51:13 PM UTC-3, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>
> Regression fixes from previous alphas (and one from 1.6):
>
> 1) CLJ-1544 was rolled back and will be investigated for a future release.
> 2) CLJ-1637 fixed regression with vec on MapEntry 
> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
> method
> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
> literal nil arg
> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
> prevented update
>
> Some highlights new in alpha6:
>
> ## Transducer-related changes:
>
> The LazyTransformer introduced to create lazy transforming sequences has 
> been 
> replaced with a TransformingIterator. This was done to simplify the code
> around transformations and to make certain use cases around eduction more 
> efficient.
>
> ## Faster reduce, iterator, and sequence paths
>
> A lot of work has been done across a set of tickets to improve the ability 
> of
> collections to provide more efficient reduce or iterator performance, and 
> also to
> make common sequence generators create faster sequence and reduce paths. 
> You
> should see significant performance in many reduce-related paths (this 
> includes 
> reduce, transduce, into, and anything else built on reduce). 
>
> Many of those changes also have beneficial sequence performance, so you 
> may see
> some benefits even in code that does not use transducers.
>
> * Most uses of SeqIterator have now been replaced with iterators that 
> directly walk
> the underlying source for improved efficiency. This includes maps, sets, 
> records, etc.
> * repeat - now returns a faster sequence with a fast reduce path
> * cycle - now returns a faster sequence with a fast reduce path
> * iterate - now returns a faster sequence with a fast reduce path
> * range - (did not quite make it in, but coming soon...)
> * keys - iterates directly over the keys of a map, without seq or MapEntry 
> allocation
> * vals - iterates directly over the vals of a map, without seq or MapEntry 
> allocation
> * iterator-seq - now creates a chunked sequence when previously it was 
> unchunked
> * vec and set - were not changed in this release but were set up in a 
> previous alpha
>   to take advantage of the reduce and iterator changes above
>
> ## Reader conditionals
>
> Reader Conditionals is a new capability to support portable code that
> can run on multiple Clojure platforms with only small changes. In
> particular, this feature aims to support the increasingly common case
> of libraries targeting both Clojure and ClojureScript.
>
> Code intended to be common across multiple platforms should use a new
> supported file extension: ".cljc". When requested to load a namespace,
> the platform-specific file extension (.clj, .cljs) will be checked
> prior to .cljc.
>
> A new reader form can be used to specify "reader conditional" code in
> cljc files (and *only* cljc files). Each platform defines a feature
> identifying the platform (:clj, :cljs, :cljr). The reader conditional
> specifies code that is read conditionally based on the feature/
>
> Form #? takes a list of alternating feature and expression. These are
> checked like cond and the selected expression is read and returned. Other
> branches are unread. If no branch is selected, the reader reads nothing
> (not nil, but literally as if reading ""). An optional ":default" branch
> can be used as a fallthrough.
>
> Reader conditional with 2 features and a default:
>
> #?(:clj Double/NaN
>:cljsjs/NaN
>:default nil)
>
> There is also a reader conditional splicing form. The evaluated expression
> should be sequential and will be spliced into t

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

>From my perspective, Instaparse is reaching pretty far into the guts there. 
>I'll talk to Rich about it though.

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

We do not expect to provide readers for the #object and #error forms
(afaik). It's not possible to actual create a new Object or Throwable form
that would be useful as an instance.

The new tagged-literal function could be used as a fallback reader function
for either though, which would then allow you to retrieve either the tag or
form as data.

On Tue, Mar 31, 2015 at 9:57 PM, Colin Fleming 
wrote:

> One question - it appears that the new #object and #error forms aren't
> readable at the moment. Is this something that's coming, or is the
> intention just that people could provide reader functions for these if they
> wanted to?
>
> On 1 April 2015 at 14:01, Sean Corfield  wrote:
>
>> With instaparse 1.3.6 available, we’ve been able to upgrade our dev stack
>> to Clojure 1.7.0-alpha6 and all our automated tests pass (and our full
>> build/test script seems to be running a bit faster although we haven’t
>> actually benchmarked our application yet). We’ll push alpha6 into QA either
>> later today or tomorrow in preparation for our next production build (we’re
>> running alpha5 in production right now).
>>
>> Sean
>>
>> On Mar 31, 2015, at 3:21 PM, Sean Corfield  wrote:
>>
>> Looks like a great set of updates!
>>
>> Unfortunately, as several of us found out today, the change to the
>> StringReader invoke() signature breaks Instaparse so I’m blocked from
>> testing the World Singles code base with alpha6 (or master) at the moment.
>> Is that just a hazard of relying on the internals of reader classes or
>> would Clojure/core consider that breakage avoidable (by adding an
>> overloaded signature instead of just changing the current signature)? Since
>> those readers extend AFn, it seems that there is an expectation that they
>> would be used as functions in Clojure code out in the wild...
>>
>> Sean
>>
>> On Mar 31, 2015, at 9:50 AM, Alex Miller  wrote:
>>
>> Clojure 1.7.0-alpha6 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
>> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>>
>> Regression fixes from previous alphas (and one from 1.6):
>>
>> 1) CLJ-1544 was rolled back and will be investigated for a future release.
>> 2) CLJ-1637 fixed regression with vec on MapEntry
>> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
>> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List)
>> method
>> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for
>> literal nil arg
>> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols
>> that prevented update
>>
>> Some highlights new in alpha6:
>>
>> ## Transducer-related changes:
>>
>> The LazyTransformer introduced to create lazy transforming sequences has
>> been
>> replaced with a TransformingIterator. This was done to simplify the code
>> around transformations and to make certain use cases around eduction more
>> efficient.
>>
>> ## Faster reduce, iterator, and sequence paths
>>
>> A lot of work has been done across a set of tickets to improve the
>> ability of
>> collections to provide more efficient reduce or iterator performance, and
>> also to
>> make common sequence generators create faster sequence and reduce paths.
>> You
>> should see significant performance in many reduce-related paths (this
>> includes
>> reduce, transduce, into, and anything else built on reduce).
>>
>> Many of those changes also have beneficial sequence performance, so you
>> may see
>> some benefits even in code that does not use transducers.
>>
>> * Most uses of SeqIterator have now been replaced with iterators that
>> directly walk
>> the underlying source for improved efficiency. This includes maps, sets,
>> records, etc.
>> * repeat - now returns a faster sequence with a fast reduce path
>> * cycle - now returns a faster sequence with a fast reduce path
>> * iterate - now returns a faster sequence with a fast reduce path
>> * range - (did not quite make it in, but coming soon...)
>> * keys - iterates directly over the keys of a map, without seq or
>> MapEntry allocation
>> * vals - iterates directly over the vals of a map, without seq or
>> MapEntry allocation
>> * iterator-seq - now creates a chunked sequence when previously it was
>> unchunked
>> * vec and set - were not changed in this release but were set up in a
>> previous alpha
>>   to take advantage of the reduce and iterator ch

Re: Transducers: sequence versus eduction

[Alex Miller]

First, I love this discussion! Great questions, great thinking.

Up top, I wanted to mention a couple things that have changed in alpha6:
- Eduction is no longer Seqable and thus the return from eduction is not 
seqable  (but it is reducible and iterable). You can use iterator-seq to 
get a chunked seq over the top if you need one. 
- Prior to alpha6, sequence with transformations returned a 
LazyTransformer. That's gone and now transformations are done using 
TransformerIterator, which is subsequently wrapped with a (now chunked) 
iterator-seq.
- There are lots of performance implications due to those changes and I 
would recommend re-testing any perf test related to sequence or eduction on 
alpha6 to get a fresh picture as anything pre-alpha6 is not comparable.
- eduction now takes multiple transformations, not just one, and composes 
them. This is designed for mechanical rewriting (hello tool developers!!) 
of ->> chains like this:

(->> s (interpose 5) (partition-all 2))

to this:

(->> s (eduction (interpose 5) (partition-all 2)))

That particular example has timings in CLJ-1669 and shows a reduction from 
501 microseconds to 108 microseconds on a source vector, comparable savings 
on a source sequence. You do need to be careful to not include 
non-transducer functions in that chain, or stop the rewrite when you fall 
into a materialization function at the end (for example, sort). 

On Wednesday, April 1, 2015 at 2:13:07 AM UTC-5, Tassilo Horn wrote:
>
> Hi all, 
>
> I've switched many nested filter/map/mapcat applications in my code to 
> using transducers.  That brought a moderate speedup in certain cases 
> and the deeper the nesting has been before, the clearer the transducers 
> code is in comparison, so yay! :-) 
>

Depending what you're transducing over, you may see some additional gains 
in alpha6.
 

> However, I'm still quite unsure about the difference between `sequence` 
> and `eduction`.  From the docs and experimentation, I came to the 
> assumptions below and I'd be grateful if someone with more knowledge 
> could verify/falsify/add: 
>
>   - Return types differ: Sequence returns a standard lazy seq, eductions 
> an instance of Eduction. 
>

Yes, although I think the actual return type of eduction is not important, 
rather the implemented interfaces of Iterable and IReduceInit are the key 
thing.
 

>   - Eductions are reducible/sequable/iterable, i.e., basically I can use 
>

no longer explicitly seqable, although seq will automatically wrap a 
chunked iterator-seq around it if passed to a sequence function.
 

> them wherever a (lazy) seq would also do, so sequence and eduction 
> are quite interchangeable except when poking at internals, e.g., 
> (.contains (sequence ...) x) works whereas (.contains (eduction ...) 
> x) doesn't. 
>

No guarantees made on those internals, only on what is promised in the 
docstrings (reducible/iterable for eduction and sequence for sequence). :) 
 

>   - Both compute their contents lazily. 
>

eduction is not lazy by itself. if used in a non-seq context, it is eagerly 
recomputed on each use. If you use it in a seq context, then it will be 
computed and cached as needed.
 

>   - Lazy seqs cache their already realized contents, eductions compute 
> them over and over again on each iteration. 
>

Yes.
 

>
> Because of that, I came to the conclusion that whenever I ask myself if 
> one of my functions should return a lazy seq or an eduction, I should 
> use these rules: 
>
>   1. If the function is likely to be used like 
>
>  (let [xs (seq-producing-fn args)] 
>(or (do-stuff-with xs) 
>(do-other-stuff-with xs) 
>...)) 
>
>  that is, the resulting seq is likely to be bound to a variable 
>  which is then used multiple times (and thus lazy seq caching is 
>  benefitical), then use sequence. 
>

Yes, it makes sense to take advantage of seq caching this way.
 

>   2. If it is a private function only used internally and never with the 
>  usage pattern of point 1, then definitively use eduction. 
>


  3. If its a public function which usually isn't used with a pattern as 
>  in point 1, then I'm unsure.  eduction is probably more efficient 
>  but sequence fits better in the original almost everything returns 
>  a lazy seq design.  Also, the latter has the benefit that users of 
>  the library don't need to know anything about transducers. 
>
> Is that sensible?  Or am I completely wrong with my assumptions about 
> sequence and eduction? 
>

You're definitely on the right track. How the result is going to be used is 
pretty important - eduction is designed to be consumed entirely for a 
result and thus gives up the caching of sequences. 

If you are going to consume the entire thing once, particularly in the 
context of a reduction, then eduction is far more efficient. Eduction does 
not need to allocate or cache intermediate sequence objects, so is much 
more m

Re: Transducers: sequence versus eduction

[Alex Miller]

The general idea is that eduction is best when the result will be 
completely consumed in a reducible context. Any case of reusing the result 
will likely be better served by sequence which can cache and reuse the 
answer.

On Wednesday, April 1, 2015 at 3:51:53 AM UTC-5, Tassilo Horn wrote:
>
> vve...@gmail.com  writes: 
>
> > Eduction retains the ability to be recomposed with other transducers 
> > higher in the function chain. The following two are nearly equivalent: 
> > 
> > (transduce (take 1e2) + (eduction (filter odd?) (range))) 
> > (transduce (comp (filter odd?) (take 1e2)) + (range)) 
> > 
> > This will be slower: 
> > (transduce (take 1e2) + (sequence (filter odd?) (range))) 
> > 
> > Execution time mean : 19.054407 µs 
> > Execution time mean : 19.530890 µs 
> > Execution time mean : 39.955692 µs 
>
> Interesting.  But in my code experimentation has shown that sequence is 
> almost always faster in my use-cases which usually look like 
>
>   (sequence (comp (mapcat foo1) 
>   (filter p1) 
>   (map f1) 
>   (mapcat foo2) 
>   (filter p2) 
>   (mapcat foo3) 
>   (filter p3)) 
>  coll) 
>
> Here, I've switched between making the foo* functions return eductions 
> or lazy sequences, and the latter seems to alway be faster although that 
> looks like a use-case of eduction based on my assumptions... 
>
> So maybe eduction can unfold its full potential only during transduce? 
>
> Bye, 
> Tassilo 
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

If this is a use case that could be lifted out into an API level function, 
that would be an ok enhancement jira request to consider (would need to 
think about it more, but that seems like one option).

On Tuesday, March 31, 2015 at 6:12:09 PM UTC-5, puzzler wrote:
>
> The reason instaparse uses Clojure's string reader is to make sure that 
> strings inside the context-free grammar DSL are handled consistently with 
> Clojure's logic for interpreting strings.
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

If you want to invoke the reader programmatically with reader conditionals 
allowed, you can do that through the (new) options map available with both 
read and read-string:

user=> (read-string {:read-cond :allow} "#?(:clj foo :cljs bar)")
foo

There is no way to "turn on" read conditionals by default at the REPL - it 
is only on by default when loading a .cljc file. 


On Wednesday, April 1, 2015 at 11:56:12 AM UTC-5, Alexander Gunnarson wrote:
>
> This patch is incredibly useful! Great job to everyone that contributed. 
> One question: how do I enable conditional reading by default in the REPL as 
> opposed to passing a properties map to /read-string/, etc.? Do I set 
> certain system properties in the command line like "cond_read=true"?
>
> On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>
> Regression fixes from previous alphas (and one from 1.6):
>
> 1) CLJ-1544 was rolled back and will be investigated for a future release.
> 2) CLJ-1637 fixed regression with vec on MapEntry 
> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
> method
> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
> literal nil arg
> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
> prevented update
>
> Some highlights new in alpha6:
>
> ## Transducer-related changes:
>
> The LazyTransformer introduced to create lazy transforming sequences has 
> been 
> replaced with a TransformingIterator. This was done to simplify the code
> around transformations and to make certain use cases around eduction more 
> efficient.
>
> ## Faster reduce, iterator, and sequence paths
>
> A lot of work has been done across a set of tickets to improve the ability 
> of
> collections to provide more efficient reduce or iterator performance, and 
> also to
> make common sequence generators create faster sequence and reduce paths. 
> You
> should see significant performance in many reduce-related paths (this 
> includes 
> reduce, transduce, into, and anything else built on reduce). 
>
> Many of those changes also have beneficial sequence performance, so you 
> may see
> some benefits even in code that does not use transducers.
>
> * Most uses of SeqIterator have now been replaced with iterators that 
> directly walk
> the underlying source for improved efficiency. This includes maps, sets, 
> records, etc.
> * repeat - now returns a faster sequence with a fast reduce path
> * cycle - now returns a faster sequence with a fast reduce path
> * iterate - now returns a faster sequence with a fast reduce path
> * range - (did not quite make it in, but coming soon...)
> * keys - iterates directly over the keys of a map, without seq or MapEntry 
> allocation
> * vals - iterates directly over the vals of a map, without seq or MapEntry 
> allocation
> * iterator-seq - now creates a chunked sequence when previously it was 
> unchunked
> * vec and set - were not changed in this release but were set up in a 
> previous alpha
>   to take advantage of the reduce and iterator changes above
>
> ## Reader conditionals
>
> Reader Conditionals is a new capability to support portable code that
> can run on multiple Clojure platforms with only small changes. In
> particular, this feature aims to support the increasingly common case
> of libraries targeting both Clojure and ClojureScript.
>
> Code intended to be common across multiple platforms should use a new
> supported file extension: ".cljc". When requested to load a namespace,
> the platform-specific file extension (.clj, .cljs) will be checked
> prior to .cljc.
>
> A new reader form can be used to specify "reader conditional" code in
> cljc files (and *only* cljc files). Each platform defines a feature
> identifying the platform (:clj, :cljs, :cljr). The reader conditional
> specifies code that is read conditionally based on the feature/
>
> Form #? takes a list of alternating feature and expression. These are
> checked like cond and the selected expression is read and returned. Other
> branches are unread. If no branch is selected, the reader reads nothing
> (not nil, but literally as if reading ""). An optional ":default" branch
> can be used as a fallthrough.
>
> Reader conditional with 2 features and a default:
>
> #?(:clj Double/NaN
>:cljsjs/NaN
>:default nil)
>
> There i

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

REPLs are of course free to choose how they read and some of the other
changes coming out of the socket repl work may make those choices easier to
select. The clojure.main/repl function is already (perhaps excessively)
parameterized and can be given a custom read function for example. The read
and read-string option maps are intentionally the first arg for easy use
with partial.

On Wed, Apr 1, 2015 at 1:51 PM, Sean Corfield  wrote:

> On Apr 1, 2015, at 10:09 AM, Alex Miller  wrote:
>
> There is no way to "turn on" read conditionals by default at the REPL - it
> is only on by default when loading a .cljc file.
>
>
> This sounds like a useful feature to add to the REPL tho’ so that you can
> copy’n’paste code as-is and have it behave "appropriately" (i.e., you can
> verify that a given section of code does the right thing for a given
> environment)?
>
> I guess we’ll have to see how various IDEs deal with this to know what’s
> really needed…
>
> Sean
>
> On Wednesday, April 1, 2015 at 11:56:12 AM UTC-5, Alexander Gunnarson
> wrote:
>>
>> This patch is incredibly useful! Great job to everyone that contributed.
>> One question: how do I enable conditional reading by default in the REPL as
>> opposed to passing a properties map to /read-string/, etc.? Do I set
>> certain system properties in the command line like "cond_read=true"?
>>
>

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

Re: Transducers: sequence versus eduction

[Alex Miller]

On Wed, Apr 1, 2015 at 2:17 PM, Tassilo Horn  wrote:

> Alex Miller  writes:
>
> Hi Alex,
>
> > - Eduction is no longer Seqable and thus the return from eduction is not
> > seqable (but it is reducible and iterable). You can use iterator-seq to
> get a
> > chunked seq over the top if you need one.
>
> Really?
>
> user> *clojure-version*
> {:major 1, :minor 7, :incremental 0, :qualifier "alpha6"}
> user> (seq (eduction (map inc) (range 10)))
> (1 2 3 4 5 6 7 8 9 10)
>

Yep. :)

user=> (supers (class (eduction (map inc) (range 10
#{clojure.lang.Sequential java.lang.Object java.lang.Iterable
clojure.lang.IReduceInit clojure.lang.IType}

However, seq checks for Iterable and will automatically use iterator-seq to
produce a seq from an Iterable, which is what's happening here.
See:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L517


> - There are lots of performance implications due to those changes and
> > I would recommend re-testing any perf test related to sequence or
> > eduction on alpha6 to get a fresh picture as anything pre-alpha6 is
> > not comparable.
>
> My observations are all based on today's experience with alpha6. :-)
>
> > - eduction now takes multiple transformations, not just one, and
> > composes them.  This is designed for mechanical rewriting (hello tool
> > developers!!) of ->> chains like this:
> >
> > (->> s (interpose 5) (partition-all 2))
> >
> > to this:
> >
> > (->> s (eduction (interpose 5) (partition-all 2)))
>
> Ah, that's sensible.
>
> > The general idea is that eduction is best when the result will be
> > completely consumed in a reducible context.  Any case of reusing the
> > result will likely be better served by sequence which can cache and
> > reuse the answer.
>
> Yes, that's what I guessed.  But at least when I tested replacing
> sequence with eduction at exactly these places () the result has been a
> slight slowdown instead of a speedup.  But that might have been
> accidental as it is hard to do measurements with real-world code where a
> 5% slowdown/speedup might be the reason of something completely
> unrelated.
>

Are you including the cost of realizing the elements? Comparing this stuff
well is hard, or at least I had a hard time thinking through all the
nuances. From what I've looked at, I think the alpha6 changes have made
things slightly worse for sequence with transformations and somewhat better
for eductions used in a reducible or sequence context.


>
> Bye,
> Tassilo
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

We'll consider it, thanks for the questions.

On Wednesday, April 1, 2015 at 2:32:58 PM UTC-5, Alexander Gunnarson wrote:
>
> @Sean Corfield — That's exactly my point. I use Sublime Text and I usually 
> just copy-paste code from various buffers / open files into a REPL buffer 
> on my workspace. Maybe that's not the most efficient way, and I want to 
> move to some sort of auto-reload plugin for leiningen a la figwheel for 
> Clojure, but I'm not sure if the new reader conditionals would with such a 
> plugin anyway. I'd have to experiment. Either way, it would be very 
> convenient to be able to enable/disable reader conditionals via something 
> like (set! *cond-eval* true) or some such thing.
>
>
>

-- 
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: Transducers: sequence versus eduction

[Alex Miller]

On Wed, Apr 1, 2015 at 3:17 PM, Tassilo Horn  wrote:

> Alex Miller  writes:
>
> Ok.  But to me, if I can call `seq` on a thing and iterate it using
> `first` and `rest`, that's a sequable thing to me. :-)
>

Fair enough. I just meant it no longer implements Seqable. :)


> > > The general idea is that eduction is best when the result will
> > > be completely consumed in a reducible context. Any case of
> > > reusing the result will likely be better served by sequence
> > > which can cache and reuse the answer.
> >
> > Yes, that's what I guessed.  But at least when I tested replacing
> > sequence with eduction at exactly these places () the result has
> > been a slight slowdown instead of a speedup.  But that might have
> > been accidental as it is hard to do measurements with real-world
> > code where a 5% slowdown/speedup might be the reason of something
> > completely unrelated.
> >
> > Are you including the cost of realizing the elements?
>
> Oh, yes, and not only that.  The tests I did maybe spend 20% of their
> time in the transducer part, 80% in other stuff.  So I definitively have
> to do some more elaborate benchmarking where the transducer part is
> somehow isolated.
>
> That's why I've asked if there are clear usage-recipes when to use what.
> I think my prime use-case is deeply nested mapcatting where the
> mapcatted function gets an object and returns a java collection, and
> filtering with usually a quite cheap predicate.  E.g.
>
>   (sequence-or-eduction (comp (mapcat ...)
>   (filter ...)
>   (mapcat ...)
>   ...
>   (filter ...))
> coll)
>
> That's part of a larger search algorithm which either stops after
> finding the first match (in which case the resulting sequence is likely
> not to be realized completely) or runs till all matches are found (in
> which case all these transducer-produced sequences would be fully
> realized).
>
> If that would make sense, I could use eduction when I know everything
> will be realized and sequence in the other case (or vice versa).
>

In this case, I don't know that I'd expect much difference. sequence is
going to create a TransformerIterator, and wrap it in an
chunkedIteratorSeq. Using (seq (eduction ...) should give you exactly the
same thing, except calling through an Eduction type. So, I doubt it matters.


> Bye,
> Tassilo
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

I would love a jira for the iterate thIng.

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

Thanks! If anyone wants to throw a patch, would love to have one. Must 
include test ...

On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> http://dev.clojure.org/jira/browse/CLJ-1692
>
> On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant <
> abonnair...@gmail.com > wrote:
>
>> Ok.
>>
>> On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller > > wrote:
>>
>>> I would love a jira for the iterate thIng.
>>>
>>> --
>>> 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.

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

Great to hear feedback like this! I'd be particularly interested if you had any 
suspicions about the characteristics of the ones that are slower.



> On Apr 2, 2015, at 3:22 AM, tcrayford  wrote:
> 
> Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark suite
> (using criterium, with a heck of a lot of work put into getting real and good
> results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - it's
> pretty comprehensive, and covers a wide range of things. Results are below.
> 
> Mostly some things got very minorly slower (but not enough to make a real
> impact for the application), but quite a few benchmarks saw **dramatic**
> speedups.
> 
> Given these promising results, I ran Yeller's `test.check` suite for 8 hours 
> in
> CI, and didn't see any failures, so I've deployed 1.7 alpha6 to production, 
> and
> haven't seen any issues as of yet.
> 
> Yeller's build also got ~24 seconds faster, which is super awesome (and it no
> longer breaks under CLJ-1604 because that patch is in).
> 
> Much love to all the folk who put time and work into this release.
> 
> Benchmark names retracted because they're proprietary. Each line is a 
> seperate benchmark, recorded on production level hardware, with the same jvm 
> options/version used in production. Each benchmark is run in its own JVM 
> (because otherwise JIT path dependence will kill you).
> 
> Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage 
> changed amounts):
> 3.12%
> 2.62%
> 2.27%
> 2.19%
> 2.17%
> 2.06%
> 1.97%
> 1.43%
> 1.29%
> 0.89%
> 0.74%
> 0.71%
> 0.58%
> 0.45%
> 0.42%
> 0.34%
> 0.27%
> 0.25%
> 0.21%
> 0.2%
> 0.08%
> 0.03%
> 
> Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage 
> changed amounts):
> +0.0%
> +0.0%
> +0.01%
> +0.02%
> +0.03%
> +0.03%
> +0.03%
> +0.04%
> +0.04%
> +0.09%
> +0.12%
> +0.16%
> +0.31%
> +0.33%
> +0.52%
> +0.53%
> +0.85%
> +1.74%
> +1.84%
> +1.99%
> +2.14%
> +2.17%
> +2.42%
> +2.96%
> +3.0%
> +5.18%
> +5.36%
> +9.86%
> +11.93%
> +12.41%
> +14.36%
> +16.95%
> +24.71%
> +53.5%
> +53.62%
> +72.07%
> 
> Thanks again! Super excited about this release.
> 
>> On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote:
>> Clojure 1.7.0-alpha6 is now available.
>> 
>> Try it via
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
>> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>> 
>> Regression fixes from previous alphas (and one from 1.6):
>> 
>> 1) CLJ-1544 was rolled back and will be investigated for a future release.
>> 2) CLJ-1637 fixed regression with vec on MapEntry 
>> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
>> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
>> method
>> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
>> literal nil arg
>> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
>> prevented update
>> 
>> Some highlights new in alpha6:
>> 
>> ## Transducer-related changes:
>> 
>> The LazyTransformer introduced to create lazy transforming sequences has 
>> been 
>> replaced with a TransformingIterator. This was done to simplify the code
>> around transformations and to make certain use cases around eduction more 
>> efficient.
>> 
>> ## Faster reduce, iterator, and sequence paths
>> 
>> A lot of work has been done across a set of tickets to improve the ability of
>> collections to provide more efficient reduce or iterator performance, and 
>> also to
>> make common sequence generators create faster sequence and reduce paths. You
>> should see significant performance in many reduce-related paths (this 
>> includes 
>> reduce, transduce, into, and anything else built on reduce). 
>> 
>> Many of those changes also have beneficial sequence performance, so you may 
>> see
>> some benefits even in code that does not use transducers.
>> 
>> * Most uses of SeqIterator have now been replaced with iterators that 
>> directly walk
>> the underlying source for improved efficiency. This includes maps, sets, 
>> records, etc.
>> * repeat - now returns a faster sequence with a fast reduce path
>> * cycle - now returns a faster sequence with a fast reduce path
>> * iterate - now returns a faster sequence with a fast reduce path
>> * range - (did not quite make it in, but coming soon.

Re: Transducers: sequence versus eduction

[Alex Miller]

> On Apr 2, 2015, at 4:09 AM, Tassilo Horn  wrote:

> So we can agree on eduction not being a Sequable but still being
> sequable. :-)

Agreed. :)

> 
>>I think my prime use-case is deeply nested mapcatting where the
>>mapcatted function gets an object and returns a java collection, and
>>filtering with usually a quite cheap predicate. E.g.
>> 
>>(sequence-or-eduction (comp (mapcat ...)
>>(filter ...)
>>(mapcat ...)
>>...
>>(filter ...))
>>coll)
>> 
>>That's part of a larger search algorithm which either stops after
>>finding the first match (in which case the resulting sequence is likely
>>not to be realized completely) or runs till all matches are found (in
>>which case all these transducer-produced sequences would be fully
>>realized).
>> 
>>If that would make sense, I could use eduction when I know everything
>>will be realized and sequence in the other case (or vice versa).
>> 
>> In this case, I don't know that I'd expect much difference. sequence
>> is going to create a TransformerIterator, and wrap it in an
>> chunkedIteratorSeq. Using (seq (eduction ...) should give you exactly
>> the same thing, except calling through an Eduction type.  So, I doubt
>> it matters.
> 
> Ok, thanks.
> 
> Could you also comment on my other question namely the full realization
> of intermediate operations in:
> 
> ,[ Docs of sequence at http://clojure.org/transducers ]
> | The resulting sequence elements are incrementally computed. These
> | sequences will consume input incrementally as needed and fully realize
> | intermediate operations.  This behavior differs from the equivalent
> | operations on lazy sequences.
> `
> 
> Does that mean I'm better off with a traditionally nested
> map/mapcat/filter cascade instead of transducers in the case where the
> intermediate mapcatting functions return possibly not so cheap/large
> lazy sequences and it is likely that I won't fully realize the result
> sequence or eduction?

If you're going to use expanding transformations and not realize all of the 
results then I think sequences are likely a better choice for you.

> 
> Hm, I now benchmarked a bit with criterium and measured
> 
>  (sequence (comp (mapcat #(range %))
>  (mapcat #(range %)))
>(range 1000))
> 
> versus
> 
>  (eduction (comp (mapcat #(range %))
>  (mapcat #(range %)))
>(range 1000))
> 
> versus the traditional
> 
>  (mapcat #(range %)
>  (mapcat #(range %)
>  (range 1000)))
> 
> and either taking just the first element of the result using (first
> ...), taking the first 1000 elements of the result using (dorun (take
> 1000 ...)), or realizing everything using (dorun ...).
> 
> These are the timings:
> 
> | Version| first | first 1000 | everything |
> |+---++|
> | transd. (sequence) | 10 μs | 214 μs | 21 sec |
> | transd. (eduction) | 10 μs | 216 μs | 21 sec |
> | traditional|  3 μs | 151 μs |  7 sec |
> 
> So as you see, the traditional version is about three times faster in
> the first and everything scenario, and just a littlebit faster in the
> first 1000 scenario.
> 
> When I test
> 
>  (sequence (comp (mapcat #(range % 1000))
>  (mapcat #(range % 1000)))
>(range 1000))
> 
> versus
> 
>  (eduction (comp (mapcat #(range % 1000))
>  (mapcat #(range % 1000)))
>(range 1000))
> 
> versus
> 
>  (mapcat #(range % 1000)
>  (mapcat #(range % 1000)
>  (range 1000)))
> 
> so that the larger intermediate sequences come first, I get these
> timings:
> 
> | Version| first | first 1000 | everything |
> |+---++|
> | transd. (sequence) | 24 ms |  24 ms | 21 sec |
> | transd. (eduction) | 24 ms |  24 ms | 21 sec |
> | traditional|  4 μs | 102 μs |  7 sec |
> 
> So here the results are even much worse than above.  If you don't fully
> realize the resulting sequence the traditional version can be many
> orders of magnitudes faster.  I guess that's because of the cited
> statement above, i.e., intermediate operations are always fully
> realized.
> 
> However, at least I had expected that in the case where all elements are
> realized the transducer version should have been faster than the
> traditional version which also needs to fully realize all intermediate
> lazy seqs.  Why is it still three times slower?

I think my main suggestion here is that you are using a non-reducible source 
(range) throughout these timings, so transducers have no leverage on the input 
side. CLJ-1515 will make range reducible and should help a lot on this 
particular example.

> 
> So my conclusion is that you cannot use transducers as a kind of drop-in
> replacement of traditional sequence manipulation functions.  They pay
> off only wh

Re: Any chance of a module system being added to the language?

[Alex Miller]

It's possible we could make use of Java's module system if it ever actually 
gets released in Java 9. While I followed it pretty extensively when they 
first started discussing it (7 or 8 years ago!) I have not been keeping up 
on it lately. Some people have used OSGi with Clojure but I don't gather 
that it's a picnic. Designing a good module system, especially one that 
takes into account Java's classloader architecture, is a challenging task.

Personally, I think it's probably useful to think about your namespace 
layout, so I'm not really looking to get rid of the thinking part. :) 


On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote:
>
> I'd love a module system solving the following problems:
>
> 1. Dependency isolation
> 2. Being able to export vars without having to think about namespace 
> layout in the project
>
> 1. Is a serious problem where transitive dependencies on the classpath put 
> consumers in "jar hell" and force library and tooling authors to either 
> inline code, re-invent the wheel, attempt to run their code in isolated 
> classloaders or turn to source rewriting.
>
> 2. Is a nice to have which is solved today by in potemkin's import-vars, 
> but I think this makes sense to include if modules are added to the 
> language.
>
> We might get some of this for free whenever project jigsaw gets released, 
> but considering it was due in 2007, originally, I'm hoping this can be 
> solved without the help of Oracle.
>
>

-- 
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: Transducers: sequence versus eduction

[Alex Miller]

Just for fun, I ran the (dorun (sequence (comp (mapcat #(range %)) (mapcat 
#(range %))) (range 1000))) and eduction version with the CLJ-1515 patch. I 
saw ~20 seconds before and 15 seconds after. 

But the new version also makes pure seqs better and I saw the full (dorun 
...) drop from 6 seconds before to 3 seconds after too.

Just a hint of the benefits coming in CLJ-1515.



On Thursday, April 2, 2015 at 9:21:08 AM UTC-5, Michał Marczyk wrote:
>
> It may be worth noting that while the return value of range is wrapped in 
> lazy-seq and thus isn't itself a clojure.lang.IChunkedSeq, what you get 
> when you realize it is indeed chunked:
>
> (contains? (ancestors (class (seq (range 128 clojure.lang.IChunkedSeq)
> true
>
> It doesn't implement c.l.IReduce, but 
> clojure.core.protocols/InternalReduce has an implementation for 
> c.l.IChunkedSeq. At least transduce should be able to take advantage of the 
> InternalReduce implementation (via CollReduce). transduce could be used for 
> short-circuiting search with (reduced …), so it might be a legitimate 
> contender here.
>
> Cheers,
> Michał
>
>
> On 2 April 2015 at 15:38, Tassilo Horn > 
> wrote:
>
>> Alex Miller > writes:
>>
>> Hi Alex,
>>
>> > If you're going to use expanding transformations and not realize all of 
>> the
>> > results then I think sequences are likely a better choice for you.
>>
>> Ok, I see.
>>
>> >> However, at least I had expected that in the case where all elements
>> >> are realized the transducer version should have been faster than the
>> >> traditional version which also needs to fully realize all
>> >> intermediate lazy seqs.  Why is it still three times slower?
>> >
>> > I think my main suggestion here is that you are using a non-reducible
>> > source (range) throughout these timings, so transducers have no
>> > leverage on the input side. CLJ-1515 will make range reducible and
>> > should help a lot on this particular example.
>>
>> Well, even if I revamp the (admittedly contrieved) example to have
>> reducible vectors as source and also intermediates
>>
>>   (let [v (vec (range 0 1000))
>> vs (zipmap (range 0 1000)
>>(for [i (range 0 1000)]
>>  (vec (range i 1000]
>> (time (dorun (sequence (comp (mapcat (fn [i] (vs i)))
>>  (mapcat (fn [i] (vs i
>>v
>>
>> it still takes 18 seconds instead of 21 with lazy seqs produced by
>> range, or just 7 seconds with normal lazy seq functions.
>>
>> In my real scenario, I think there's also no IReduces paths because the
>> mapcat functions either return normal lazy seqs or Java Collections
>> (which are not actually clojure collections).  But usually, the
>> transformations are not so freaking expanding as the example above.  I
>> benchmarked a bit, and there sometimes using transducers is faster and
>> sometimes it is not.  So I've made than configurable (with normal lazy
>> seqs as default) so users can benchmark and then decide, and I don't
>> need to choose for them. :-)
>>
>> Oh, and actually *you* have made that possible by making me aware of
>>
>>   (sequence (comp xform*) start-coll)
>>
>> is almost identical to
>>
>>   (->> start-coll xform*)
>>
>> that is, when my macro computes xforms as if they were meant for
>> transducing, I can also use them "traditionally" with ->>.
>>
>> Until now, I've newer used ->> but before I had implemented the
>> expansion for transducers, I used a for with gensyms for intermediates
>> like:
>>
>>   (for [G__1 start-coll
>> G__2 (xform1 G__1)
>> G__3 (xform2 G__2)]
>> G__3)
>>
>> That's pretty much different to generate.  But since the xforms for
>> transducers and ->> are the same, switching between lazy seq fns and
>> transducers is just changing how start-coll and xforms are composed.
>> Awesome!
>>
>> >> So my conclusion is that you cannot use transducers as a kind of
>> >> drop-in replacement of traditional sequence manipulation functions.
>> >> They pay off only when you can make very strong assumptions about the
>> >> sizes and compututation costs of intermediate collections, and I
>> >> think you cannot do that in general.  Or well, maybe you can when you
>> >> program an application but you almost certainly cannot when you
>> 

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

Yup. Fixed.

On Thursday, April 2, 2015 at 1:24:46 PM UTC-5, Leon Grapenthin wrote:
>
> http://dev.clojure.org/display/design/Reader+Conditionals
>
> First use-case "Platform-specific require/import":
>
> Shouldn't the reader conditional example be:
> (ns cemerick.pprng
>   #?(:cljs (:require math.seedrandom
>  [cljs.core :as lang]))
>   #?@(:clj [
> (:require [clojure.core :as lang])
> (:import java.util.Random)])
>   (:refer-clojure :exclude (double float int long boolean)))
>
>
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

If you want caching behavior, then use it as a sequence. If you want faster 
iteration, use it via reduce. The whole point of this change is to open the 
faster reduce path, which you won't get if you also cache.

I did some research a few months back via crossclj looking at how people 
typically use iterate. I can't actually remember finding any use cases other 
than inc or something similar (but it's been a while).



> On Apr 2, 2015, at 6:11 PM, Nicola Mometto  wrote:
> 
> 
> The recent changes to iterate come with an interesting consequence:
> reducing an iterate multiple times will cause the entire chain of x, (f
> x), (f (f x)) .. to be recalculated every time.
> 
> I'd argue that this is not desiderable and a regression (even though
> probably one considered by design), and that this change in behaviour is
> going to produce a degradation in performance when the function to
> iterate actually does some computation rather than being a trivial
> function like the one used in the benchmarks in the CLJ-1603 ticket
> (inc) since its result won't be cached.
> 
> If changing the new behaviour is out of the question I'd suggest to at
> least document this new behaviour. The docstring of iterate talks about
> returning a lazy-seq while when used with reduce it is actually a
> generator.
> 
> To show what I mean here's a silly example using Threa/sleep to simulate
> computation:
> 
> Clojure 1.7.0-alpha5
> user=> (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
> #'user/a
> user=> (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
> "Elapsed time: 106.385891 msecs"
> nil
> user=> (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
> "Elapsed time: 0.560275 msecs"
> nil
> 
> Clojure 1.7.0-master-SNAPSHOT
> user=> (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
> #'user/a
> user=> (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
> "Elapsed time: 109.088477 msecs"
> nil
> user=> (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
> "Elapsed time: 109.51494 msecs"
> nil
> 

-- 
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: into still losing metadata (CLJ-916)

[Alex Miller]

The CLJ-916 commit 
(https://github.com/clojure/clojure/commit/b5d0e84f92038449312bea4c31dcdedd499e28b8)
 
looks like it preserved meta on the to collection but did not merge meta 
from the from collection, so as far as I can tell this is a new 
enhancement. Feel free to file a ticket for that but seems unlikely we'll 
get it into 1.7.

On Friday, April 3, 2015 at 7:14:31 AM UTC-5, Gregg Reynolds wrote:
>
> Hi,
>
> http://dev.clojure.org/jira/browse/CLJ-916 reports that into loses 
> metadata; it is marked closed and fixed in 1.5.  However, into still seems 
> to be losing metadata.  The relevant code from 1.7-alpha6 (core.clj) is:
>
>  (if (instance? clojure.lang.IEditableCollection to)
>(with-meta (persistent! (reduce conj! (transient to) from)) (meta 
> to))
>
> What I need is something like
>
>  (if (instance? clojure.lang.IEditableCollection to)
>(with-meta (persistent! (reduce conj! (transient to) from)) (merge 
> (meta to) (meta from))
>
> Did the fix get lost, or is there a problem with changing into's handling 
> of metadata?
>
> Thanks,
>
> Greggg
>
>

-- 
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: Transducers: sequence versus eduction

[Alex Miller]

I understand your point and there are several competing comparisons here. 
Generally only collection functions take the coll first. eduction is 
similar to sequence (and into and reduce and transduce) in taking it last 
(but differs in taking multiple xforms). The multiple xforms are similar to 
->> though which works left to right and puts the source first. I think I'd 
rather emphasize it's similarity to sequence than its similarity to ->>.


On Friday, April 3, 2015 at 10:08:38 AM UTC-5, miner wrote:
>
>
> > On Apr 1, 2015, at 11:16 AM, Alex Miller  > wrote: 
> > 
> > - eduction now takes multiple transformations, not just one, and 
> composes them. This is designed for mechanical rewriting (hello tool 
> developers!!) of ->> chains like this: 
> > 
> > (->> s (interpose 5) (partition-all 2)) 
> > 
> > to this: 
> > 
> > (->> s (eduction (interpose 5) (partition-all 2))) 
> > 
>
> Maybe it’s just me, but the eduction argument order just looks strange to 
> me.  For a variadic function, I would have expected the single collection 
> to come first, then any number of xforms.  There must be a better reason 
> than mechanical rewriting.  Wouldn't a macro make more sense? 
>
> (defmacro educe->> [coll & xfs] `(->Eduction (comp ~@xfs) ~coll)) 
>
> So the rewrite could be just educe->> for ->>, without having to wrap the 
> xforms at all. 
>
> (educe->> s (interpose 5) (partition-all 2)) 
>
>
>
> Steve Miner 
> steve...@gmail.com  
>
>
>
>
>
>
>

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

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

Yes, I'll get that in the next release, I forgot to put it in there...

On Saturday, April 4, 2015 at 6:45:07 PM UTC-5, Andy Fingerhut wrote:
>
> I believe that change is due to this commit from early March 2015: 
> https://github.com/clojure/clojure/commit/692645c73c86d12c93a97c858dc6e8b0f4280a0b
>
> Nicola Mometto had opened a ticket CLJ-1593 for this issue: 
> http://dev.clojure.org/jira/browse/CLJ-1593
> The commit did not reference the ticket, but Nicola noticed the commit and 
> closed the ticket due to that commit.
>
> Alex, would it be appropriate to include a reference to CLJ-1593 in the 
> Clojure 1.7 release notes?
>
> Andy
>
> On Sat, Apr 4, 2015 at 7:57 AM, Ian Rumford  > wrote:
>
>> Hi Alex, All,
>>
>> An observation really.
>>
>> I've just noticed that a literal map e.g. (def m {:a 1 :b 2 :c 3}) in 
>> alpha6 is an array map not hash map.  
>>
>> In 1.6.0 and 1.7.0-alpha5  its a hash map.
>>
>> Couldn't find any obvious statement in the release notes but interested 
>> in the background to the change.
>>
>

-- 
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] Clojure 1.7.0-alpha6 released

[Alex Miller]

The reader can be invoked programmatically with any feature set you like now. 
We did not plan to allow custom features for 1.7.

I'm not sure what it would mean to "add" an android feature? I'll plead 
ignorance in not knowing how the Clojure 
Android stuff works or where a feature indicating Android could be set without 
support for custom features. Do you currently fork to support Android?



> On Apr 5, 2015, at 1:44 PM, Alexander Yakushev  wrote:
> 
> Hello Alex,
> 
> As I've understood from the dev.clojure.org page, additional features and 
> feature combinations will become available later. Can we please get 
> :clj/android (or :clja) still in 1.7? If so, what has to be done by me or 
> Daniel to make it happen?
> 
> Thanks!
> 
>> On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote:
>> Clojure 1.7.0-alpha6 is now available.
>> 
>> Try it via
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
>> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>> 
>> Regression fixes from previous alphas (and one from 1.6):
>> 
>> 1) CLJ-1544 was rolled back and will be investigated for a future release.
>> 2) CLJ-1637 fixed regression with vec on MapEntry 
>> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
>> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
>> method
>> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
>> literal nil arg
>> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
>> prevented update
>> 
>> Some highlights new in alpha6:
>> 
>> ## Transducer-related changes:
>> 
>> The LazyTransformer introduced to create lazy transforming sequences has 
>> been 
>> replaced with a TransformingIterator. This was done to simplify the code
>> around transformations and to make certain use cases around eduction more 
>> efficient.
>> 
>> ## Faster reduce, iterator, and sequence paths
>> 
>> A lot of work has been done across a set of tickets to improve the ability of
>> collections to provide more efficient reduce or iterator performance, and 
>> also to
>> make common sequence generators create faster sequence and reduce paths. You
>> should see significant performance in many reduce-related paths (this 
>> includes 
>> reduce, transduce, into, and anything else built on reduce). 
>> 
>> Many of those changes also have beneficial sequence performance, so you may 
>> see
>> some benefits even in code that does not use transducers.
>> 
>> * Most uses of SeqIterator have now been replaced with iterators that 
>> directly walk
>> the underlying source for improved efficiency. This includes maps, sets, 
>> records, etc.
>> * repeat - now returns a faster sequence with a fast reduce path
>> * cycle - now returns a faster sequence with a fast reduce path
>> * iterate - now returns a faster sequence with a fast reduce path
>> * range - (did not quite make it in, but coming soon...)
>> * keys - iterates directly over the keys of a map, without seq or MapEntry 
>> allocation
>> * vals - iterates directly over the vals of a map, without seq or MapEntry 
>> allocation
>> * iterator-seq - now creates a chunked sequence when previously it was 
>> unchunked
>> * vec and set - were not changed in this release but were set up in a 
>> previous alpha
>>   to take advantage of the reduce and iterator changes above
>> 
>> ## Reader conditionals
>> 
>> Reader Conditionals is a new capability to support portable code that
>> can run on multiple Clojure platforms with only small changes. In
>> particular, this feature aims to support the increasingly common case
>> of libraries targeting both Clojure and ClojureScript.
>> 
>> Code intended to be common across multiple platforms should use a new
>> supported file extension: ".cljc". When requested to load a namespace,
>> the platform-specific file extension (.clj, .cljs) will be checked
>> prior to .cljc.
>> 
>> A new reader form can be used to specify "reader conditional" code in
>> cljc files (and *only* cljc files). Each platform defines a feature
>> identifying the platform (:clj, :cljs, :cljr). The reader conditional
>> specifies code that is read conditionally based on the feature/
>> 
>> Form #? takes a list of alternating feature and expression. These are
>> checked like cond and the selected expression is read and returned. Other
>> branches are unread. If no branch is selec

Re: [ANN] Clojure 1.7.0-alpha6 released

[Alex Miller]

Yes, each platform defines their own platform feature so it wouldn't be too 
hard to change the specified platform in the fork. However the key here is that 
the conditional occurs at read time, so you need to ensure that compilation 
happens with this platform if aot is involved. Maybe that's obvious.

The existing code in Clojure will not fail in unknown features so you would be 
able to read the same code in Clojure or Android.

I'll ask Rich about a preferred feature name.



> On Apr 5, 2015, at 5:44 PM, Alexander Yakushev  wrote:
> 
> Well, I must say I'm even more ignorant in how the feature expansions are 
> implemented. Is the feature a thing that each implementation defines 
> separately? If so, then it will be easy to set our fork's feature as :clja, 
> or whatever else. My request to you would then be: can you please include 
> :clja into the "spec", in the list of available features? What I ask for is 
> sort of semi-official confirmation that Clojure-Android has its own feature, 
> so that we would have easier time to include Android-specific code into the 
> libraries that will become cross-platform after 1.7 goes live.
> 
> Best regards,
> Alex
> 
>> On Monday, April 6, 2015 at 12:34:04 AM UTC+3, Alex Miller wrote:
>> The reader can be invoked programmatically with any feature set you like 
>> now. We did not plan to allow custom features for 1.7.
>> 
>> I'm not sure what it would mean to "add" an android feature? I'll plead 
>> ignorance in not knowing how the Clojure 
>> Android stuff works or where a feature indicating Android could be set 
>> without support for custom features. Do you currently fork to support 
>> Android?
>> 
>> 
>> 
>> On Apr 5, 2015, at 1:44 PM, Alexander Yakushev  wrote:
>> 
>> Hello Alex,
>> 
>> As I've understood from the dev.clojure.org page, additional features and 
>> feature combinations will become available later. Can we please get 
>> :clj/android (or :clja) still in 1.7? If so, what has to be done by me or 
>> Daniel to make it happen?
>> 
>> Thanks!
>> 
>> On Tuesday, March 31, 2015 at 7:50:27 PM UTC+3, Alex Miller wrote:
>> Clojure 1.7.0-alpha6 is now available.
>> 
>> Try it via
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
>> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>> 
>> Regression fixes from previous alphas (and one from 1.6):
>> 
>> 1) CLJ-1544 was rolled back and will be investigated for a future release.
>> 2) CLJ-1637 fixed regression with vec on MapEntry 
>> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
>> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) 
>> method
>> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for 
>> literal nil arg
>> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that 
>> prevented update
>> 
>> Some highlights new in alpha6:
>> 
>> ## Transducer-related changes:
>> 
>> The LazyTransformer introduced to create lazy transforming sequences has 
>> been 
>> replaced with a TransformingIterator. This was done to simplify the code
>> around transformations and to make certain use cases around eduction more 
>> efficient.
>> 
>> ## Faster reduce, iterator, and sequence paths
>> 
>> A lot of work has been done across a set of tickets to improve the ability of
>> collections to provide more efficient reduce or iterator performance, and 
>> also to
>> make common sequence generators create faster sequence and reduce paths. You
>> should see significant performance in many reduce-related paths (this 
>> includes 
>> reduce, transduce, into, and anything else built on reduce). 
>> 
>> Many of those changes also have beneficial sequence performance, so you may 
>> see
>> some benefits even in code that does not use transducers.
>> 
>> * Most uses of SeqIterator have now been replaced with iterators that 
>> directly walk
>> the underlying source for improved efficiency. This includes maps, sets, 
>> records, etc.
>> * repeat - now returns a faster sequence with a fast reduce path
>> * cycle - now returns a faster sequence with a fast reduce path
>> * iterate - now returns a faster sequence with a fast reduce path
>> * range - (did not quite make it in, but coming soon...)
>> * keys - iterates directly over the keys of a map, without seq or MapEntry 
>> allocation
>> * vals - iterates directly over the vals of a map, without seq or MapEntry 
&g

[ANN] Clojure Applied: From Practice to Practitioner

[Alex Miller]

Hey all,

I'm very happy to announce that Clojure Applied is now available in beta:

https://pragprog.com/book/vmclojeco/clojure-applied

I've been working on this with Ben Vandgrift for a long time, hoping to
fill the underserved niche of *intermediate* Clojure material. Our goal is
to step in after you've read any of the fine introductory books and provide
the next level of guidance needed to successfully apply Clojure to real
problems.

The chapters are:

1. Model Your Domain - an overview of modeling domain entities, modeling
relationships, validating them, and creating domain operations.
2. Collect And Organize Your Data - choosing the right collection, updating
collections, accessing collections, and building custom collections.
3. Processing Sequential Data - using sequence functions and transducers to
transform your data.
4. State, Identity, and Change - modeling change and state with Clojure's
state constructs.
5. Use Your Cores - waiting in the background, queues and workers,
parallelism with reducers, and thinking in processes with core.async.
6. Creating Components - organizing your code with namespaces, designing
component APIs, connecting components with core.async channels, and
implementing components with state.
7. Compose Your Application - assembling components, configuration, and
entry points.
8. Testing Clojure - example- and property-based testing with clojure.test,
expectations, and test.check.
9. Playing With Others - details TBD
10. Getting Out The Door - publishing your code and deploying your
application.

Chapters 1-6 and 10 are available now in beta form. We expect to release a
new chapter every 2-3 weeks until completion. The printed book should be
available this fall.

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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

I'm not sure what unit of "page" you're seeing on your device, but there 
are ~160 PDF pages in the beta and we expect to add maybe 60 more pages 
before completion. Pragmatic adheres to a fairly regular beta schedule of a 
new chapter every 2-3 weeks, so all content should be available within a 
couple months. Thanks for reading!

Alex


On Wednesday, April 8, 2015 at 10:00:32 AM UTC-5, Mike Haney wrote:
>
> I've been waiting for this since the Conj, and so far it has been worth 
> the wait. 
>
> One thing that impressed me right off the bat was the amount of content - 
> 300 pages in this beta version.  A pleasant surprise considering the recent 
> trend of "early access" books that only have 2-3 chapters completed (and 
> often times just the introductory info at 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.

Re: [ANN] Clojure Applied: From Practice to Practitioner

[Alex Miller]

Great to hear!

-- 
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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

I have bought and read most of them and they are all fine choices - I would 
not steer you away from any of them. :) 

I started with "Programming Clojure" (Pragmatic) by Halloway and Bedra, but 
then that's all there was at that point! I also really like both "Clojure 
Programming" by Emerick, Carper, and Grand (O'Reilly) and "Practical 
Clojure" by VanderHart and Sierra (although that one hasn't been updated in 
a while). "Clojure for the Brave and True" by Higginbotham is a lot of fun 
- it's both online and coming in print from No Starch. I haven't had a 
chance to read Carin Meier's new "Living Clojure" but that also promises to 
be great. And then Kyle Kingsbury's online series is great - 
https://aphyr.com/posts/301-clojure-from-the-ground-up-welcome. 

It's not mentioned as much, but Brian Marick's leanpub book "FP for the OO 
programmer" has fantastic exercises, one of the best intros to monads that 
I've seen, and some other interesting stuff - probably best read *with* 
another intro book, I think. 

The "Clojure Cookbook" and "Clojure in Action" are both useful as you are 
start to do more practical stuff. 

For you, "Joy of Clojure" is probably a good 2nd or 3rd book, but others 
will find it useful if they have more Lisp or FP background to start from.

And then, I'd recommend 4clojure.com as a great place to practice.



On Thursday, April 9, 2015 at 11:41:09 AM UTC-5, Derek Koziol wrote:
>
> What do you recommend as "fine introductory books" to get myself at the 
> level needed for this book? I have very little experience with functional 
> programming and Clojure.
>
> On Wednesday, April 8, 2015 at 9:27:58 AM UTC-4, Alex Miller wrote:
>>
>> Hey all,
>>
>> I'm very happy to announce that Clojure Applied is now available in beta:
>>
>> https://pragprog.com/book/vmclojeco/clojure-applied
>>
>> I've been working on this with Ben Vandgrift for a long time, hoping to 
>> fill the underserved niche of *intermediate* Clojure material. Our goal 
>> is to step in after you've read any of the fine introductory books and 
>> provide the next level of guidance needed to successfully apply Clojure to 
>> real problems.
>>
>> The chapters are:
>>
>> 1. Model Your Domain - an overview of modeling domain entities, modeling 
>> relationships, validating them, and creating domain operations.
>> 2. Collect And Organize Your Data - choosing the right collection, 
>> updating collections, accessing collections, and building custom 
>> collections.
>> 3. Processing Sequential Data - using sequence functions and transducers 
>> to transform your data.
>> 4. State, Identity, and Change - modeling change and state with Clojure's 
>> state constructs.
>> 5. Use Your Cores - waiting in the background, queues and workers, 
>> parallelism with reducers, and thinking in processes with core.async.
>> 6. Creating Components - organizing your code with namespaces, designing 
>> component APIs, connecting components with core.async channels, and 
>> implementing components with state.
>> 7. Compose Your Application - assembling components, configuration, and 
>> entry points.
>> 8. Testing Clojure - example- and property-based testing with 
>> clojure.test, expectations, and test.check. 
>> 9. Playing With Others - details TBD
>> 10. Getting Out The Door - publishing your code and deploying your 
>> application.
>>
>> Chapters 1-6 and 10 are available now in beta form. We expect to release 
>> a new chapter every 2-3 weeks until completion. The printed book should be 
>> available this fall.
>>
>> 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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

Thanks! I like that metric.

On Wednesday, April 8, 2015 at 1:07:46 PM UTC-5, Mike Haney wrote:
>
> Yeah, I noticed my mistake after I posted.  I regularly use the kindle app 
> and iBooks and I forgot how they represent page numbers differently. 
>
> So I'll use a different, more appropriate metric - AIDKT's (Ah, I didn't 
> know that).  About 30% of the way through the book, and I'm registering 3-4 
> AIDKT's per chapter.  Good stuff.

-- 
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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

Thanks Mohit!

There was a bug around this that I had fixed at one point, perhaps I didn't 
get that change applied. BTW, for future "bugs" on the book, it's best to 
file them here so we can track 
them: https://pragprog.com/titles/vmclojeco/errata

Alex

On Sunday, April 12, 2015 at 1:28:03 AM UTC-5, Mohit Thatte wrote:
>
> Alex 
>
> I read the preview chapters, great read so far. Looking forward to the 
> whole book.
>
> There seems to be a small error in the Value Based Dispatch section on 
> page 8, where the comments don't match the code. oz and lb seem to be 
> flipped!
>
> (defmulti convert
>> "Convert quantity from unit1 to unit2, matching on [unit1 unit2]"
>> (fn [unit1 unit2 quantity] [unit1 unit2]))
>>
>> ;; lb to oz
>> (defmethod convert [:lb :oz] [_ _ oz] (* oz 16))
>>
>> ;; oz to lb
>> (defmethod convert [:oz :lb] [_ _ lb] (/ lb 16))
>>
>
>
> Cheers,
> Mohit
>
> On Saturday, April 11, 2015 at 6:35:05 AM UTC+5:30, Alex Miller wrote:
>>
>> Great to hear!
>
>

-- 
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] Clojure 1.7.0-beta1 released

[Alex Miller]

I think what you're seeing here makes sense.

On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote:
>
> Are there any thoughts on code like this:
>
> #_
>

This says to ignore the next read form
 

> #?(:cljs (def unrelated-1 nil))
>

This evaluates to *nothing*, ie nothing is read, so it is not ignored by 
the #_.
 

> #?(:cljs (def unrelated-2 nil))
> #?(:cljs (def unrelated-3 nil))
>

These also read as *nothing*.
 

> #?(:clj (def n 10))
>

This *is* read, but ignored per the prior #_ 

#?(:clj (defn num [] n))
> ; compile on clj =>RuntimeException: Unable to resolve symbol: n
>

And then this makes sense.
 

>
> I guess it's fine if it continues to work that way but I can imagine it 
> being a little surprising from time to time heh
>

Conditional reading is definitely something to be careful about - I think 
in this case you are combining two types of conditional reading so be 
doubly careful. :) 

To get the effect you want in this, using #_ *inside* the reader 
conditional would work:

#?(:cljs #_(def unrelated-1 nil))

 

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

Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released

[Alex Miller]

There is a ticket to consider a portable solution to this issue:

http://dev.clojure.org/jira/browse/CLJ-1293

On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote:
>
> The only reason :default exists is because *anything* in JavaScript can be 
> thrown and there needs to be some way to catch non-Error derived values. 
> This is not the case for Java of course. :default could probably be aliased 
> to Throwable, but in the meantime differences like this are now handleable 
> via conditional reading.
>
> David
>
> On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen <
> skinn...@gmail.com > wrote:
>
>> Hmm... In Clojurescript you can do the following
>>
>> (try
>>   ;; throw something
>>   (catch :default e
>>  e))
>>
>> When I try the same thing in Clojure, it seems to not be supported. Is 
>> there any plans to support this syntax in Clojure 1.7?
>>
>>
>

-- 
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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

The errata form is for technical errors, typos, and suggestions.

If you have broader questions or items for discussion, there is also a 
forum available: 
https://forums.pragprog.com/forums/352

Probably better to use either of those than this group.

Thanks...


On Monday, April 13, 2015 at 8:28:46 AM UTC-5, Nando Breiter wrote:
>
> Alex,
>
> Would you also like general feedback at the pragprog.com 
> <http://www.google.com/url?q=http%3A%2F%2Fpragprog.com&sa=D&sntz=1&usg=AFQjCNH42NqPrlF1xg8KTzx39DMWO2I5Xw>
>  
> url? Or is that better here?
>
>
>
> Aria Media Sagl
> Via Rompada 40
> 6987 Caslano
> Switzerland
>
> +41 (0)91 600 9601
> +41 (0)76 303 4477 cell
> skype: ariamedia
>
> On Mon, Apr 13, 2015 at 3:16 PM, Alex Miller  > wrote:
>
>> Thanks Mohit!
>>
>> There was a bug around this that I had fixed at one point, perhaps I 
>> didn't get that change applied. BTW, for future "bugs" on the book, it's 
>> best to file them here so we can track them: 
>> https://pragprog.com/titles/vmclojeco/errata
>>
>> Alex
>>
>>
>> On Sunday, April 12, 2015 at 1:28:03 AM UTC-5, Mohit Thatte wrote:
>>>
>>> Alex 
>>>
>>> I read the preview chapters, great read so far. Looking forward to the 
>>> whole book.
>>>
>>> There seems to be a small error in the Value Based Dispatch section on 
>>> page 8, where the comments don't match the code. oz and lb seem to be 
>>> flipped!
>>>
>>> (defmulti convert
>>>> "Convert quantity from unit1 to unit2, matching on [unit1 unit2]"
>>>> (fn [unit1 unit2 quantity] [unit1 unit2]))
>>>>
>>>> ;; lb to oz
>>>> (defmethod convert [:lb :oz] [_ _ oz] (* oz 16))
>>>>
>>>> ;; oz to lb
>>>> (defmethod convert [:oz :lb] [_ _ lb] (/ lb 16))
>>>>
>>>
>>>
>>> Cheers,
>>> Mohit
>>>
>>> On Saturday, April 11, 2015 at 6:35:05 AM UTC+5:30, Alex Miller wrote:
>>>>
>>>> Great to hear!
>>>
>>>  -- 
>> 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.

Re: [ANN] Clojure Applied: From Practice to Practitioner

[Alex Miller]

On Monday, April 13, 2015 at 9:40:39 AM UTC-5, Jonathon McKitrick wrote:
>
> Will we be notified as new content is added so we can update our 
> electronic versions?
>

Yes, you should be notified when it's updated. Also, if you visit the 
Pragmatic web site and log in, they will notify you if any books on your 
bookshelf have been updated.

We will probably have another update next week with chapter 8 and any 
errata fixes since the first release.

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] Clojure 1.7.0-beta1 released

[Alex Miller]

Well, we never added "fancy printing", just data printing of Throwables. :) 
 

But we were working on this in the context of another thing that got moved 
out and I have pulled that back as a separate ticket:
http://dev.clojure.org/jira/browse/CLJ-1703

Haven't talked to Rich about it yet, but we'll discuss for 1.7.


On Tuesday, April 14, 2015 at 6:06:49 AM UTC-5, Geraldo Lopes de Souza 
wrote:
>
> Hi, 
>
>>
>> Fancy printing is not working.
>
> Geraldo 
>

-- 
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: range function wrong in 1.7.0-beta?

[Alex Miller]

Thanks all! Will definitely fix before release.

-- 
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] Clojure 1.7.0-beta1 released

[Alex Miller]

The serializable thing is not intentional -  would definitely like to fix it!

-- 
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] Clojure 1.7.0-beta1 released

[Alex Miller]

I logged it with a patch here - thanks very much for that report. It's 
tricky because you have to start realizing a chunk before you can see this, 
so the existing serialization tests for range (which didn't do this) were 
working!

http://dev.clojure.org/jira/browse/CLJ-1713


On Monday, April 20, 2015 at 9:04:59 PM UTC-7, Alex Miller wrote:
>
> The serializable thing is not intentional -  would definitely like to fix 
> it!

-- 
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] Clojure 1.7.0-beta2

[Alex Miller]

Clojure 1.7.0-beta2 is now available.

Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
- Leiningen: [org.clojure/clojure "1.7.0-beta2"]

Regression fixes since 1.7.0-beta1:

1) CLJ-1711 - structmap iterator broken
2) CLJ-1709 - range wrong for step != 1
3) CLJ-1713 - range chunks are not serializable
4) CLJ-1698 - fix reader conditional bugs

Additional enhancements to new features since 1.7.0-beta1:

1) CLJ-1703 - Pretty print #error and new public function Throwable->map
2) CLJ-1700 - Reader conditionals now allowed in the REPL
3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj

For a full list of changes since 1.6.0, see:
https://github.com/clojure/clojure/blob/master/changes.md

Please give it a try and let us know if things are working (or not)!

- 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: Strange behaviour of a callable record

[Alex Miller]

It would be great if the ticket has more of the original use case as 
motivation.

On Thursday, April 23, 2015 at 7:00:51 AM UTC-5, Nicola Mometto wrote:
>
>
> I've opened an enhancement ticket with a patch that changes this 
> behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 
> 
>  
>
> Alexey Cherkaev writes: 
>
> > Hi, 
> > 
> > I have encountered the problem with Clojure 1.6.0, when I create the 
> record 
> > that implements IFn. 
> > 
> > For example, 
> > 
> > (defrecord Foo [x] 
> > clojure.lang.IFn 
> > (invoke [_ f] (f x))) 
> > 
> > Than create an instance of this record: 
> > 
> > (def f (->Foo 10)) 
> > 
> > And we can call it without a problem: 
> > 
> > user=> (f inc) 
> > 11 
> > 
> > Yet, if you try to define a value to keep the result, compiler throws an 
> > error: 
> > 
> > user=> (def z (f inc)) 
> > 
> > CompilerException java.lang.AbstractMethodError, 
> > compiling:(form-init4774307052978984831.clj:1:8) 
> > 
> > There is workaround: create local binding first and then assign the 
> value 
> > to a global variable: 
> > 
> > user=> (def z (let [temp (f inc)] temp)) 
> > #'user/z 
> > user=> z 
> > 11 
> > 
> > Is this a bug or I don't fully understand why you can't do that? 
> > 
> > Cheers, Alexey 
>
> -- 
>

-- 
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] Clojure 1.7.0-beta2

[Alex Miller]

Thanks David! 

Instaparse was using some internals of the reader, which changed for reader 
conditionals, but has subsequently been patched.

On Friday, April 24, 2015 at 2:06:01 PM UTC-5, David McNeil wrote:
>
> I did a real quick test on one of our projects. I had to upgrade to the 
> latest compojure (seems the old version used a version of instaparse that 
> wouldn't compile) but after that it seemed to work and was noticably faster.
>
> -David
>

-- 
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: any?

[Alex Miller]

I think 'some' fills this role. Given truthy values, why do you need to use 
boolean with it?

On Saturday, April 25, 2015 at 8:32:09 PM UTC-5, Colin Taylor wrote:
>
> Any reason why we don't have `any?`. Googled without much luck.
> Trivially done as `comp boolean some` not doubt, but I know I use it more 
> than not-any at least.
> It's particularly useful as a composable `or`.
>
>
>

-- 
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: Performance of defmulti in both ClojureScript and Clojure

[Alex Miller]

On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote:
>
> Hi everyone,
>
> There are situations where I want to dispatch functions using based on 
> their certain properties. I can also use case statements instead but it 
> looks more coupled and more change is required if I want to add new types. 
>

case is useful for the particular situation where you have a finite set of 
compile-time constants that you are looking for (integers, characters, 
etc). Then case will leverage a special JVM bytecode that performs a 
*constant-time* look-up (not linear-time like checking a series of cond 
conditions, etc). This is one of the two bytecode options (tableswitch, 
rather than lookupswitch) underlying the Java switch/case feature.

What I want to ask is if I need to avoid using multi-methods for 
> performance reasons? I read somewhere that they are not really fast but the 
> posts were old and the performance might have been improved in between. 
> Should I favor case and cond branches instead of defmulti when I need 
> performance? 
>

multimethods are slower than protocols - they must effectively invoke the 
dispatch function, perform a linear search for a match across the cases, 
and then invoke the actual implementation function. Protocols leverage JVM 
internals to select the right implementation, then invoke it. However, the 
search part of multimethods is cached, making that step fast after the 
initial call. The last time I benchmarked multimethods with class dispatch 
vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I 
found multimethods were about 5x slower.

If you want fastest type-based dispatch with open extension, then protocols 
are the best.
If you want any other type of dispatch with open extension, then 
multimethods are the best.
If you want a closed system of constant choices, then case is best 
(constant-time lookup!)
If you want a closed system of arbitrary conditions, then cond is best.

I have never compared the performance of cond vs multimethods for something 
like this. My guess is that multimethods are faster as they evaluate a 
single condition, then do a table lookup once cached vs evaluating a series 
of conditions every time. 

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: Performance of defmulti in both ClojureScript and Clojure

[Alex Miller]

I should say all of that is for Clojure and likely bears no similarity to 
the nuances in ClojureScript.

On Saturday, April 25, 2015 at 9:39:06 PM UTC-5, Alex Miller wrote:
>
> On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote:
>>
>> Hi everyone,
>>
>> There are situations where I want to dispatch functions using based on 
>> their certain properties. I can also use case statements instead but it 
>> looks more coupled and more change is required if I want to add new types. 
>>
>
> case is useful for the particular situation where you have a finite set of 
> compile-time constants that you are looking for (integers, characters, 
> etc). Then case will leverage a special JVM bytecode that performs a 
> *constant-time* look-up (not linear-time like checking a series of cond 
> conditions, etc). This is one of the two bytecode options (tableswitch, 
> rather than lookupswitch) underlying the Java switch/case feature.
>
> What I want to ask is if I need to avoid using multi-methods for 
>> performance reasons? I read somewhere that they are not really fast but the 
>> posts were old and the performance might have been improved in between. 
>> Should I favor case and cond branches instead of defmulti when I need 
>> performance? 
>>
>
> multimethods are slower than protocols - they must effectively invoke the 
> dispatch function, perform a linear search for a match across the cases, 
> and then invoke the actual implementation function. Protocols leverage JVM 
> internals to select the right implementation, then invoke it. However, the 
> search part of multimethods is cached, making that step fast after the 
> initial call. The last time I benchmarked multimethods with class dispatch 
> vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I 
> found multimethods were about 5x slower.
>
> If you want fastest type-based dispatch with open extension, then 
> protocols are the best.
> If you want any other type of dispatch with open extension, then 
> multimethods are the best.
> If you want a closed system of constant choices, then case is best 
> (constant-time lookup!)
> If you want a closed system of arbitrary conditions, then cond is best.
>
> I have never compared the performance of cond vs multimethods for 
> something like this. My guess is that multimethods are faster as they 
> evaluate a single condition, then do a table lookup once cached vs 
> evaluating a series of conditions every time. 
>
> 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: Performance of defmulti in both ClojureScript and Clojure

[Alex Miller]

Sounds like you might have been running into the absence of multimethod 
caching for the default case (http://dev.clojure.org/jira/browse/CLJ-1429), 
which has been fixed in 1.7. 

Just on a side note, that repo does not change the default lein :jvm-opts, 
which are bad for benchmarking. I recommend at least:

  :jvm-opts ^:replace ["-server"]

Criterium now yells at you if you haven't done this. 


On Monday, April 27, 2015 at 9:43:11 AM UTC-5, Phillip Lord wrote:
>
>
> I think that the answer is, it depends, and, there might be some 
> surprises in store. 
>
> In my own use, I found multimethods collapse in performance as a result 
> of changes to the interface hierarchy in the library I was using (my 
> tests cases went from 45s to over 4mins). 
>
> I circumvented this by fiddling with the dispatch function, so that it 
> returned ONLY classes that exactly matched one of the ones in the 
> multi-method, and memoizing the look up of these classes. In effect, 
> this closes down the multi-method, so it can no longer be freely 
> extended. This dropped the time of my test cases dramatically. 
>
> How widely applicable these results are, I do not know, as I never got 
> down to the mechanistics underneath. Still, my conclusion is, you might 
> want to test things out first! 
>
> My full set of experiments are here... 
>
> http://www.russet.org.uk/blog/3007 
> 
>  
>
>
> Timur > writes: 
>
> > Hi everyone, 
> > 
> > There are situations where I want to dispatch functions using based on 
> > their certain properties. I can also use case statements instead but it 
> > looks more coupled and more change is required if I want to add new 
> types. 
> > 
> > What I want to ask is if I need to avoid using multi-methods for 
> > performance reasons? I read somewhere that they are not really fast but 
> the 
> > posts were old and the performance might have been improved in between. 
> > Should I favor case and cond branches instead of defmulti when I need 
> > performance? 
> > 
> > Thanks for your help!!! 
>

-- 
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: Performance of defmulti in both ClojureScript and Clojure

[Alex Miller]

I fleshed out some of this a bit more in a blog post with perf numbers in 
case anyone's interested:

http://insideclojure.org/2015/04/27/poly-perf/


On Saturday, April 25, 2015 at 9:39:06 PM UTC-5, Alex Miller wrote:
>
> On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote:
>>
>> Hi everyone,
>>
>> There are situations where I want to dispatch functions using based on 
>> their certain properties. I can also use case statements instead but it 
>> looks more coupled and more change is required if I want to add new types. 
>>
>
> case is useful for the particular situation where you have a finite set of 
> compile-time constants that you are looking for (integers, characters, 
> etc). Then case will leverage a special JVM bytecode that performs a 
> *constant-time* look-up (not linear-time like checking a series of cond 
> conditions, etc). This is one of the two bytecode options (tableswitch, 
> rather than lookupswitch) underlying the Java switch/case feature.
>
> What I want to ask is if I need to avoid using multi-methods for 
>> performance reasons? I read somewhere that they are not really fast but the 
>> posts were old and the performance might have been improved in between. 
>> Should I favor case and cond branches instead of defmulti when I need 
>> performance? 
>>
>
> multimethods are slower than protocols - they must effectively invoke the 
> dispatch function, perform a linear search for a match across the cases, 
> and then invoke the actual implementation function. Protocols leverage JVM 
> internals to select the right implementation, then invoke it. However, the 
> search part of multimethods is cached, making that step fast after the 
> initial call. The last time I benchmarked multimethods with class dispatch 
> vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I 
> found multimethods were about 5x slower.
>
> If you want fastest type-based dispatch with open extension, then 
> protocols are the best.
> If you want any other type of dispatch with open extension, then 
> multimethods are the best.
> If you want a closed system of constant choices, then case is best 
> (constant-time lookup!)
> If you want a closed system of arbitrary conditions, then cond is best.
>
> I have never compared the performance of cond vs multimethods for 
> something like this. My guess is that multimethods are faster as they 
> evaluate a single condition, then do a table lookup once cached vs 
> evaluating a series of conditions every time. 
>
> 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] Clojure Applied: From Practice to Practitioner

[Alex Miller]

The second beta of "Clojure Applied" is now available. This version adds 
Chapter 8 (Clojure Testing) as well as a foreword by Russ Olsen, and fixes 
for many of the reported errata.

https://pragprog.com/book/vmclojeco/clojure-applied

If you've already bought the book, you should get an email to download the 
new version.

Alex


On Monday, April 13, 2015 at 12:00:58 PM UTC-5, Alex Miller wrote:
>
> On Monday, April 13, 2015 at 9:40:39 AM UTC-5, Jonathon McKitrick wrote:
>>
>> Will we be notified as new content is added so we can update our 
>> electronic versions?
>>
>
> Yes, you should be notified when it's updated. Also, if you visit the 
> Pragmatic web site and log in, they will notify you if any books on your 
> bookshelf have been updated.
>
> We will probably have another update next week with chapter 8 and any 
> errata fixes since the first release.
>
> 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: complex numbers in clojure

[Alex Miller]

I think it's unlikely that Clojure would add a complex number type. 
However, it might be possible to open up the system enough that new types 
could be created and integrated by others. I think this discussion and 
implementation from clojure-dev (about unsigned numbers) is pertinent:

https://groups.google.com/d/msg/clojure-dev/QF8P7_DK0rc/p8JOlF3Zs44J

In my last posts on that thread, I suggested some of the design and testing 
work that I would expect Rich to ask about. I did not get the impression 
that anyone cared enough to contribute further. If there was enough 
interest, I'd be happy to ask Rich about it.

Alex


On Monday, April 27, 2015 at 1:46:48 PM UTC-5, Lee wrote:
>
> Just cheerleading: I, for one, would love for Clojure to have complex 
> number support, however it can be arranged (built-in or through a library). 
>
> I sometimes do quantum computing work and this issue has prevented 
> progress on a couple of projects. I haven't tried to solve the problem 
> myself, and I'm not sure exactly what the difficulties are in detail, but a 
> couple of strong students have worked on this for me and been stymied.
>
> I started my quantum computing work in Common Lisp, where complex numbers 
> are free and easy... and it's frustrating that this (and only this) has 
> prevented us from continuing that work now that we've switched to Clojure 
> for almost everything else.
>
>  -Lee
>
>
>
> On Apr 27, 2015, at 1:52 PM, Andy Fingerhut  > wrote:
>
> People frequently make their own modified versions of Clojure without 
> having their changes made part of the core Clojure distribution.  That is 
> why I said "depending upon your goals".  If your goal is to try it out and 
> learn from it, and you don't care whether it becomes part of the standard 
> Clojure distribution, then it does not matter what the Clojure core team's 
> priorities are, because they are not involved.
>
> Andy
>
> On Mon, Apr 27, 2015 at 10:46 AM, endbegin  > wrote:
>
>> As far as I know, Java Math does not have a complex number type. Some 
>> implementations of a complex number exist (such as Apache Commons Math), 
>> but they create a Complex class that implements Serializeable and a Commons 
>> specific interface.  
>>
>> Modifying clojure.core itself is a bit daunting, and like you said, it 
>> would need to be a priority for the core team.
>>
>>
>>
>> On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
>>>
>>> Unless the Java Math library handles complex types already, I don't know 
>>> of any way to extend it in a way that would let you get the answer you want 
>>> from (Math/abs my-complex-number) in Clojure.
>>>
>>> If you want code that gives the correct answers, a library using vectors 
>>> or maps for complex numbers can get you there.  Memory footprint and 
>>> performance should be better with Clojure records or a new class written 
>>> directly in Java.  With a library, I don't know of any way to be able to 
>>> mix Clojure's arithmetic operations like + - * / etc. with its existing 
>>> numeric types, and your new library-implemented complex types.
>>>
>>> Support of Clojure's arithmetic operations on complex numbers might only 
>>> be achievable by modifying Clojure itself.  Depending upon your goals, the 
>>> down side of that approach is that it will not become part of the normal 
>>> Clojure distribution unless the Clojure core team wants that addition, 
>>> which I would guess would be very low on their priority list (just a guess 
>>> -- I have no inside knowledge there).
>>>
>>> Andy
>>>
>>> On Mon, Apr 27, 2015 at 8:39 AM, endbegin  wrote:
>>>
 I have been thinking along the lines of mikera and Maik - and it seems 
 like there is no further progress here? I would like to take a crack at 
 creating a complex number type, but implemented as a library to Clojure. I 
 am not sure where to start, and if anyone here has suggestions, I'd be 
 happy to hear them. 

 A complex number could simply be a vector of two elements, or a map 
 with :real and :imag keys (or something lightweight) - and I am not sure 
 what it would require to make this type work happily with code arithmetic 
 functions in Clojure and Java Math. 

 It would also have to work with seq operations in Clojure - for 
 instance: 
 If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 
 -2 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 
 2 
 5). 

 I am having trouble figuring out all the pieces that need to be 
 implemented. Is it even possible to implement this as a library, or does 
 this need to be a part of clojure.core?

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

Re: Question about Clojure codebase

[Alex Miller]

Persistent collections, STM, and the compiler are all deep veins. One may 
also muse on how these were also some of the earliest things in Clojure.

On Tuesday, April 28, 2015 at 6:04:48 PM UTC-5, Renzo Borgatti wrote:
>
> Many choices…. 
>
> We can start from BitmapIndexedNode assoc: 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentHashMap.java#L686
>  
>
> although you might argue that if you read 
> http://lampwww.epfl.ch/papers/idealhashtrees.pdf you know what’s in 
> there. So maybe a classic FnExpr.parse(): 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3860
>  
>
> with all the complexity of parsing a function expression. Or maybe more 
> some hardcore concurrency stuff from the STM: 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L256
>  
>
> that also according to blame is basically untouched since 2009. Impression 
> of complexity is subjective though, someone else could give different 
> answers. 
>
> Renzo 
>
>
> > On 28 Apr 2015, at 17:57, Jonathon McKitrick  > wrote: 
> > 
> > What would you say is the most complex, hard-to-grok code in Clojure 
> codebase? 
> > 
> > -- 
> > 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.

Re: ClassNotFoundException using try inside core.async go block

[Alex Miller]

I think this is a bug in the fairly old tools.analyzer version used in the 
latest released version. That's actually been updated for the next release 
and does not seem reproducible to me there. 


On Tuesday, April 28, 2015 at 6:04:19 PM UTC-5, Chap Lovejoy wrote:
>
> I'm running into a strange exception trying to handle exceptions within a 
> go block. So far this is the simplest test case I've gotten to fail:
>
> (ns test-async
>   (require [clojure.core.async :refer [go >!]
> :as async]))
>
>
> (defn test-chan
>   [chan]
>   (go
> (try
>   (>! chan)
>   (catch Throwable ex
> ex
>
>
> Requiring the namespace results in the following error:
> user=> (require 'test-async :reload)
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
> test-async in this context, compiling:(test_async.clj:7:3)
>
>
> Using either >! or  it go away. Is there something I'm missing here? I'm using the latest 
> (0.1.346.0-17112a-alpha) version of core.async and have tried on both 1.6.0 
> and 1.7.0-beta1.
>
> Thanks,
> Chap
>
>
>
>

-- 
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] Clojure 1.7.0-beta2

[Alex Miller]

On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto  wrote:
>
>
> Now, if you want to argue that the compiler should immediately throw an
> error as soon as the wrong type hint is used rather than silently ignore
> it and fail when the type-hinted form is used, I'll agree with you and
> I've proposed to make the compiler stricter a number of times on the
> clojure-dev ML and talked about it on IRC but I guess either it's not a
> priority for the clojure/core team or they're simply not interested in
> more compile-time checks.
>

Is there a ticket?

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

Different behavior for .cljc file?

[Alex Miller]

There should be no ill effect from simply renaming from clj to cljc. What error 
are you seeing?

Please also consider whether something in your tool chain is at fault. For 
example, if the cljc files are not getting properly packaged or included in the 
classpath then there may need to be changed in the tools. While I've tried 
several things successfully, there could easily be more to do.

-- 
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 community organisation

[Alex Miller]

Re gsoc, last year Cognitect was a receiving organization for the funds and 
distributed them to students for travel to Clojure conferences. This incurs 
some cost on Cognitect for the accounting effort but overall seemed worth it. 
We also offer free tickets to all gsoc students for any Clojure conf we run. We 
are happy to keep doing this but would be happier to be more out of the loop on 
money issues if there was some org that could act in this capacity.

Re the Cognitect position on this stuff, I forwarded it to the appropriate 
people - I don't yet have anything to share.

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.