[ANN] Inlein 0.2.0

[Jean Niklas L'orange]

Hi all,

I just released version 0.2.0 of Inlein <http://inlein.org/>. You can think 
of Inlein as a Leiningen
for scripts, where the project.clj is inlined into the script itself. Inlein
itself starts up very fast, so the startup time of a script is more or less 
only
the time it takes to start Clojure and the dependencies you drag in.

If you have already installed Inlein, you should be able to just run inlein 
--upgrade,
and if not, you can go to https://github.com/hyPiRion/inlein/releases/0.2.0/
for the download link and installation instructions. To get started, you can
take a look over at the Getting Started page 
<https://github.com/hyPiRion/inlein/wiki/Getting-Started> on the wiki. 

If you experience any breaking changes, you can always go back to 0.1.0
by running inlein --upgrade 0.1.0

This release contains a couple of minor bugfixes, and support for 
:exclusions
and file dependencies (:file-deps) in the parameter map.

The biggest addition to this version is support for file dependencies: You 
can
specify other Inlein Clojure files as dependencies to a script file. This 
can be
convenient if you have multiple scripts which all have the same startup
procedure, or need the same utility functions.

For example, if you use Inlein scripts to retrieve data from a database, 
you can
put the code for connecting to the database (fetching environment 
variables, etc.)
and common operations in one file, and let other scripts depend on it:

util/db-setup.clj:

'{:dependencies [[org.clojure/java.jdbc "0.6.0"]
 [org.postgresql/postgresql "9.4.1207.jre7"]]}

(require '[clojure.java.jdbc :as jdbc])

(def db {:dbtype "postgresql"
 :dbname (System/getenv "MYCORP_DBNAME")
 ;; +++
 })

(defn get-users [tx]
  ...)


user-charts.clj:

'{:dependencies [[org.clojure/clojure "1.8.0"]
 [com.hypirion/clj-xchart "0.2.0"]]
  :file-deps #{"util/db-setup.clj"}}
;; additional functions here

(jdbc/with-db-transaction [tx db]
  (->> (get-users tx)
   (aggregate-stats tx)
   (generate-charts {:joined "users-joined.png"
 :activity "user-activity.png"})))

This is not a replacement for namespaces though: If you feel the user 
namespace
is getting polluted, it may be an idea to either refactor the commonly used 
code
into a library, or make a CLI program in your favourite project management 
tool
(Leiningen/Boot).

Here is the full list of visible user changes:

   - Added support for :file-deps (Jean Niklas L'orange)
   - Added support for :exclusions in the parameter map (Jean Niklas 
   L'orange)
   - Fixed a bug where the Windows daemon weren't properly daemonised (Jean 
   Niklas L'orange)
   - Fixed a bug where Inlein crashed when port files weren't properly 
   cleaned up (Mark Mathis)
   - Added proxy support via the System properties http.proxy{Port,Host} 
   (Vladimir Kadychevski)
   - Fixed a bug where download failed on machines where /tmp and $HOME 
   were on different mountpoints (Reid McKenzie)

Thanks to all the contributors who made this happen!

-- Jean Niklas

-- 
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] clj-xchart – A charting/plotting library for Clojure

[Jean Niklas L'orange]

Hi Marshall,

On 17 October 2016 at 07:54, Mars0i <marsh...@logical.net> wrote:

> Looks very nice! Thanks Jean Niklas.  I've been using Incanter for charts,
> which has been fine so far for my needs, but clj-xchart looks like it will
> make it easier to make nicer charts, and it would avoid loading much of
> Incanter when you don't need some of the other things Incanter provides.
> (I also use nvd3 to generate charts in a browser with Clojurescript.)
>

Thanks! This was also parts of the rationale for clj-xchart as well:
Incanter is great, but it feels a bit strange to drag in both json and csv
dependencies if you only need to plot some charts.


> Since you've developed a charting library, maybe I'll mention a feature
> that I have wanted (I think!):
>
> I've been making plots with a large number of points--100K, sometimes even
> 1M or 2M per data sequence.  Sometimes I will sample a larger sequence
> every 10 or 100 steps to reduce the burden on the Incanter or nvd3 plotting
> function, but sometimes I want to see what the data looks like with all of
> the points.
>
> I generate the data in a lazy sequence, using iterate, where, let's say,
> each element of the sequence is a map containing several pieces  of y
> values for the x value corresponding to that element of the sequence, e.g.
>
> data = ({:a y-a-1, :b y-b-1, :c y-c-1}, {:a y-a-2, :b y-b-2, :c y-c-2},
> ...)
>
> In order to plot all three sequences of y values in Incanter or nvd3 (and
> clj-xchart?), I have to extract a new sequence of values for each data
> series, e.g. like this:
>
> (map :a data)
> (map :b data)
> (map :c data)
>
> and I have to generate several sequences of x values by calling (range)
> repeatedly.  I pass these six lazy sequences to the chart function, but at
> least in Incanter and nvd3, I don't believe Incanter does anything until it
> realizes all of the sequences.  That means that it realizes six distinct
> sequences, I think, and my initial sequence of maps will have been realized
> as well.
>
> But if I'm plotting several sequences of y values that are embedded in a
> sequence of maps or vectors, each with several y values for the same x, I
> wonder if it could be more to efficient pass the entire complex sequence to
> the plotting function at once, and only provide one set of x values if all
> of the y values will share the same x's.  If the plotting function extracts
> the y values as it reads through the sequence of maps/vectors, and needs
> only one sequence of x's, then only two sequences are realized.
>
> Maybe this is an unusual need, at present, but as Clojure is used for more
> scientific applications, it might become more common.
>

XChart (and consequently clj-xchart) can take the same x-axis as input. So
you can reuse the same x values instead of creating 3 distinct but
identical ones:

(let [x [1 2 3]
  y1 [1 2 3]
  y2 [2 4 6]
  y3 [3 6 9]]
  (c/xy-chart {"y1" {:x x :y y1}
   "y2" {:x x :y y2}
   "y3" {:x x :y y3}}))

I don't think this is unique to clj-xchart though, the same should apply to
Incanter/JFreeChart.

Unfortunately, clj-xchart will indirectly realise almost all lists it is
given, as it calls .size() on them to ensure that the X/Y/error lists are
identical in size. It will also walk the lists to find the size/scale of
the chart to plot. I'm not sure if there's a way around that, except
perhaps if one pin the boundaries of the plot axes.

That being said, it doesn't seem like a bad idea to provide some sort of
efficient view over data to avoid creating a new list that will be realised
with the exact same data in another list. I made an issue
<https://github.com/hyPiRion/clj-xchart/issues/5> on this, it shouldn't be
too hard to implement either.



For what it's worth, I've had the same "issue" with large datasets as well
(10-20M elements). In my case there isn't that much interesting to look at
except the occational outlier, or if you have values which differ extremely
from one datapoint to another.

What I tend to do is rebin/shrink the data set, typically by computing the
average/max value of partitions (after filtering away outliers), depending
on what I need to plot. I have a small section in the "Gotchas" section
named Many Datapoints
<https://github.com/hyPiRion/clj-xchart/blob/master/docs/tutorial.md#many-datapoints>
(bottom
of the page) which has a couple of lines on how one can do that. I haven't
found a good generic interface for it yet, so it's not provided by
clj-xchart as of now.

-- 
Regards,
Jean Niklas L'orange

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

[ANN] clj-xchart – A charting/plotting library for Clojure

[Jean Niklas L'orange]

Hi Clojurians,

I am happy to announce clj-xchart ! 
XChart  is a lightweight charting
library for Java. clj-xchart wraps this library and tries to be a
succinct yet evident charting library for Clojure. The library can
emit the following chart types:

- Line charts
- Scatter charts
- Area charts
- Bar charts
- Histogram charts
- Pie charts
- Donut charts
- Bubble charts
- Stick charts

It also provides the following useful features:

- Easy to compare, view and make charts from a REPL
- Logarithmic axes
- Number, Date and Category X-Axis
- Export to png, gif, jpg, svg, pdf and eps
- Extensive customisation

Note that clj-xchart is a Clojure only library; if you need
interactive or animated charts in a web browser, then this library
will not help you with that. However, if you need png/jpg/svg/pdfs of
charts, then this may be a viable option.

To see a couple of example charts, along with the code required to
generate them, head over to the examples page 
.

The tutorial 
 for 
the current release should give you a good
introduction in how to use the library, and the render options page 

page has additional information about how to style the charts. The
majority of all commits and work has been related to examples and
documentation, and I hope this will make the library easy to use.

The source code is over at https://github.com/hyPiRion/clj-xchart

Suggestions and contributions are welcome!

-- Jean Niklas

-- 
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] Leiningen 2.7.1

[Jean Niklas L'orange]

Hi fellow Clojurians,

I am happy to announce Leiningen 2.7.1! This release contains bugfixes
to managed dependencies, and an alternative installation option: Users
who use SDKMAN! <http://sdkman.io/> can now install Leiningen by issuing 
`sdk install leiningen`.

The list of changes since 2.7.0:

* Add support for SDKMAN! as installation alternative. (Jean Niklas
  L'orange)
* Improved text in some error messages. (Jean Niklas L'orange)
* Don't require `nil` for version in managed deps. (Chris Price)
* Fix a bug with snapshot dependencies for managed deps. (Chris Price)

For those who manually installed, `lein upgrade` will automatically
upgrade to the latest version. `lein downgrade 2.7.0` will bring it
back down to 2.7.0 if you run into any issues.

-- Jean Niklas

-- 
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] Leiningen 2.7.0

[Jean Niklas L'orange]

Greetings, fellow Clojurians!

I am happy to announce Leiningen 2.7.0! This release contains mostly
bugfixes, but two major new improvements were added. There is now a
PowerShell version of `lein.bat`, and `:managed-dependencies` has been
added to Leiningen.

Both improvements should be considered to be in beta, but please try
them out and report bugs you find in the GitHub issue tracker. The
rationale for `:managed-dependencies` can be found at [1].

To replace `lein.bat` with the PowerShell equivalent, download
`lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
you end up with an error related to `Invoke-WebRequest`, then it may
be a result of an old version of PowerShell, which seems to be
resolved by installing the Windows Management Framework 4.0 [4].

The full list of significant user changes:

* Add PowerShell script for Windows users. (Brian Lalonde)
* Run `:prep-tasks` before `lein test`, so generated test namespaces
  will be tested. (Martin Reck)
* Better error message when attempting to do `lein run` without
  `project.clj`. (Eduardo Seabra Silva)
* Add support for `:managed-dependencies`. (Chris Price)
* Provide the current clojars certificate. (Toby Crawley)
* Add `*eval-print-dup*` to evaluate forms passed to
  `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
* Update bash completions. (Zack Dever)
* Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
* Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
* Catch and handle fixture errors during `lein test`. (Alex Hall)
* Fix a bug where spaces in directory names on Windows caused crashes.
  (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
* Fix a bug where `lein search` would take forever downloading
  clojars.org. (Paul Dorman)
* Retain user defined private repositories when building jars,
  uberjars and deploy. (Rick Moynihan)
* Honor whitelist settings when `lein javac` is called via `lein jar`.
  (Chris Price)
* `lein vsc push` for git will now only push branch-related tags.
  (Łukasz Klich)

Those who have manually installed Leiningen can run `lein upgrade` to
pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
previous version if you run into any issues. Keep in mind that the
PowerShell script was introduced in this release, hence there are no
downgrade candidates for it right now.

We have had lots of contributors help out making this release happen,
and I'd especially like to thank Chris Price (cprice404) and Florian
Anderiasch (winks) for their help with this release.

[1]: 
https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
[2]: 
https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd
[3]: 
https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1
[4]: 
http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx

-- Jean Niklas


-- 
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] clj-conduit 0.1.0

[Jean Niklas L'orange]

Hello fellow Clojurians,

I have just released the first version of clj-conduit 
 – a small library that attempts 
to make transducers a bit more readable.

To give you a taste, here's the take transducer implemented with 
clj-conduit:

(ns my.namespace
 (:refer-clojure :exclude [await])
 (:require [com.hypirion.conduit :refer [await yield conduit]]))

(defn taking [n]
  (conduit
(dotimes [_ n]
  (yield (await)


Compare this with how take is implemented in clojure.core:

(defn take
  ([n]
 (fn [rf]
   (let [nv (volatile! n)]
 (fn
   ([] (rf))
   ([result] (rf result))
   ([result input]
  (let [n @nv
nn (vswap! nv dec)
result (if (pos? n)
 (rf result input)
 result)]
(if (not (pos? nn))
  (ensure-reduced result)
  result)))
   ...)


Information about usage and source code can be found over at 
https://github.com/hyPiRion/clj-conduit

https://github.com/hyPiRion/clj-conduit/wiki/clojure.core-ports contains 
all the clojure.core transducers implemented with conduit, to give you some 
examples to look at.

I also wrote a blogpost about it, explaining usage, implementation details 
and the 
rationale: http://hypirion.com/musings/transducers-to-conduits-and-back

-- Jean Niklas

-- 
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] Inlein 0.1.0

[Jean Niklas L'orange]

On 14 March 2016 at 19:45, Christopher Small  wrote:

> I know that planck (http://planck-repl.org/) has successfully achieved
> cljs scripting capacity on OSX (and I've heard there's progress on Linux
> support as well, but am fuzzy on the details). Do you think support for
> planck or something similar might be achievable through inlien? This would
> make it an attractive candidate for snappy, short-lived scripting tasks as
> well.
>

I would certainly hope so, but I am not familiar enough with cljs to answer
this properly. It is on my list of things to investigate and look into.

Anything that comes out of it will most likely not depend on Planck
directly though, as I'd like to support as many common OSes as possible for
now (Windows/Unix).

On 14 March 2016 at 23:24, Yehonathan Sharvit  wrote:

> Really awesonme.
> Is there a way to use the repl while developing a script with inlein?
>

It's possible, yes. You can for example add

(do (clojure.main/repl)
(System/exit 0))

at the very end of your script.

If you want a more sophisticated repl, you can use reply by adding it as a
dependency (temporarily):

'{:dependencies [[org.clojure/clojure "1.8.0"]
 ;; ...
 [reply "0.3.7"]]}

;; your code

(do (reply.ReplyMain/main (into-array String ["--standalone"]))
(System/exit 0))

If you wonder about the (do (repl) (System/exit 0)) idiom, it's used to
stop the Clojure reader to attempt to read more data while you're editing
the script. Otherwise it'll work similar to running a bash script while
you're editing the script itself, which usually ends in pain and errors.

I'm not sure whether I consider that a bug or not yet (being able to edit
script while running), so thoughts on this is welcome. I can't imagine
anything but issues by supporting it right now.

(See also https://github.com/hyPiRion/inlein/blob/master/examples/repl.clj
for a customised repl example, and
https://github.com/hyPiRion/inlein/issues/8 for an issue to create a basic
provided repl for users)

-- Jean Niklas

-- 
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] Inlein 0.1.0

[Jean Niklas L'orange]

Hi all Clojurians,

Alex Miller did some research 
 on slow 
boot times with Clojure/scripting in
Clojure not too long ago.

What I found weird was that there were no tool for doing Clojure scripting. 
It's
possible to do this with both Leiningen and Boot, but neither were 
originally
designed for scripts nor fast startup times. I have personally found this a 
bit
annoying in the past, as I have had good reasons to use Clojure for 
scripting.

Therefore, I have created a new tool called Inlein . You 
can think of it as a
Leiningen for scripts, where the project.clj is inlined into the script 
itself.
Inlein itself starts up very fast, so the startup time of a script is more 
or
less only the time it takes to start Clojure and the dependencies you drag 
in.

You could probably use this for a lot of things. The first thing that comes 
to
mind is obviously long-running scripts and CLI programs, but it could also 
be
used for customised REPLs, independent of Boot and Leiningen.

There are probably many uses for Inlein that I haven't thought of yet, but 
if
you want inspiration, you can have a look in the examples directory 
.

Inlein is located over at https://github.com/hyPiRion/inlein and the 0.1.0
version can be downloaded from
https://github.com/hyPiRion/inlein/releases/0.1.0/

To get started, you can take a look over at the Getting Started page 
 on the
wiki.

-- Jean Niklas

-- 
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] Leiningen 2.6.0

[Jean Niklas L'orange]

On Wednesday, February 10, 2016 at 9:18:04 PM UTC+1, Avi Flax wrote:
>
> Does this mean that those who manually installed will not experience these 
> improvements? If so, I’m curious as to why? 
>

Ah, good question: People who installed manually will already have the
performance improvements that Homebrew users now get. So installing via
Homebrew or manually should not yield any performance differences.

As to the reason why: The manual installation uses the default `lein`
script, whereas Homebrew uses a stripped down version named `lein-pkg`.
We tweaked `lein` to speed up the Leiningen JVM startup times, but this
was not ported over to `lein-pkg`. Thanks to Thu Trang Pham, `lein` and
`lein-pkg` are now in sync.

I'll be sure to verify that changes to `lein` is properly ported over to
`lein-pkg`, so that we can avoid the mismatch in the future.

-- Jean Niklas

-- 
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] Leiningen 2.6.0

[Jean Niklas L'orange]

Hi all,

Instead of creating a new thread for the 2.6.1 release of Leiningen,
I'll just piggyback on this one.

Leiningen 2.6.1 is a small release to fix an issue with 2.6.0. Some
popular plugins (`lein midje`, `lein ring` to mention a few) broke
because of a change in eval-in-project. This has now been fixed.

Sorry for any inconvenience caused.

-- Jean Niklas

On Friday, February 5, 2016 at 2:27:37 AM UTC+1, Jean Niklas L'orange wrote:
>
> Greetings!
>
> I am happy to announce Leiningen 2.6.0! This release contains mostly
> usability improvements, along with some bugfixes. 
>
> The biggest notable change will likely be for Homebrew users. When the
> Homebrew formula is updated to 2.6.0, you will likely experience startup
> time improvements.
>
> In addition, `lein release` now supports '-SNAPSHOT' on qualifiers (alpha,
> beta, RC), and signing GPG artifacts from the terminal will give you
> feedback on whether you managed to type in your passphrase correctly or
> not.
>
> Due to syntax changes from Clojure 1.1.0 to 1.2.0, we had to drop
> support for Clojure 1.1.0 and older.
>
> The full list of significant changes:
>
> * The templates, repl and Leiningen itself now use Clojure 1.8.
> * Support for Clojure 1.1.0 and older is now dropped.
> * Warn if possibly stale native dependencies end up in `:native-path`.
>   (Jean Niklas L'orange)
> * Speed up restarts after `:dependency` changes. (Jean Niklas L'orange)
> * `lein release` now supports SNAPSHOT on qualifiers. (Chris Price)
> * Synchronise `lein-pkg` and `lein` scripts. (Thu Trang Pham)
> * Decrease timeout for the Clojure compiler agent thread pool. (Ryan
>   Fowler)
> * Fix a bug where implicit resource directories were created by default.
>   (Jean Niklas L'orange)
> * Avoid optimizing away stack traces by default. (solicode)
> * Fix a bug where duplicate profiles were merged when profile merging.
>   (Jean Niklas L'orange)
> * Improved GPG artifact signing feedback. (Jean Niklas L'orange, Andrea
>   Richiardi)
> * Add function to support binary files with `lein-new`. (Sergiy Bondaryev)
> * Show better error message when java is not found on the path. (Pavel
>   Prokopenko, Jürgen Hötzel)
> * Fix a bug with non-GitHub SCM urls in pom files. (Ralf Schmitt)
> * Don't send aot warning if `:aot` contains regex matching the main
>   namespace. (Emlyn Corrin)
>
> As usual, for those who manually installed, `lein upgrade` will pull in
> the latest. `lein downgrade 2.5.3` will back it down to the previous
> version if you run into any issues.
>
> Thanks to all the contributors who made this happen!
>
> -- Jean Niklas
>
>

-- 
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] Leiningen 2.6.0

[Jean Niklas L'orange]

Greetings!

I am happy to announce Leiningen 2.6.0! This release contains mostly
usability improvements, along with some bugfixes. 

The biggest notable change will likely be for Homebrew users. When the
Homebrew formula is updated to 2.6.0, you will likely experience startup
time improvements.

In addition, `lein release` now supports '-SNAPSHOT' on qualifiers (alpha,
beta, RC), and signing GPG artifacts from the terminal will give you
feedback on whether you managed to type in your passphrase correctly or
not.

Due to syntax changes from Clojure 1.1.0 to 1.2.0, we had to drop
support for Clojure 1.1.0 and older.

The full list of significant changes:

* The templates, repl and Leiningen itself now use Clojure 1.8.
* Support for Clojure 1.1.0 and older is now dropped.
* Warn if possibly stale native dependencies end up in `:native-path`.
  (Jean Niklas L'orange)
* Speed up restarts after `:dependency` changes. (Jean Niklas L'orange)
* `lein release` now supports SNAPSHOT on qualifiers. (Chris Price)
* Synchronise `lein-pkg` and `lein` scripts. (Thu Trang Pham)
* Decrease timeout for the Clojure compiler agent thread pool. (Ryan
  Fowler)
* Fix a bug where implicit resource directories were created by default.
  (Jean Niklas L'orange)
* Avoid optimizing away stack traces by default. (solicode)
* Fix a bug where duplicate profiles were merged when profile merging.
  (Jean Niklas L'orange)
* Improved GPG artifact signing feedback. (Jean Niklas L'orange, Andrea
  Richiardi)
* Add function to support binary files with `lein-new`. (Sergiy Bondaryev)
* Show better error message when java is not found on the path. (Pavel
  Prokopenko, Jürgen Hötzel)
* Fix a bug with non-GitHub SCM urls in pom files. (Ralf Schmitt)
* Don't send aot warning if `:aot` contains regex matching the main
  namespace. (Emlyn Corrin)

As usual, for those who manually installed, `lein upgrade` will pull in
the latest. `lein downgrade 2.5.3` will back it down to the previous
version if you run into any issues.

Thanks to all the contributors who made this happen!

-- Jean Niklas

-- 
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] Leiningen 2.5.3

[Jean Niklas L'orange]

Greetings, Clojurians.

I am happy to announce the release of Leiningen version 2.5.3. This version
contains mostly bugfixes, most notably an issue where environment variables 
were
not propagated down to GPG. This caused `lein deploy` and similar commands 
to
fail if you set up GPG with the `GPG_AGENT_INFO` environment variable. In
addition, `lein vcs tag` now supports `--no-sign` if you do not want to sign
your git tags.

Here's a list of user-visible changes:

## 2.5.3 / 2015-09-21

* Add CHANGELOG.md to default lein templates. (Daniel Compton)
* `lein vcs tag` now supports the `--no-sign` flag. (Daniel Compton)
* Fix a bug where javac errors were not printed to terminal. (Brandon 
Shimanek)
* Fix a bug where environment variables were not propagated down to GPG. 
(Brandon Shimanek)
* `lein retest` now saves information on which tests that fail. (Shalaka 
Patil)

For those who manually installed, `lein upgrade` will pull in 2.5.3, and 
`lein
downgrade 2.5.2` will bring you back to the previous version if you run 
into any
issues.

Thanks to all the contributors who made this happen!

-- Jean Niklas

-- 
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] Leiningen 2.5.2

[Jean Niklas L'orange]

Hello fellow hackers,

I am happy to finally announce the release of Leiningen 2.5.2, which I know 
a
lot of you have been waiting for. This version is mainly a bugfix release, 
but
there are also some new enhancements to the `new` command. To all the Cider
users out there, nREPL has also been updated to 0.2.10.

## 2.5.2 / 2015-08-09

* Allow repl dependencies to be specified in default user profiles. (Jean 
Niklas L'orange)
* Fix a bug where transitive dependencies on tools.nrepl failed. (Jean 
Niklas L'orange)
* Fix a bug preventing custom certificates to work. (Jean Niklas L'orange)
* Add support for reader conditional files. (Stephen Nelson)
* Add `--template-version` flag to `lein new`. (Ohta Shogo)
* Bail immediately if snapshot dependencies are discovered during 
uberjaring. (Justin Smith)
* Use powershell by default in `lein.bat`. (Frederick Giasson, Florian 
Anderiasch)
* Fix bug where manifest files could contain duplicate entries. (Michael 
Blume)
* Allow template designers to use a custom rendering function. (Dmitri 
Sotnikov)
* Fix a bug where `:uberjar-name` wasn't used when inside the `:uberjar` 
profile. (Kyle Harrington)

Running `lein upgrade` will pull in the latest stable release, and if you 
run
into any issues you can always run `lein downgrade 2.5.1` to go back to the
previous release. Please report any issues on the Leiningen mailing list or 
the
GitHub issue tracker.

Thanks to all the contributors and users who helped us get to this release.

---

As you may have realised, Phil is not the one releasing Leiningen this time
around. You can read more about this at
http://librelist.com/browser//leiningen/2015/7/25/next-steps/

I would like to thank Phil for the countless hours he has spent making 
Leiningen
into the amazing project and community it is. Leiningen is an important 
part of
the Clojure community, and without Phil, we wouldn't be where we are now.

I am honoured to be Phil's successor as maintainer of Leiningen, and will 
strive
to do the job as well as Phil did.

-- Jean Niklas

-- 
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: Paper on Immutable Persistent Data Structures

[Jean Niklas L'orange]

On Tuesday, July 21, 2015 at 1:43:54 AM UTC+2, JvJ wrote:

 Does anyone know if there exists a paper/web page describing in detail how 
 each of Clojure's data structures are implemented?


I have a formal analysis and all the core algorithms related to the 
Persistent Vector in Chapter 2 of my thesis: http://hypirion.com/thesis.pdf

Bagwell's original paper on the Array Mapped Trie, which is the basis for 
the Persistent Hash Map implementation, is also a good read and probably 
more approachable 
paper: http://infoscience.epfl.ch/record/64394/files/triesearches.pdf

And, as already mentioned, my informal blogpost series about them is over 
at http://hypirion.com/musings/understanding-persistent-vector-pt-1

I really like Okasaki's book Purely Functional Data Structures, but if 
you're only interested in the Persistent Vector and Persistent Hash Map, 
then I think it would be overkill to read it. Variants of them are first 
described in chapters 9-10. Mohit gave a good link to understand the sorted 
sets and maps.

-- Jean Niklas

-- 
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] Understanding the Persistent Vector

[Jean Niklas L'orange]

Hi Frank,

On Wednesday, March 4, 2015 at 12:24:42 PM UTC+1, Frank Castellucci wrote:

 Will you be doing this for other data types?


I will have a small break first, but I intend to do the same kind of series 
for persistent hash maps/sets. Maybe even RRB-trees if people are 
interested (I found them to be pretty hard to grasp by the paper alone).

Again, Great Work!


Thanks! =)

-- Jean Niklas


Frank

 On Saturday, February 28, 2015 at 11:14:17 AM UTC-5, Jean Niklas L'orange 
 wrote:

 Hello fellow Clojurians,

 I am happy to announce that I have finished my blogpost series on the 
 persistent
 vector. It consists of five parts:

1. The basic algorithms 
http://hypirion.com/musings/understanding-persistent-vector-pt-1
2. Indexing 
http://hypirion.com/musings/understanding-persistent-vector-pt-2
3. The tail optimisation 
http://hypirion.com/musings/understanding-persistent-vector-pt-3
4. Transients 
http://hypirion.com/musings/understanding-clojure-transients
5. Performance 
http://hypirion.com/musings/persistent-vector-performance-summarised 
(which is a summary of this detailed blogpost 
http://hypirion.com/musings/persistent-vector-performance)

 I hope this will help you to get a good understanding of how the 
 algorithms on
 the data structure work, how the optimisations work, and how efficient it 
 is on
 the JVM.

 Constructive criticism, both positive and negative, is appreciated.

 Enjoy!

 (NB: I haven't gotten around to fix the illustrations in part 3, so
 unfortunately it will be a bit hard to read if you print it out in 
 grayscale.
 It's on my todo-list.)

 -- Jean Niklas L'orange



-- 
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] Understanding the Persistent Vector

[Jean Niklas L'orange]

Hi Bost,

Thanks for the input!

Yeah, I agree it might be a bit confusing right now. I'll definitely change 
it to something that's a bit easier to grok, probably with some inspiration 
from your suggestion.

On Tuesday, March 3, 2015 at 11:58:00 AM UTC+1, Bost wrote:

 Hi Jean 

  The tail optimisation 
  http://hypirion.com/musings/understanding-clojure-transients 

 It took me a second to find out how the graphs for the vector-trie and 
 tail correspond to each other. 
 Please consider slightly deeper explanation or add some visual clues. 
 Something like: 
 http://picpaste.com/pics/tails-colored.1425379672.png 


-- 
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] Understanding the Persistent Vector

[Jean Niklas L'orange]

Hello fellow Clojurians,

I am happy to announce that I have finished my blogpost series on the 
persistent
vector. It consists of five parts:

   1. The basic algorithms 
   http://hypirion.com/musings/understanding-persistent-vector-pt-1
   2. Indexing 
   http://hypirion.com/musings/understanding-persistent-vector-pt-2
   3. The tail optimisation 
   http://hypirion.com/musings/understanding-persistent-vector-pt-3
   4. Transients 
   http://hypirion.com/musings/understanding-clojure-transients
   5. Performance 
   http://hypirion.com/musings/persistent-vector-performance-summarised 
   (which is a summary of this detailed blogpost 
   http://hypirion.com/musings/persistent-vector-performance)

I hope this will help you to get a good understanding of how the algorithms 
on
the data structure work, how the optimisations work, and how efficient it 
is on
the JVM.

Constructive criticism, both positive and negative, is appreciated.

Enjoy!

(NB: I haven't gotten around to fix the illustrations in part 3, so
unfortunately it will be a bit hard to read if you print it out in 
grayscale.
It's on my todo-list.)

-- Jean Niklas L'orange

-- 
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] Leiningen 2.5.1 released

[Jean Niklas L'orange]

Hi there,

On Monday, January 12, 2015 at 3:22:46 AM UTC+1, hba wrote:

 The message comes from wget [1] and to fix it i uninstalled it to let 
 leiningen-win-installer [2] use curl instead. 


If it's more sensible to use curl over wget on Windows by default, then I'd 
like to have one of you creating a new issue in the lein issue tracker[1]. 

It's probably also possible to use the %HTTP_CLIENT% environment variable 
to solve this. If the Windows shell works anything like bash, then this 
should be something like
SET HTTP_CLIENT=call curl -f -L -o

[1]: https://github.com/technomancy/leiningen/issues

-- Jean Niklas

-- 
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: About transients no longer being safe in 1.7-alpha2

[Jean Niklas L'orange]

Hi there,

On Tuesday, November 4, 2014 8:05:03 AM UTC+1, Daniel Marjenburgh wrote:

 I know transients aren't bash-in-place, as they may return new references, 
 but that is not the problem I'm having here.
 If you bash in place, you would get unexpected results, but still the same 
 result every time. The problem here is that the 'value' of the transient is 
 changing underneath you because of another thread.


To ensure consistency, you must ensure that you update a transient value at 
most once – all calls (including reads) on the same transient value after 
an update is illegal/undefined behaviour. Transient updates – minus 
persistent! – will always return a new transient value, even though the 
transient returned may be the same reference. So the code

(let [v (transient {:a 0})
  f1 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))
  f2 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))]
  @f1 @f2 ; wait for futures
  (persistent! @f1))

will result in undefined behaviour, because the original v is updated twice 
(and is potentially read after an update). The correct way would be to do 
the following:

(let [v {:a 0}
  f1 (future (reduce #(assoc! % (+ (:a %) %2)) (transient v) (range 
10)))
  f2 (future (reduce #(assoc! % (+ (:a %) %2)) (transient v) (range 
10)))]
  @f1 @f2 ; wait for futures
  (persistent! @f1))

I don't see an explicit rule at http://clojure.org/transients stating this, 
although I feel it is implicit from the bash in-place rule. Perhaps that's 
something worth adding to the page to avoid confusion.

--
Regards,
Jean Niklas L'orange

 

 Op dinsdag 4 november 2014 06:13:00 UTC+1 schreef Alex Miller:



 On Monday, November 3, 2014 10:44:19 PM UTC-6, Atamert Ölçgen wrote:

 Thanks Alex!

 Now that I took a second look at Daniel's code, it seems assoc! is used 
 like swap!, as if it would modify m in place. So I would expect, if it runs 
 without errors, result to be {:a 0}.


 Right, that is an incorrect usage - it will actually modify with changes 
 though, but not in expected ways (this is independent of the change we're 
 discussing - you can get the same behavior in a single thread modifying a 
 transient without reusing the return).

 Given that transients are values (not reference types like ref or atom) I 
 can't think of a case where they can be modified concurrently.


 You can, but not without going pretty far out of normal Clojure code. 
  



 On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller al...@puredanger.com 
 wrote:



 On Monday, November 3, 2014 9:00:10 PM UTC-6, Atamert Ölçgen wrote:



 On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh 
 dmarje...@gmail.com wrote:

 Hi,

 I just want to address this issue (CLJ-1498 
 http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in 
 1.7-alpha2 and I haven't seen a lot of discussion around it, even though 
 it's quite a big change.

 With this change the following code is possible:


 With persistents the result would be the same, every time. If this is 
 now valid Clojure, I didn't run it myself, we are sacrificing 
 consistency. 
 I don't understand what we're getting in return.

 Even the simple example in the ticket (with one future) doesn't make a 
 lot of sense to me.

 Am I missing something obvious?


 Transients always expect thread isolation. In the past this was locked 
 to a single thread (the one that made the transient). That restriction now 
 extends to being used by multiple threads, but isolation should still be 
 maintained for proper use. 

 What we are gaining is the ability to use transient collections in go 
 blocks with core.async, where the thread being used is just one pool out 
 of 
 a thread. For example (just typing this not running it, so excuse any 
 typos):

 (defn drain [ch coll] 
   (let [t (transient []]
 (go-loop
   (if-some [v (! ch)]
 (do (conj! t v) (recur))
 (persistent! t)

 This doesn't necessarily work in core.async because each time the ! 
 parks, it may be woken up with a different thread from the pool. The 
 transient change allows this kind of code to succeed.



 (let [m (transient {:a 0})
   futs (for [n (range 100)]
  (future (assoc! m :a (inc (:a m)]
   (mapv deref futs) ; wait until futures are done
   (persistent! m))


 The results will vary per run, where it used to throw 
 an IllegalAccessError: Transient used by non-owner thread.

 I understand the problems of not being able to have 1 go routine 
 access a transient, even though it would be safe, but this solution 
 feels 
 like it's throwing out the baby with the bathwater. Basically, it's 
 doing 
 away with what the following block on clojure.org 
 http://clojure.org/transients says:

 *Transients enforce thread isolation**.* Because each result of a 
 transient operation shares (mutable) structure with the previous, it 
 would 
 be very dangerous if more than one thread were to manipulate a 
 transient at 
 once. In order

Re: About transients no longer being safe in 1.7-alpha2

[Jean Niklas L'orange]

Hi Daniel,

On Tuesday, November 4, 2014 11:54:30 AM UTC+1, Daniel Marjenburgh wrote:

 Hi Jean,

 In this case, we are dealing with 1 key-value pair, so there is only one 
 transient reference all the time. It is not my experience that each update 
 returns a new transient value (here, each update is identical to the 
 original, as per the identical? predicate).


I probably worded myself poorly: When I wrote transient value, I meant the 
contents of a transient, not the reference to it.

I like to think of transients like this: They work exactly like persistent 
data structures, but when any kind of update is performed on the transient, 
the runtime should be allowed to deallocate the old transient head if it 
wants to. If I use transients correctly, I should never see any segfaults 
(or whatever you want to call it) due to transient usage.

Now, the runtime doesn't actually deallocate the transient head, it 
(usually) reuses it for performance. Which means that the old transient 
references are equal to the new transient references, even though the old 
transient contents are overwritten (and therefore invalidated). So even 
though you can use the old transient reference to refer to the new 
transient value, it's not referring to the old transient value.

If it helps you, you can also think of transients as linear types, like the 
ones in Rust. Their constraints are very similar, but correct transient 
usage have to be verified by us, not the compiler. Now, whether that's a 
good idea or not is another matter.
 

 I know you shouldn't use transients in the way I illustrated, but use it 
 as if it always returns a new value. In that scenario, you would not get 
 inconsistent results, as multiple threads would have to coordinate to pass 
 the reference around (as happens in core.async) and the birth-thread check 
 is unnecessary.

 Still, the onus is now put on the user to ensure correct use of transients 
 in a multi-threaded environment, as no warning or error is given anymore. 
 It has always been the case that Clojure makes it hard to write unsafe 
 mutable code, you had to go out of your way. With this change, I feel we 
 are giving up this safeguard a bit too easily.

 Maybe another solution could be to have the birth-thread explicitly 
 relinquish ownership of the transient, for example, by calling 
 (relinquish-transient m). Then the thread that makes the next transient 
 update would become the new owner. If another thread updates a transient 
 while another threads owns it, the usual error is thrown. This way we 
 maintain the safety as before and it becomes a issue for core.async to deal 
 with transients in logical threads, not clojure.core. I guess a go macro 
 could recognize transients in go-blocks and auto-relinguish them before 
 parking operations so that the user can keep thinking in logical threads. 
 I'd like to know how feasible a solution like that would be.


 Op dinsdag 4 november 2014 11:12:08 UTC+1 schreef Jean Niklas L'orange:

 Hi there,

 On Tuesday, November 4, 2014 8:05:03 AM UTC+1, Daniel Marjenburgh wrote:

 I know transients aren't bash-in-place, as they may return new 
 references, but that is not the problem I'm having here.
 If you bash in place, you would get unexpected results, but still the 
 same result every time. The problem here is that the 'value' of the 
 transient is changing underneath you because of another thread.


 To ensure consistency, you must ensure that you update a transient value 
 at most once – all calls (including reads) on the same transient value 
 after an update is illegal/undefined behaviour. Transient updates – minus 
 persistent! – will always return a new transient value, even though the 
 transient returned may be the same reference. So the code

 (let [v (transient {:a 0})
   f1 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))
   f2 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))]
   @f1 @f2 ; wait for futures
   (persistent! @f1))

 will result in undefined behaviour, because the original v is updated 
 twice (and is potentially read after an update). The correct way would be 
 to do the following:

 (let [v {:a 0}
   f1 (future (reduce #(assoc! % (+ (:a %) %2)) (transient v) (range 
 10)))
   f2 (future (reduce #(assoc! % (+ (:a %) %2)) (transient v) (range 
 10)))]
   @f1 @f2 ; wait for futures
   (persistent! @f1))

 I don't see an explicit rule at http://clojure.org/transients stating 
 this, although I feel it is implicit from the bash in-place rule. Perhaps 
 that's something worth adding to the page to avoid confusion.

 --
 Regards,
 Jean Niklas L'orange

  

 Op dinsdag 4 november 2014 06:13:00 UTC+1 schreef Alex Miller:



 On Monday, November 3, 2014 10:44:19 PM UTC-6, Atamert Ölçgen wrote:

 Thanks Alex!

 Now that I took a second look at Daniel's code, it seems assoc! is 
 used like swap!, as if it would modify m in place. So I would expect, if 
 it 
 runs without errors, result

Re: Is there a term for non-map collections?

[Jean Niklas L'orange]

On Friday, May 16, 2014 6:53:08 PM UTC+2, Mars0i wrote:

 Is there a single term that covers vectors, lists, sets, lazy sequences, 
 cons's, etc., but not maps?

 
I would use a collection of keywords in your example. As mentioned by 
Steve, a map is a collection of map entries/pairs, so a map *cannot* be a 
collection of keywords.

-- Jean Niklas

-- 
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: core.logic with functions

[Jean Niklas L'orange]

Hey Phillip,

If you want to say the goal g(x) shall succeed, for all x in this list, 
then use `everyg` from clojure.core.logic instead of map. I think it is 
exactly what you're looking for.

On Monday, April 28, 2014 3:36:10 PM UTC+2, Phillip Lord wrote:



 I can do this with core.logic (yes, I know that match-list isn't doing 
 anything much here) 

 (defn match-list [member list] 
   (membero member list)) 


 (run* [q] 
   (match-list 10 [1 10 100]) 
   (== q worked)) 

 For q to come back with any values then 10 has to be part of the list [1 
 10 100]. 

 I want to do the same thing where the second argument is a list of 
 lists. So something like: 

 (defn match-lists [member lists] 
   (map 
(fn [l] (membero member l)) 
lists)) 

 (run* [q] 
   (match-lists 10 
[[1 10 100] 
 [1 10 100]]) 
   (== q worked)) 

 which should also return worked. The point is that I don't know how 
 many membero forms I need at compile time, only at runtime. My initial 
 attempt above fails. 

 java.lang.ClassCastException: clojure.lang.LazySeq cannot be cast to 
 clojure.lang.IFn 
  at clojure.core.logic.Substitutions.bind (logic.clj:410) 
 logic_expts.what_i_want$eval7021$fn__7022$fn__7023$_inc__7024.invoke 
 (form-init238773086654203315.clj:2) 
 clojure.core.logic$eval5780$fn__5781$fn__5782.invoke 
 (logic.clj:1109) 


 Is there a way to do this with functions -- or do I need to macro it? 

 Phil 

-- 
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: fast parallel reduction into hash-set/map

[Jean Niklas L'orange]

Hello,

On Saturday, March 15, 2014 11:37:11 PM UTC+1, Jules wrote:

 2. I've had a look at rrb-vector - very fast for catvec - agreed, but 
 there does appear to be a performance penalty in terms of conj[!]-ing - I 
 can post my results if you  are interested. I read the Bagwell paper on 
 which your work was based and came away with the impression that he did not 
 think he was introducing significant overhead with his improvements for 
 constant tiime concatenation - so maybe this is due to rrb being impled in 
 clojure and builting vec in java ? 


I've not looked at the implementation done by Michał in detail (lack of 
documentation makes it a tad hard to grok), but a properly implemented 
variant should have about the same performance as a normal vector when no 
concatenation has been done on the vector, and would only require one extra 
check. Transients which aren't concatenated should have same performance 
guarantees as transient Clojure vectors, but only if the node size is fixed 
to 32 elements.

However, I've found it rather hard to perform the general conj-case 
efficiently, so you're right that conjing will be slower on average in an 
RRB-vector after concatenations. I'm trying to find ways to cut off large 
parts of the constant factor off, and hope to get some results dished out 
in some months time.

Another factor here is that the Clojure impl *may* suffer from suboptimal 
JVM-emitted code, although that is purely speculation from my side.

As for 3, I've not looked into GPU programming of these things as the 
memory is not contiguous and would probably be messy to transfer over.

-- JN

-- 
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: Accumulate results without state?

[Jean Niklas L'orange]

Hello,

On Tuesday, March 4, 2014 10:47:12 PM UTC+1, Jason Felice wrote:

 Something like

 (with-open [rdr (clojure.java.io/reader /dev/errors-sunday.csv)]
   (- (line-seq rdr)
  (filter #(re-matches #...))
  (map #(nth (string/split % #,) 1

 Will do what you want.  It's laziness to the rescue.


Just a heads up: laziness is dangerous when using I/O. In this case, 
with-open will close the reader before all lines have been read, and throw 
an IOException for trying to read from a closed reader.

Add a `doall` to the end of the threading, and it should be safe. Or use 
`slurp` to read the whole file, avoiding the problem to begin with.

As another suggestion: You can use a for comprehension, if you consider it 
more readable. It's relatively similar to your imperative version.

(with-open [rdr (clojure.java.io/reader /dev/errors-sunday.csv)]
  (doall
   (for [line (line-seq rdr)
 :when (re-matches #^[^,]+,[^,]+,FAIL,.*$ line)]
 (second (string/split line #,)

-- Jean Niklas

-- 
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: fast parallel reduction into hash-set/map

[Jean Niklas L'orange]

Hi Jules,

On Thursday, February 20, 2014 11:59:03 PM UTC+1, Jules wrote:

 Subvec provides a view on a subseq of a vector that behaves like a full 
 vector. Supervec provides a similar view that makes two vectors behave like 
 a single one


This data structure (supervec) is usually known as a rope, and your 
implementation degrades the *~O(1)* to worst case *O(k)* time for lookups, 
assoc, conj and pop, where *k* is the amount of concatenations performed. A 
good rope implementation can reduce that factor down to *O(log k)* through 
balancing, but it will still break the performance guarantees a persistent 
vector is supposed to have. If you try to use this in the reducers library, 
the amount of concatenations fork/join performs might actually show notable 
performance degradation for those operations. Further, passing it around to 
code which might perform more concatenations will lead to even worse 
performance, which may be hard to debug for people not knowing Clojure 
internals.

However, it is a very nice solution if you know there will be limited 
concatenations, that the concatenations result in a balanced tree, and you 
don't pass this vector around to other people. :)

For a small discussion on this vs. RRB-trees, see Section 1.1 in 
http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf.

Hopefully I'm not destroying your fun playing around with these things—that 
is not the intent at all. I'm just saying that these things are (sadly?) 
harder than it first looks like.

-- JN

-- 
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: Latex style file for formatting/coloring clojure code?

[Jean Niklas L'orange]

Hi Mark,

On Monday, February 17, 2014 12:05:24 AM UTC+1, puzzler wrote:

 I am unable to find a style file that supports clojure code in LaTeX.  Can 
 anyone point me in the right direction?


I always use Minted for this kind of stuff: See 
https://code.google.com/p/minted/

It is available in most, if not all, linux distributions. A small example 
for clojure follows:

[...]
\usepackage[section]{minted}

\begin{document}
[...]
\begin{minted}[gobble=2, frame=single}{clj}
  (with-open [reader (- 
META-INF/maven/my-program/my-program/pom.properties
 io/resource
 io/reader)]
(- (doto (java.util.Properties.)
  (.load reader))
(.getProperty version)))
\end{minted}
[...]
\end{document}

Keep in mind that pdflatex has to be invoked with -shell-escape in order to 
allow pygments to be called. If you use latexmk (if you don't know about 
it, check it out!), then you could use the following command stored in a 
shell script or Makefile:

latexmk -pdf -pdflatex='pdflatex -shell-escape %O %S' -pvc $(REPORT).tex

At least it has been immensely useful to me.

-- JN

-- 
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: fast parallel reduction into hash-set/map

[Jean Niklas L'orange]

On Sunday, February 16, 2014 11:49:38 AM UTC+1, Mikera wrote:

 Wow - that's a pretty big win. I think we should try and get this into 
 Clojure ASAP.

 Are we too late for 1.6?


Yeah, this is probably too late for 1.6 =/

Anyway, cool stuff you got going on here. I'm playing around with similar 
functions myself (for a variant of RRB-Trees), but ended up with several 
issues when I attempted to splice trees which shared structure. Is there 
any indication that this will be an issue? An easy way to check this out is 
to generate a large random map/set, then randomly generate maps/sets based 
on the large one by cutting off random elements. Then you randomly splice 
those maps/sets repeatedly, repeat the cutting, and continue with the 
splicing.

-- JN

-- 
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: simple-check gen/boolean Only Returning false

[Jean Niklas L'orange]

On Saturday, January 25, 2014 10:03:13 PM UTC+1, Michael Daines wrote:

 I decided to play with simple-check for the first time and was working 
 through the examples on github. I noticed that all the values that use 
 gen/boolean are returning false. I never get a true.

 At the extreme end, the following never returns when run in the repl:

 (gen/sample (gen/such-that true? (gen/list gen/boolean)))


 I'm using Clojure 1.5.1, simple-check 0.5.5, JVM 1.7.0_51, Ubuntu 13.04.


Yeah, you're correct that this is an error in 0.5.5; I traced down the 
cause and sent in an issue which can be found here: 
https://github.com/reiddraper/simple-check/issues/54.

You can downgrade to simple-check 0.5.3 in the meantime – that version has 
not the bug you encountered.

-- JN

-- 
-- 
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: Auto updating Leiningen dependencies?

[Jean Niklas L'orange]

On Thursday, January 2, 2014 1:28:19 AM UTC+1, g vim wrote:

 Is there are a way to auto-update project.clj dependencies in Leiningen 
 or configure them to simply use the latest stable version?


Instead of using 1.2.3, you can use RELEASE to specify the latest 
stable release. I would never recommend to use this in production or 
libraries, though.
 

 I'm also 
 finding `lein search dep` pretty useless for quickly getting a dep's 
 latest version when it returns 39 pages for clojure itself, starting 
 with the oldest version. 


Yeah, Lein's search functionality is not the best. I looked at the issue 
tracker in Lein, and couldn't find an issue for this, so feel free to add 
in an issue which describes how we can improve 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/groups/opt_out.

Re: Leiningen 2.3.0 and uberjar

[Jean Niklas L'orange]

On Sunday, August 11, 2013 1:18:52 AM UTC+2, Nelson Morris wrote:

 I believe this is https://github.com/technomancy/leiningen/issues/1283.


Yes. As Nelson says, this is 1283.

As a workaround until 2.3.1 is out, downgrade by calling `lein upgrade 
2.2.0` and then use uberjar from there. 

-- JN

-- 
-- 
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: [ANN] Leiningen 2.3.0 released

[Jean Niklas L'orange]

Hey guys,

I've hacked together a temporary fix for people who really, really, really 
want to use 2.3.0 right away, or have broken their lein script and just 
want to solve this the easy way. I would NOT recommend people to upgrade 
right now, just wait until the jar has been set up with the right acl. (I 
would be surprised if that's not the first thing Phil would do in the 
morning.)

If you've not tried to upgrade, do so and get the error message in your 
face: lein upgrade should do the trick. Then go to the directory 
~/.lein/self-installs (or your equivalent directory on Windows). Download 
https://github.com/hyPiRion/leiningen-2.3.0-tempfix/raw/temporary-fix/target/leiningen-2.3.0-standalone.jar
 (wget/curl) 
and save it in the folder. Ensure that it has the name 
leiningen-2.3.0-standalone.jar. That's all you need to do to get 2.3.0 
working.

Again: this is just a temporary fix, and it is packaged by me, not Phil. 
However, it should be equivalent in terms of functionality, and there 
shouldn't be any need to replace the jar once it's downloaded.

I'll remove the repo with the temporary fix once it is possible to download 
the official release once again.

-- Jean Niklas

-- 
-- 
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] Beckon - POSIX signal handling in Clojure

[Jean Niklas L'orange]

Hello Clojurians,

I've released a tiny library for handling POSIX signals named Beckon. You 
can find more information and documentation at 
https://github.com/hyPiRion/beckon: It is not a library aimed to make POSIX 
signals simpler, but to make it easier to work with from Clojure without 
getting your hands dirty with Java.

If you need to handle POSIX signals in your Clojure application and is 
unfamiliar with the JVM/Java way of working with them, you should take a 
look. If you already handle POSIX signals in your Clojure application, this 
library would most likely not give you any mentionable benefits, but it may 
be worth looking at regardless.

A couple of notes if you want to play around with it:

   - nREPL+Emacs doesn't print signal handling stuff in the repl buffer, as 
   signal handling is done in another thread the JVM spawns. Look in the 
   *nrepl-server* buffer instead.
   - `lein repl` and REPL-y-based repls already modify Ctrl-C (SIGINT) and 
   the like, so you will certainly get weird/undefined behaviour if/when using 
   those.


(As POSIX handling isn't usually needed in JVM applications, this is more 
of a *hey, I exist!* than a *hey, you should try me out!*-library.)

-- JN

-- 
-- 
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: with-open and for

[Jean Niklas L'orange]

I haven't seen the use of multiple statements in the for comprehension 
here, so perhaps it's nice to elaborate that this exists?

(defn filter-file [filename]
  (with-open [rdr (io/reader filename)]
(set
 (for [line (line-seq rdr)
   word (str/split line #\s+)
   :when (= 4 (count word) 9)]
   word

I would believe that is one of the more evident ways of writing it. If you 
would like duplicates, replace set with doall.

 -- JN

-- 
-- 
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: [ANN] if-and

[Jean Niklas L'orange]

On Monday, June 10, 2013 10:20:20 PM UTC+2, Steven Degutis wrote:

 Sometimes I've wanted a function that takes a value and a bunch of tests, 
 and returns it if it passes every test, otherwise nil.

 Does this seem useful enough to put into core?

  
A simpler variant already exists in core, named every-pred:

(let [pred (every-pred string? 
   #(.startsWith % f)
   #(.contains % oo))]
  (pred foo))
;;= true

(let [pred (every-pred string?
   #(.startsWith % f)
   #(.contains % NOT IN THE STRING))]
  (pred foo))
;;= false

The main difference being that the function is higher order and independent 
of the input given.

-- JN

-- 
-- 
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: What is the status of Clojure on LLVM or C?

[Jean Niklas L'orange]

On Thursday, May 30, 2013 2:21:36 PM UTC+2, Gary Trakhman wrote:

 I just thought about this recently, but does the value-oriented nature of 
 clojure mostly void the need for a cycles-aware GC?  It seems like you 
 won't ever have cycles without identities, or pointers (java references). 
  Maybe this would be a problem only when you need identities, ie deftype or 
 defprotocol implementing objects.


Sure thing, the value-oriented nature removes a lot of cycles in practice. 
However, you may for instance have an atom which contain itself, so they 
are not nonexistant. As such, the GC cannot be completely cycle-ignorant, 
but perhaps it doesn't have to be efficient at finding them either.

Another place where cycles happen are in (mutually) recursive functions, 
they may be iffy if you define many recursive anonymous functions at 
runtime.

-- Jean Niklas L'orange

-- 
-- 
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: Why is using (not (empty? coll)) not idiomatic?

[Jean Niklas L'orange]

On Saturday, May 11, 2013 11:28:34 PM UTC+2, Sean Corfield wrote:

 you could just write [...]


In some cases, this is even more readable:  

(if-not (empty? foo)
  (do-something-to foo) 
  base-expr)

which has the same effect, but in some cases, having (do-something-to foo) 
first 
may be more readable than having base-expr first.

I'd generally write code as evident as possible. (if-not (empty? x) is a 
recurring pattern as I feel it conveys its purpose better than (if (seq x), 
but I suppose that's preference.

-- JN

-- 
-- 
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: What is the status of Clojure on LLVM or C?

[Jean Niklas L'orange]

On Friday, March 29, 2013 5:04:33 AM UTC+1, tbc++ wrote:

 This is something I've thought/talked about for some time now. In reality 
 this is one of the reasons I started Mjolnir. I would like to see an 
 implementation of Clojure on LLVM. Mjolnir is several months away from 
 being able to handle a project like this, but I took the time tonight to 
 type up my thoughts on the topic. 

 https://github.com/halgari/clojure-metal/blob/master/README.md

 I'd love to hear anyone's input on this doc. I just typed this up, so it's 
 a bit rough, but it should communicate some of the ideas I have.

 Timothy Baldridge


Looks interesting to me, and what you describe is in my eyes a sound 
approach. Seems like you've been thinking about this for some time, esp. 
considering the talk you gave recently. Unfortunately I weren't there, but 
when one gives a talk on this topic, it's evident one has thought a lot 
about it.

What I found lacking was how one should design the Clojure core of 
Clojure-metal. Should one simply convert Clojure as it is right now, or 
should one take into account the lessons learned from creating Clojure? I'm 
sure Rich has some ideas on what should be done differently from what is 
currently done in Clojure right now, though perhaps aimed for the JVM 
implementation, and not in general. (Maybe you talked about this at 
Clojure/West?)

-- Jean Niklas L'orange

-- 
-- 
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: Problem installing Pedestal libraries

[Jean Niklas L'orange]

If you upgrade leiningen to 2.1.1 (`lein upgrade 2.1.1`) , it may be that 
the issue will be resolved as if by magic :)

If you still get some issues, report it at 
https://github.com/technomancy/leiningen or join #leiningen on freenode, 
and we should be able to help you out.

-- JN

-- 
-- 
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: Metadata evaluation

[Jean Niklas L'orange]

On Tuesday, March 19, 2013 9:49:09 AM UTC+1, ajlopez wrote:

 Hi everyone!


Hi!

The easiest thing to find out of this would be to check it out: 

(def ^{:a (+ 1 1)} two 2) 
;= user/two
(meta #'two)
;= { :a 2}

So indeed, the forms within metadata is evaluated.

-- Jean Niklas L'orange

-- 
-- 
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: Metadata evaluation

[Jean Niklas L'orange]

On Tuesday, March 19, 2013 11:49:45 AM UTC+1, ajlopez wrote:

 Thanks Jean!

 Yes, I did that test before my email.

 But my doubt is:

 What part is in charge of metadata evaluation?


As Herwig commented: The part which evaluates metadata is without doubt the 
lisp evaluator's work, the def macro does nothing magical here.

A simple test to ensure that follows:
(meta ^{:a (+ 1 1)} [:a :b])
;= {:a 2}

-- 
-- 
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: Using Leiningen 2.1.0-SNAPSHOT

[Jean Niklas L'orange]

On Saturday, March 16, 2013 1:03:27 AM UTC+1, Michael Klishin wrote:

 To upgrade: pull, compile. Sometimes re-bootstrapping is necessary if
 there were leiningen-core changes.


It's often, if not always, when leiningen-core changes its project.clj map 
(updates dependencies or changes version number). Code changes in 
leiningen-core/src won't need re-bootstrapping as far as I know.

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

Re: problem with dependencies

[Jean Niklas L'orange]

On Wednesday, March 13, 2013 3:17:49 PM UTC+1, Joachim De Beule wrote:

 This gives the following error:

 ClassNotFoundException org.mortbay.log.Logger 
  java.net.URLClassLoader$1.run (URLClassLoader.java:202)

 The problem disappears when I do not include [ring.util.serve]. For some 
 reason that I do not understand. the problem also disappears when I 
 include [org.apache.mahout/mahout-integration 0.7] as a dependency in the 
 project file. Neither of these options is a real solution though, (because 
 I need ring.util.serve and I do not need mahout.integration).

 Any ideas? I'm using lein 2.0 + emacs and nrepl.


Dependency pain. It's smart to do `lein deps :tree`, which should show 
which dependencies you've fetched. In this case it seems like 
[org.mortbay.jetty/jetty 
6.1.22] (and a ton of other stuff) is dragged in by mahout. 
ring.util.serve uses its logger without directly depend on it through 
ring-jetty-adapter. This would have been fine, if it weren't for the fact 
that ring-jetty-adapter changed from mortbay's jetty to eclipse's jetty in 
the recent versions, and that the most recent version of ring uses the 
latest version. And when two versions clash, the highest one is picked 
unless version ranges comes into play.

To fix, just directly depend on mortbay's jetty: the latest stable version 
is 6.1.26, so add in [org.mortbay.jetty/jetty 6.1.26] to your deps. That 
should 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/groups/opt_out.

Re: Proposal/request: Give clojure.core/conj a unary implementation

[Jean Niklas L'orange]

On Sunday, November 4, 2012 12:43:22 AM UTC+1, Ben wrote:

 There might be a reason to write (apply f coll seqable) in a situation 
 in which f might be conj, though. 


One may use (reduce f coll seqable) instead, if that makes sense 
semantically in that context.

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

Re: Parallelising reduce-kv

[Jean Niklas L'orange]

On Tuesday, October 9, 2012 9:14:51 PM UTC+2, Wolodja Wentland wrote:

 --- snip --- 
 (reduce-kv 
  (fn [ret k v] 
   (assoc ret k (func-that-does-something-with v))) 
  some-map)) 
 --- snip -- 

 I am using reducers in other places, but am not entirely sure how to 
 employ 
 them here. I would be grateful for any advice. 


You could use merge as the combine function, and let (fn [ret [k v]] (assoc 
ret k (func-that-does-something-with v))) be the reducing function you pass 
to fold. Then it's at least parallelisable, though I'm unsure of its 
performance.

-- 
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: apply: increase performance by 60% for fixed length

[Jean Niklas L'orange]

On Sunday, October 7, 2012 11:15:28 PM UTC+2, Marc Dzaebel wrote:

 *apply *is slow. However you can increase performance by 60% with the 
 following macro, if you have a fixed length in S. 


 [...]

 (let[t(fn[](*apply   *+ '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
 100] (t ; ~680 msec
 (let[t(fn[](*applyn *10 + '(1 2 3 4 5 6 7 8 9 10)))] (time(dotimes [_ 
 100] (t ; ~220 msec


Interesting, even though it's impractical to use it on an already defined 
list. Usually, I want to work with list or sequences I've generated with 
other functions, like so:

(let[t(fn[](applyn 10 + (range 1 11)))] (time(dotimes [_ 100] (t ; 
~ 950 msec
(let[t(fn[](applyn + (range 1 11)))] (time(dotimes [_ 100] (t ; ~ 
940 msec

(In addition, apply is in this case is not really what you want to do with 
this list - you should use reduce instead.)
(let[t(fn[](reduce + (range 1 11)))] (time(dotimes [_ 100] (t ; ~ 
890 msec

Curiously, if I vec the result, I get a completely different answer:

(let[t(fn[](applyn 10 + (vec (range 1 11] (time(dotimes [_ 100] 
(t ; ~ 1330 msec
(let[t(fn[](apply + (vec (range 1 11] (time(dotimes [_ 100] (t 
; ~ 1410 msec
(let[t(fn[](reduce + (vec (range 1 11] (time(dotimes [_ 100] (t 
; ~ 1340 msec

This is hardly any scientific test though, so I'll leave the conclusion to 
someone with a more rigorous testing scheme.

-- 
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: == is not transitive?

[Jean Niklas L'orange]

On Friday, October 5, 2012 7:17:50 PM UTC+2, Ben wrote:

 I'm not sure what you mean by this. Transitivity means that for all x, 
 y, and z, (Fxy  Fyz) = Fxz. But there are values of x, y, and z for 
 which that does not hold. 


Yeah, sorry. What I meant was that == is only commutative if you pass it 
two arguments as of right now.

-- 
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: == is not transitive?

[Jean Niklas L'orange]

On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote:

 user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] 
 [true true false] 


When passing two arguments to ==, == will be transitive.
 

 user [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0) 
 (== 0.0M 0.0 0) (== 0.0M 0 0.0)] 
 [true false false false true false] 


This is more of a problem with number equality, not the transitivity of ==. 
(== x1 x2 x3 ... xn) can be rewritten as (and (== x1 x2) (== x2 x3) ... (== 
xn-1 xn)). 

So if you compare (== x y z), then if x = y, then the result of (== x z) 
and (== y z) should be equivalent, considering the numbers are, well, 
numbers.

I believe the issue lies within the bigdec-parsing, which seems to have two 
zeroes: (== 0M 0.0M) returns false, and their hashcode (0 and 1, 
respectively) are different.
 

-- 
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: Which power function is right for Clojure?

[Jean Niklas L'orange]

Numeric tower has implemented pow (named expt in the library), so you could 
have a look at their implementation:
https://github.com/clojure/math.numeric-tower/blob/master/src/main/clojure/clojure/math/numeric_tower.clj#L64

(It utilizes exponentiation by squaring to get the running time from O(n) 
to O(log n).)

-- 
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: More Concise or Idiomatic Max Sub-Array?

[Jean Niklas L'orange]

 Is there a more concise implementation, perhaps using `filter` or merely 
 by making the `reduce` version more idiomatic somehow?

 
Another version I believe is more evident utilizes reductions to build a 
list over all the *max-ending-here*s. You can then just pick the maximal 
value in that list, giving you the maximal subarray:

(defn max-subarray [A]
  (let [pos+ (fn [sum x] (if (neg? sum) x (+ sum x)))
ending-heres (reductions pos+ 0 A)]
(reduce max ending-heres)))

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