Re: lazy-seq and threads

[Gerrit Jansen van Vuuren]

Hi,

I do not think it has anything to do with thread sync or jit+gzip as a 
matter of fact.

Why threads aren't the issue:
I've downloaded the code on my machine and the clojure code always run 
slower no matter if I read one or two files, use gzip or not. 
You run the test case using  (future) and for each instance a new 
InputStream+Reader is created which means no inter thread sharing is done.

Why not the jit+gzip:
During my runs the clojure code with or without gzip always run slower than 
the java code.

Issue:
You are not comparing apples with apples. Looking at the Java code you are 
not creating any intermediate List/Seq structure and then counting what is 
in the List/Seq,
this is exactly what the Clojure code is doing, line-seq creates an 
intermediate structure that can never be jitted away.

In the java code you are testing: how fast you can read lines of text, and 
increment a counter.
In the clojure code you are testing: how fast you can read lines for text, 
how fast you can create a Sequence, and how fast can you count elements in 
the Sequence, iterating through that Sequence.

I've written a clojure function that does what the java code does i.e count 
lines at https://gist.github.com/gerritjvv/a9b4ab17f9f4d4b6cdb7 (also 
pasted below) and this runs as fast as the java code.

The clojure code is:
(defn gz-line-counter [^String file-name] (let [^BufferedReader reader (
BufferedReader. (InputStreamReader. (GZIPInputStream. (FileInputStream. 
file-name] (try (loop [i 0] (if (.readLine reader) (recur (inc i)) i)) (
finally (.close reader) 


My suggestion would be that, use line-seq when you are interested in 
treating file lines as a stream of data. 
If you are interested in just counting avoid intermediate data structures.
If you are interested in brute force performance and still need to line 
processing use loop/recur but only after having tried out line-seq first,
allot of times the cost of the intermediate data structure is not 
noticeable when compared to the string processing/reading logic, but this 
depends
on each use case.


On Wednesday, 16 September 2015 07:00:35 UTC+2, Andy L wrote:
>
>
> Hi,
>
> Thanks for looking into my questions. I posted a self contained example 
> here https://github.com/coreasync/parallel-gzip with instructions how to 
> create test data as well. Also attached results below I get on my quite 
> decent hardware (partial 'time' results are mangled, was not sure how to 
> separate them). I use two separate 'lazy-seq', however I heard somewhere, 
> that they are not free even if no synchronization takes place, like in this 
> case but could be optimized out for a single thread situation. Apologies 
> for jumping into conclusion ... Also, I do not believe that we deal with a 
> significant amount of IO as those test files easily fit into O/S buffers.
>
> Two test runs below show, that we can easily take advantage of multiple 
> cores. Java versions scale well. Same in the Clojure code for uncompressed 
> files. In all 3 cases, resulting in JVM taking a stable 200% of CPU, i.e. 
> occupying two cores. Also Java and Clojure time numbers are quite 
> consistent.
>
> However, as soon as I add a GZIPInputStream input stream, Clojure version 
> start pegging 400, 500, 600% of CPU varying over time. I assumed initially, 
> taht effort was spend for some thread synchronization tasks as JIT was not 
> able to factor out due to more code involved. Interestingly enough, YourKit 
> shows only two threads busy interlaced with empty spaces, almost looking 
> like JVM being busy doing some kind of house keeping, hitting CPU really 
> bad. Thread dumps did not reveal anything weird, no locking contention, etc 
> ... I tried Java 7 and 8 as well as Clojure 1.7 and 1.8 - none of make any 
> difference.
>
> Understanding where that limitation comes from is quite critical, as I try 
> to use hardware to the best possible extend.
>
> Thanks in advance for hints and clues ...
> AndyL
>
>
> # create test data
> $curl -o 1 http://norvig.com/big.txt
> $cat 1 1 1 1 1 1 1 1 > 2
> $cat 2 2 2 2 2 2 2 2 > 3
> $cat 3 3 3 3 3 3 3 3 > 4
> $gzip -k 4
> $lein run 4
> starting...
>
> uncompressed
> Java code:
> "Elapsed time: 8258.013802 msecs"
> (65769984)
> "Elapsed time: 8268.641987 msecs"
> Clojure code:
> "Elapsed time: 9117.814135 msecs"
> (65769984)
> "Elapsed time: 9118.270526 msecs"
>
> compressed
> Java code:
> "Elapsed time: 21522.20167 msecs"
> (65769984)
> "Elapsed time: 21522.663463 msecs"
> Clojure code:
> "Elapsed time: 21573.585966 msecs"
> (65769984)
> "Elapsed time: 21574.013417 msecs"
> ...finished
> $ lein run 4 4
> starting...
>
> uncompressed
> Java code:
> ""EEllaappsseedd  ttiimmee::  77226688..0857983348 msec1s "m
> secs"
> (65769984 65769984)
> "Elapsed time: 7280.09169 msecs"
> Clojure code:
> ""EEllaappsseedd  ttiimmee::  9911..113308627362  mmsseeccss""
>
> (65769984 65769984)
> "Elapsed time: 9177.644745 msecs"
>
> compressed
> Java code:
> "Elapsed t

Re: Clojure/Pedestal vs Go

[Josh Kamau]

11.  Leiningen and painless dependency management.

Josh

On Wed, Sep 16, 2015 at 7:08 AM, Michael Gardner 
wrote:

> On Sep 15, 2015, at 20:45, Mikera  wrote:
> >
> > 7. The open source library ecosystem on the JVM is awesome. There's
> nothing like it for any other language.
>
> I like your other points, but in my experience this one is (arguably) no
> longer true. I've often found the JVM library ecosystem to be lacking in
> comparison to Python's, especially for newer problem domains. I'd attribute
> this to Java no longer being a "hip" language, which counts for a lot in
> OSS development!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: lazy-seq and threads

[Gerrit Jansen van Vuuren]

one more thing although its unrelated to the performance differences seen:

The Character encoding specified in the Java code is US-ASCII while the
clojure reader uses UTF-8. Byte to Character encoding can make huge
differences in text processing apps see
http://java-performance.info/charset-encoding-decoding-java-78/.

If you know the encoding or can control what it should be use "ISO-8859-1" the
JDK is optimized for this encoding as it gives a one to one byte copy match.

-- 
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: Using metadata to specify how calls to a macro should be indented

[Artur Malabarba]

Hi Colin, it's great to get your thoughts on this.

2015-09-15 22:52 GMT+01:00 Colin Fleming :

> I think it's important that the declaration of the formatting be separated
> from the declaration of the macro itself. This allows forms which the
> editor developer doesn't control to be annotated, e.g. core. Perhaps
> library owners could produce an EDN doc containing these specs? Or perhaps
> we could obey annotations in the functions themselves, but I think that
> some way to additionally annotate external things is essential.
>
I think it's important that this information be in the metadata. When we're
indenting a form, we only need to resolve the var and we'll have its
metadata. That seems simpler than having to resolve the var and then look
it up in the library's doc or something.

Of course, metadata can be added to a var as a separate declaration, so it
does allow us to annotate external macros as in:

(alter-meta! #'clojure.core/cond assoc :editor/indent 1)

Does that cover your point or did I misunderstand something?


> I also think that Mr Dynamics is correct, we should not go down the path
> of special casing anything, even defn - this is a hard rule that I have in
> Cursive that I only break very occasionally :-). The spec should support
> everything we need to do. It will be difficult, though [...]
>

Yes, I agree now as well.


> There are also many more aspects to formatting that this does not address
> that I think we should think about - line indentation is only one part of
> it. What about breaking lines when they're too long? Aligning subforms like
> let-binding values? Do we want to do anything about those? Cursive can
> handle all of that but doesn't expose the knobs right now. clj-fmt does, I
> believe - I think it can take a single line of pr-str output and produce
> nicely formatted code.
> There are also lots of edge cases that need to be thought through.
> Multi-arity function declarations for letfn, proxy etc come to mind.
> extend-type also supports multiple arity declarations. condp is another
> example of a form with variable numbers of elements per "block" (the :>>
> keyword). for-blocks have internal let blocks, etc etc.
>

Indeed the spec should cover some of this stuff. I'd like the spec to cover
as much as possible, but I also don't want to define something so verbose
and complicated that people just don't bother. So hopefully we can figure
out a way to add some essential features while keeping the complexity in
check.

In particular:

   -

   Handling macros that may take different syntaxes I feel is pretty
   important. This is basically the multi-arity case you mention. The `fn`
   could be invoked as `(fn my-func [] 10)` or as `(fn ([] 10) ([x] (inc
   x)))`, and the indentation is different in these cases.
   -

   Another thing I'd like is a way to indicate that there should be a
   line-break between one symbol/value pair and another in let-bindings. So
   the subforms you mention.
   -

   I would like the spec to say things like "this argument should (or
   should not) be on its own line". But I *don't* think the spec should say
   "break the line if it's longer than N chars".

It's hard to tell how far to go with this. One thing that I'm planning in
> Cursive that I'm not doing currently is also to identify forms which are
> part of a do-body-like-thing. This is very useful for refactoring. This
> might not have a place in a spec that is purely for indentation, but
> definitely would in a more general form structure spec.
>

The safest option here is to not go too far right now, but define the spec
in a way that's extensible, so we can still go as far as we want later.
The spec I proposed initially isn't highly extensible. Can we figure out a
reasonable way to add a few of these features?

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

Re: Using metadata to specify how calls to a macro should be indented

[Artur Malabarba]

2015-09-15 20:08 GMT+01:00 Josh Tilles :

> I suspect that “Matching Socks” meant that there should be a standard
> namespace, similar to how the recent Socket Server REPL design
> 
>  uses
> a “repl” namespace for its magic keywords.
> It seems natural to me to pick a namespace like “editors” or “editing”,
> but alternatives like :display/indentation or :visual/structure also look
> good.
>

Silly me. Yes, that makes perfect sense. :-)

I like :editors. Other options are :style and :format(ting).

-- 
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: Using metadata to specify how calls to a macro should be indented

[Chas Emerick]

Hi all; here to satisfy the quarterly quota to maintain my status as 
"that guy".


This is a questionable proposal. It:

* introduces completely orthogonal, transient concerns (presentation) 
into code, ideally a canonical, long-lived source-of-truth

* sets up a bikeshed at the top of every def* form
* adopts idiosyncratic implementation details of a particular editor's 
language support (the defrecord example's :indent is particularly obtuse 
IMO, even if you are aware of how clojure-mode is implemented)


I *think* I coined the "always two spaces" shorthand for the 
(admittedly, minority) position that list forms should be formatted 
completely regularly, so as to:


* make formatting a trivial operation, not requiring any "real" reading
* eliminate this entire topic

Here's the first time I talked about this IIRC: 
https://groups.google.com/forum/#!msg/clojuredev-users/NzKTeY722-I/3hmNvJulcksJ


Best,

- Chas

On 09/13/2015 06:06 AM, Artur Malabarba wrote:


Hi everyone,


Over at CIDER we're adding a feature where the author of a macro (or 
function) can specify how that macro should be indented by adding an 
|:indent| metadata to its definition. This way the editor (and other 
tools, like cljfmt) will know what's the proper way of indenting any 
macro (even those custom-defined) without having to hardcode a 
bajillion names.


Here's an example of how you specify the indent spec for your macros


|(defmacro with-out-str "[DOCSTRING]" {:indent 0} [& body] ...cut for 
brevity...) (defmacro defrecord "[DOCSTRING]" {:indent [2 nil nil 
[1]]} [name fields & opts+specs] ...cut for brevity) (defmacro 
with-in-str "[DOCSTRING]" {:indent 1} [s & body] ...cut for brevity...) |



We'd like to hear any opinions on the practicality of this (specially 
from authors of other editors).
Below, I'll be saying “macros” all the time, but this applies just the 
same to functions.




*Special arguments*


Many macros have a number of “special” arguments, followed by an 
arbitrary number of “non-special” arguments (sometimes called the 
body). The “non-special” arguments have a small indentation (usually 2 
spaces). These special arguments are usually on the same line as the 
macro name, but, when necessary, they are placed on a separate line 
with additional indentation.


For instance, |defrecord| has two special arguments, and here's how it 
might be indented:


|(defrecord TheNameOfTheRecord [a pretty long argument list] SomeType 
(assoc [_ x] (.assoc pretty x 10))) |



Here's another way one could do it:

|(defrecord TheNameOfTheRecord [a pretty long argument list] SomeType 
(assoc [_ x] (.assoc pretty x 10))) |


/
/

/The point of the indent spec is *not* to specify how many spaces to 
use./



The point is just to say “a defrecord has *2* special arguments”, and 
then let the editor and the user come to an agreement on how many 
spaces they like to use for special and non-special arguments.




*Internal indentation*


The issue goes a bit deeper. Note the last argument in that 
|defrecord|. A regular function call would be internally indented as


|(assoc [_ x] (.assoc pretty x 10)) |

But this is not a regular function call, it's a definition. So we want 
to specify this form internally has 1 special argument (the arglist 
vector), so that it will be indented like this:


|(assoc [_ x] (.assoc pretty x 10)) |

The indent spec we're working on does this as well. It lets you 
specify that, for each argument beyond the 2nd, if it is a form, it 
should be internally indented as if it had 1 special argument.




*The spec*


An indent spec can be:

  * |nil| (or absent), meaning /“indent like a regular function call”/.
  * A vector (or list) meaning that this function/macro takes a number
of special arguments, and then all other arguments are non-special.
  o The first element of this vector is an integer indicating how
many special arguments this function/macro takes.
  o Each following element is an indent spec on its own, and it
applies to the argument on the same position as this element.
So, when that argument is a form, this element specifies how
to indent that form internally (if it's not a form the spec is
irrelevant).
  o If the function/macro has more aguments than the vector has
elements, the last element of the vector applies to all
remaining arguments.
  * If the whole spec is just an integer |n|, that is shorthand for |[n]|.



  *Examples*


So, for instance, if I specify the |defrecord| spec as |[2 nil nil 
[1]]|, this is saying:


  * |defrecord| has 2 special arguments
  * The first two arguments don't get special internal indentation
  * All remaining arguments have an internal indent spec of |[1]|
(which means only the arglist is indented specially).

Another example, |reify| is |[1 nil [1]]| (which should be easy to see 
now).


|(reify Object (toString [this] (something) else "here")) |


For something

Re: Clojure/Pedestal vs Go

[Colin Yates]

12. Community (although I have no idea what Go's community is like to be fair)

And an upgrade to the "full stack" comment is full stack including over the 
wire translation with edn and transmit.

Sent from my iPhone

> On 16 Sep 2015, at 10:02, Josh Kamau  wrote:
> 
> 11.  Leiningen and painless dependency management.  
> 
> Josh
> 
>> On Wed, Sep 16, 2015 at 7:08 AM, Michael Gardner  wrote:
>> On Sep 15, 2015, at 20:45, Mikera  wrote:
>> >
>> > 7. The open source library ecosystem on the JVM is awesome. There's 
>> > nothing like it for any other language.
>> 
>> I like your other points, but in my experience this one is (arguably) no 
>> longer true. I've often found the JVM library ecosystem to be lacking in 
>> comparison to Python's, especially for newer problem domains. I'd attribute 
>> this to Java no longer being a "hip" language, which counts for a lot in OSS 
>> development!
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Vital Labs Jobs

[Ian Eslick]

Vital Labs is a San Francisco based digital health, venture backed startup 
applying cutting edge sensor and data analytics solutions to chronic 
disease.  

We are passionate users of Clojure and Clojurescript and currently everyone 
in our company is a contributing developer.  Our distributed, real-time 
backend is entirely written in Clojure and leverages HazelCast, Cassandra 
and Datomic for all our data management, analytics, and API handling.  Our 
front-end web and mobile applications are based on Om-React plus our own 
little framework Nativestore + Derive 
(https://github.com/VitalLabs/nativestore).  We contribute to open source 
projects and as we scale look forward to dedicating more time to curating 
and releasing our internal projects.

We're currently hiring both front-end and back-end engineers and data 
scientists who know the Python toolkits but are interested in moving 
algorithms to production in Clojure.  We heavily prefer full-time hires in 
San Francisco or the larger Bay Area and are not currently seeking 
contractors.  We have excellent benefits, free organic lunches and are 
located in a hip section of SOMA near public transportation and the UCSF 
Medical Center where we are running our trials.

http://www.vitallabs.com#joinus

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

Re: Clojure/Pedestal vs Go

[Brian Hurt]

I have no flipping clue what "system-level programming" means these days,
and I'm hoping someone could spell it out.  I used to think (back when I
was doing that sort of stuff) that it mean operating systems level stuff-
device drivers, embedded, real time, stuff like that.  But no language with
a GC or non-trivial run time is a good fit for that.  From usage, I now
think it means "we refuse to use Java".

On Tue, Sep 15, 2015 at 11:45 PM, Mikera 
wrote:

> Go is fine for system-level programming, but I personally wouldn't use it
> as a web application programming language. Ten reasons to consider.:
>
> 1. There isn't really much speed difference on micro-benchmarks between
> JVM code and Go. See e.g.:
> http://benchmarksgame.alioth.debian.org/u64q/go.html
>
> 2. In many real-world cases JVM code will outperform Go, see e.g.
> http://zhen.org/blog/go-vs-java-decoding-billions-of-integers-per-second/
>
> 3. The JVM GC is superior to the GC in Go. This makes a big difference for
> complex applications with a lot of live objects on the heap, especially
> when dealing with stuff like immutable persistent data structures (and you
> want to use those, right?). Overall, I'd expect Clojure to easily
> outperform Go for these types of applications.
>
> 4. The JVM startup time / memory overhead is irrelevant for long running
> server applications. If you are restarting the JVM regularly, you are
> definitely doing something wrong. The JVM is well tuned for long-running
> server side web applications in general, rather than the lightweight
> processes / scripts that are more suited to Go.
>
> 5. Functional programming is natural in Clojure and is IMHO the future for
> building modern applications
>
> 6. If you like the CSP stuff (goroutines, channels etc.), Clojure has the
> excellent core.async, which basically lets you do all the nice CSP type
> things in Clojure you can do in Go. However that isn't forced on you:
> Clojure supports a lot of other paradigms for concurrent programming.
> Choose what works best for you.
>
> 7. The open source library ecosystem on the JVM is awesome. There's
> nothing like it for any other language. Even if nobody has written a
> Clojure library that wraps up the functionality you need yet, using Java
> libraries from Clojure is very painless (often easier than using Java
> libraries from Java!)
>
> 8. Virtually all the key big data stuff depends on the JVM. Spark, Hadoop
> ecosystem etc. Being on the JVM is a valuable strategic choice if you are
> into data processing. / analytics.
>
> 9. Clojure has an compelling full stack development story with
> ClojureScript on the browser and Clojure on the server. It's pretty useful
> to be able to share code between the server and the client.
>
> 10. Once you've experienced interactive REPL driven web application
> development with stuff like Figwheel, you probably won't want to go back to
> anything else
>
> On Monday, 14 September 2015 03:44:48 UTC+8, Alan Thompson wrote:
>>
>> Hi,
>>
>> I'm about to start a new web project and they are thinking about using Go
>> (golang) instead of a JVM (preferably Clojure) based approach.  The idea is
>> "BARE METAL SPEED!!!", but I really think the network and DB will be the
>> bottlenecks, not Clojure vs Go.
>>
>> Is anybody out there aware of any speed comparisons using
>> Clojure/Pedestal and/or Go?  I'm thinking basic measurements like
>> connections/sec, latency, simultaneous users, etc.
>>
>> Thanks,
>> Alan
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Bug in DynamicClassLoader?

[András Pálinkás]

Can anyone explain to me why do we call super.findClass here:
https://github.com/clojure/clojure/blob/41af6b24dd5be8bd62dc2b463bc53b55e18cd1e5/src/jvm/clojure/lang/DynamicClassLoader.java#L69

I believe, on this line, instead of super.findClass, it should call 
getParent().findClass, otherwise we'll get to the system classloader almost 
immediately (and the parent classloader will never be used).

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

Re: Clojure on an Erlang-vm-os on Xen?

[juan.facorro]

Hi Frank,

I'm wondering why no one ever posted a question/comment/reponse to this 
thread. Personally I think Clojure is a great language and the Erlang VM is 
a feat of engineering. I would love to think what other think about this 
thoughts and about the possibility of having Clojure on the Erlang VM in 
general.

There are some language features that don't quite map from Clojure to 
Erlang though, which are a challenge to implement. For example it is my 
understanding that all of Clojure abstractions rely either on Java 
interfaces (on the JVM) or on protocols (ClojureScript). So I guess a good 
implementation for the protocol mechanism would be needed for Clojure's 
implementation on the Erlang VM. 

In my head this means:

   1. Values would need to have a type tag, in order to be able to figure 
   out if they do or do not implement a certain protocol.
   2. A possible implementation would be a tuple whose first element is an 
   atom which represents the type (i.e. {type_whatever, ...})
   3. All functions that support this scheme and also the ones that 
   participate in the protocol mechanism need to "wrap/unwrap" values for 
   "type checking". 
   4. Previous points make interop with Erlang more complicated, since 
   Erlang code would need to account for this wrapping & unwrapping. Although 
   there could be a macro that figures some of these things automatically, but 
   it would still not be a seamless Erlang/Clojure interop.

There is also the matter of *namespaces* and *vars*, Clojure's bread and 
butter :P. 

In ClojureScript *namespaces* are not a thing you can manipulate [1] (you 
can't use **ns** for example), which could be a possible workaround to 
avoid maintaining runtime information about namespaces.

*Vars* on the other hand are not reified in ClojureScript [2] (they map to 
regular JavaScript variables). Vars either have a *root value*, are *unbound 
*or (when they are dynamic) might have a *thread bound value*. The first 
two are global state related to a var while the last one is local to each 
process (when talking about the Erlang VM). There are ways of implementing 
this in the Erlang VM, just to name one (which is probably not be the best 
one) using an ETS for global vars state and the process dictionary for the 
processes bindings (maybe implementing something analogous to Clojure's 
frames approach).

Anyways...

These are just a couple of challenges in a possible implementation on the 
Erlang VM, which I think are key.

Cheers!

[1] At least not the last time I checked, although ClojureScript is on its 
way to being self-hosted so, who knows?
[2] The *var* special symbol provides compile time information though in 
ClojureScript.

On Friday, July 13, 2012 at 2:15:18 PM UTC-3, FrankS wrote:
>
> Just became aware of this effort: "http://erlangonxen.org/"; 
>
> which shows off some impressive properties: 
>
> * Startup time of a new instance is 100ms 
> * Instances are provisioned after the request arrival - all requests get 
> handled 
> * No instances are running waiting for requests - the cloud footprint is 
> zero 
> * the size of infrastructure is proportional to the maximum load - 8 
> servers may be enough 
> * … 
>
> All that begs the Q: would Clojure on an Elang-VM be feasible and make 
> sense? 
>
> -FrankS. 
>
>
>

-- 
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: lazy-seq and threads

[Andy L]

Gerrit,

Yes, I do compare apples to oranges, but my orange looks like a nice
Macintosh apple when run in a single thread :-). What I do not expect is
that lack of symmetry in a multiple thread situation and weird JVM CPU
spikes.

WRT to encoding - thanks for the hint - I removed ASCII one from Java
version and it did not make any difference. I also run your version with
lazy-seq replaced with an explicit loop/recur and this weird effect is
gone, making Clojure version performing relatively as well as in a single
thread. Interesting data point. Still lazy-seq does not cause it when
reading file without compression though, as it performs almost as fast as
Java version in a multi threaded context.

Thanks,
Andy


On Wed, Sep 16, 2015 at 2:14 AM, Gerrit Jansen van Vuuren <
gerrit...@gmail.com> wrote:

> one more thing although its unrelated to the performance differences seen:
>
> The Character encoding specified in the Java code is US-ASCII while the
> clojure reader uses UTF-8. Byte to Character encoding can make huge
> differences in text processing apps see
> http://java-performance.info/charset-encoding-decoding-java-78/.
>
> If you know the encoding or can control what it should be use "ISO-8859-1" the
> JDK is optimized for this encoding as it gives a one to one byte copy match.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Clojure Buenos Aires - MeetUp - September, 30th

[juan.facorro]

Hi dear clojurists/clojurers/clojurians,

Since we are having our fourth get together end of September, I wanted to 
announce the existence of the Buenos Aires Clojure MeetUp 
 and invite anyone who 
might be interested in having a good time and talk about Clojure.

Here's the link to the next MeetUp: 
http://www.meetup.com/ClojureBA/events/225180129/.

So if you are currently living in Buenos Aires or visiting, come join us!

Juan Facorro

-- 
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: lazy-seq and threads

[Gerrit Jansen van Vuuren]

I agree with you that the LazySeq+Gzip+2Threads combination causing a spike
is weird.

-- 
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: lazy-seq and threads

[Andy L]

Thanks for the confirmation. I run "jstat" on both cases and it indicates a
lot of GC in Survivor0 bucket, specifically for "LazySeq+Gzip+2Threads" .
New area of learning for me though. That would explain spikes and JVM
pauses.

Best regards,
Andy

On Wed, Sep 16, 2015 at 9:41 AM, Gerrit Jansen van Vuuren <
gerrit...@gmail.com> wrote:

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

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

Re: lazy-seq and threads

[Andy L]

Would like to confirm that adding "-XX:+UseSerialGC" cured all the
symptoms. In fact Clojure version with loop/recur runs faster than Java
now. I will update the GitHub repo with all findings later.

Again, thanks for all points and hints. I feel enriched now.

Best regards,
AndyL


On Wed, Sep 16, 2015 at 10:39 AM, Andy L  wrote:

> Thanks for the confirmation. I run "jstat" on both cases and it indicates
> a lot of GC in Survivor0 bucket, specifically for "LazySeq+Gzip+2Threads" .
> New area of learning for me though. That would explain spikes and JVM
> pauses.
>
> Best regards,
> Andy
>
> On Wed, Sep 16, 2015 at 9:41 AM, Gerrit Jansen van Vuuren <
> gerrit...@gmail.com> wrote:
>
>>
>> I agree with you that the LazySeq+Gzip+2Threads combination causing a
>> spike is weird.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[ANN] clojure.java.jdbc 0.4.2 released

[Sean Corfield]

What?
Clojure Contrib JDBC wrapper

https://github.com/clojure/java.jdbc#change-log

Release 0.4.2 on 2015-09-15
Remove redundant type hints JDBC-113 - Michael Blume.
Avoid reflection on .prepareStatement JDBC-112 - Michael Blume.
Add metadata-query macro to make metadata query / results easier to work with 
for JDBC-107.
prepare-statement :return-keys may now be a vector of (auto-generated) column 
names to return, in addition to just being truthy or falsey. This allows keys 
to be returned for more databases. JDBC-104.
Officially support H2 (and test against it) to support JDBC-91 and clarify 
docstrings to improve debugging driver-specific restrictions on SQL.
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)


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

Tools comparable to Luigi for Clojure or the JVM?

[Max Countryman]

Hi,

I’m working on a project at work for which we’re currently considering a Python 
tool built by Spotify called Luigi[1]. Luigi is a tool for building data 
processing pipelines (hence the name). It’s capable of connecting to various 
processors such as Hadoop and is limited in scope to building and managing 
these pipelines as a directed graph. I’m curious if there are similar tools for 
the JVM we should be taking into consideration? (Certainly a big plus if it’s 
Clojure, from my perspective.) Note that we’re processing a relatively small 
amount of data: at this point we’re just taking in some server logs and doing 
post-processing over them to build aggregates of certain statistics.

Thanks,


Max

[1] https://github.com/spotify/luigi

-- 
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: Oxford (UK) Clojure Group

[Jony Hudson]

You might ping Frank Wood who runs a research group in the engineering 
department at Oxford. I know they use Clojure heavily for their Anglican 
probabilistic programming system.

http://www.robots.ox.ac.uk/~fwood/


Jony


On Tuesday, 15 September 2015 22:04:49 UTC+1, Kévin Etienne wrote:
>
> Hi,
>
> I've seen a previous thread 
> https://groups.google.com/forum/#!topic/clojure/dRPF8bEpjBE
> where a Clojure group in Oxford was mentioned. I don't know what happened 
> to Oxjure but
> I'm interested in running a group and meeting people around Clojure and 
> more extensively
> LISP. I've been to a Clojure in London and really enjoyed a few years ago.
>
> Let me know if you're around and if want to meet. At the moment I'm trying 
> to see if there's
> enough traction and see what we can do.
>
> Thanks,
> Kevin 
>

-- 
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: Tools comparable to Luigi for Clojure or the JVM?

[Ben Mabey]

Drake is similar to what you want and it is written in Clojure: 
https://github.com/Factual/drake


-Ben

On 9/16/15 12:12 PM, Max Countryman wrote:

Hi,

I’m working on a project at work for which we’re currently considering a Python 
tool built by Spotify called Luigi[1]. Luigi is a tool for building data 
processing pipelines (hence the name). It’s capable of connecting to various 
processors such as Hadoop and is limited in scope to building and managing 
these pipelines as a directed graph. I’m curious if there are similar tools for 
the JVM we should be taking into consideration? (Certainly a big plus if it’s 
Clojure, from my perspective.) Note that we’re processing a relatively small 
amount of data: at this point we’re just taking in some server logs and doing 
post-processing over them to build aggregates of certain statistics.

Thanks,


Max

[1] https://github.com/spotify/luigi



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

Uberjar aborting because jar failed: error in opening zip file

[Lawrence Krubner]

My co-worker is building a library in Java. He sent it to me. I downloaded 
and installed it with the help of the Leiningen plugin "localrepo". But now 
if I do: 

lein uberjar

I get: 

Uberjar aborting because jar failed: error in opening zip file

I am not sure how I debug this. The error message doesn't tell me much 
about what the problem might be. 

It is a very large file: 655 megs. 

How can I dig deeper to find the problem? 

-- 
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: Uberjar aborting because jar failed: error in opening zip file

[Lawrence Krubner]

Nevermind. I downloaded a new copy and went through the whole process again 
and everything worked. 


On Wednesday, September 16, 2015 at 4:55:33 PM UTC-4, Lawrence Krubner 
wrote:
>
> My co-worker is building a library in Java. He sent it to me. I downloaded 
> and installed it with the help of the Leiningen plugin "localrepo". But now 
> if I do: 
>
> lein uberjar
>
> I get: 
>
> Uberjar aborting because jar failed: error in opening zip file
>
> I am not sure how I debug this. The error message doesn't tell me much 
> about what the problem might be. 
>
> It is a very large file: 655 megs. 
>
> How can I dig deeper to find the problem? 
>
>

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

Re: [ClojureScript] Erlang-inspired error handling for core.async

[Christian Weilbach]

Hey Moe,

> 
>>
>> into and pipe should probably be safe.
> 
> 
> I was thinking of a case where a function is returning the equivalent of:
> 
> (async/onto-chan ... [1 2 (Exception.)])
> 
> And the consumer wants to async/into [], obscuring the error from  looks like you've defined < 
> I have some distantly related code here:
> https://github.com/nervous-systems/glossop/blob/master/src/glossop/util.cljc -
> keyed-merge (when used with a/into {}) is a slightly different approach to
>  
> Can you find constructs/cases I am missing?
>>
> 
> I haven't taken everything in, though I think it'd be great if your channel
> operations were usable outside of the context of a supervisor, so pieces of
> the approach could be considered/adopted without going all-in.

Since I have to track all exceptions, you need to have a *super*
supervisor binding for the code to work (and you will later want to have
it in production setups to catch problems slipped out of explicit
supervision scope). I provide now a default supervisor, which for now
printlns errors to stdout so you can see them in the REPL (which is imo
also better than core.async printing stacktraces to stdout of the
nrepl-server through the thread pool).
Is this not modular enough for you? As long as you don't use supervisor
code and have no stale errors you will not hear from the default
supervisor and can minimally use go-try with 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: cider-error go to line

[James Elliott]

W00t, look at what just was released! :D

https://github.com/clojure/tools.nrepl/commit/64238a10a8465e0c590acb660ec5d54bf7cc3af4

On Friday, July 3, 2015 at 1:59:23 PM UTC-5, Ritchie Cai wrote:
>
> Ah, ha, good to know I'm not crazy. For sure I'm join the voices to push 
> the changes on nrepl side.
>
> Thanks
>
> On Friday, July 3, 2015 at 12:52:20 AM UTC-5, Bozhidar Batsov wrote:
>>
>> This is a problem on nREPL, not CIDER. See 
>> http://dev.clojure.org/jira/browse/NREPL-59 for details.
>>
>> There aren't any real solutions to this, other than fixing nREPL, but 
>> we're considering some workarounds (e.g. trying to find the definition 
>> using a regular expression and using the relative position from there) 
>> https://github.com/clojure-emacs/cider/issues/1175
>>
>> But as I said NREPL-59 has to be fixed eventually, as this is killing us 
>> (and everyone using nREPL), so consider dropping by the issue and voicing 
>> your support for the proposed patch. 
>>
>> On 3 July 2015 at 02:44, Ritchie Cai  wrote:
>>
>>> When I get a cider-error, it tells me line number within the function 
>>> that raised the error, but is there an easy way to go to that line?
>>> Since the line number is within the function, I've been counting lines 
>>> manually at the moment ... getting tired of this.
>>>
>>> Anyone has any suggestions?
>>>
>>> Thanks
>>> Ritchie
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: cider-error go to line

[Ritchie Cai]

It’s a beautiful day~~~!!

> On Sep 16, 2015, at 5:42 PM, James Elliott  wrote:
> 
> W00t, look at what just was released! :D
> 
> https://github.com/clojure/tools.nrepl/commit/64238a10a8465e0c590acb660ec5d54bf7cc3af4
> 
> On Friday, July 3, 2015 at 1:59:23 PM UTC-5, Ritchie Cai wrote:
> Ah, ha, good to know I'm not crazy. For sure I'm join the voices to push the 
> changes on nrepl side.
> 
> Thanks
> 
> On Friday, July 3, 2015 at 12:52:20 AM UTC-5, Bozhidar Batsov wrote:
> This is a problem on nREPL, not CIDER. See 
> http://dev.clojure.org/jira/browse/NREPL-59 
>  for details.
> 
> There aren't any real solutions to this, other than fixing nREPL, but we're 
> considering some workarounds (e.g. trying to find the definition using a 
> regular expression and using the relative position from there) 
> https://github.com/clojure-emacs/cider/issues/1175 
> 
> 
> But as I said NREPL-59 has to be fixed eventually, as this is killing us (and 
> everyone using nREPL), so consider dropping by the issue and voicing your 
> support for the proposed patch. 
> 
> On 3 July 2015 at 02:44, Ritchie Cai > wrote:
> When I get a cider-error, it tells me line number within the function that 
> raised the error, but is there an easy way to go to that line?
> Since the line number is within the function, I've been counting lines 
> manually at the moment ... getting tired of this.
> 
> Anyone has any suggestions?
> 
> Thanks
> Ritchie
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com <>
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com <>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com <>.
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/A2WNvMqkwSU/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: Bug in DynamicClassLoader?

[dennis zhuang]

I don't think it's a bug. Indeed, the class loader will invoke loadClass,
and the loadClass method will checking the parent class loader for the
requested class, if it is not found,then invoke findClass of current class
loader implementation to find the requested class as describe in loadClass
javadoc

.

The DynamicClassLoader extends the URLClassLoader, and wraps a class cache
for it.

Also see the javadoc of findClass:

protected Class

findClass(String

name)
  throws ClassNotFoundException


Finds the class with the specified binary name
.
This method should be overridden by class loader implementations that
follow the delegation model for loading classes, and will be invoked by the
loadClass

method
*after checking the parent class loader for the requested class*. The
default implementation throws a ClassNotFoundException.

2015-09-16 21:23 GMT+08:00 András Pálinkás :

> Can anyone explain to me why do we call super.findClass here:
>
> https://github.com/clojure/clojure/blob/41af6b24dd5be8bd62dc2b463bc53b55e18cd1e5/src/jvm/clojure/lang/DynamicClassLoader.java#L69
>
> I believe, on this line, instead of super.findClass, it should call
> getParent().findClass, otherwise we'll get to the system classloader almost
> immediately (and the parent classloader will never be used).
>
> --
> 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.
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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

Tools comparable to Luigi for Clojure or the JVM?

[Christopher Small]

Check out prismatic's plumbing. Its a reall y lovely tool that among other 
things let's you create directed graph structures representing computational 
pipelines, and then compile them into callable functions. It's has different 
compilers for profiling, lazy evaluation, parallelized computation and eager 
seqiential processing. I don't know that anyone has done it, but it should be 
possible to compile down to something distributed if needed. I've been 
interested in compiling to onyx actually. 

Best

Chris

Disclaimer: Written on cell phone

-- 
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: Using metadata to specify how calls to a macro should be indented

[Colin Fleming]

Unfortunately as tools developers we can't force our indentation
preferences on our users, although I'd be fine with it if you convinced
everyone to just use two spaces for everything, even though it's not my
preferred formatting. Cursive has supported this for ages (copied from
Emacs) but I don't know how many people actually use it.

As above, I agree that this shouldn't be in the code.

I also agree very strongly that this shouldn't just adopt whatever Emacs
does for formatting. The one-space indent for list forms, in particular,
drives me nuts and is purely an implementation detail, not because that
makes any sort of sense for code.

You're right that the format spec is pretty obtuse, although we have far
worse out there (the pprint format, ahem). Separating the format spec out
into a separate doc would allow something more verbose to be used which
could be more expressive.

On 16 September 2015 at 23:34, Chas Emerick  wrote:

> Hi all; here to satisfy the quarterly quota to maintain my status as "that
> guy".
>
> This is a questionable proposal. It:
>
> * introduces completely orthogonal, transient concerns (presentation) into
> code, ideally a canonical, long-lived source-of-truth
> * sets up a bikeshed at the top of every def* form
> * adopts idiosyncratic implementation details of a particular editor's
> language support (the defrecord example's :indent is particularly obtuse
> IMO, even if you are aware of how clojure-mode is implemented)
>
> I *think* I coined the "always two spaces" shorthand for the (admittedly,
> minority) position that list forms should be formatted completely
> regularly, so as to:
>
> * make formatting a trivial operation, not requiring any "real" reading
> * eliminate this entire topic
>
> Here's the first time I talked about this IIRC:
> https://groups.google.com/forum/#!msg/clojuredev-users/NzKTeY722-I/3hmNvJulcksJ
>
> Best,
>
> - Chas
>
>
> On 09/13/2015 06:06 AM, Artur Malabarba wrote:
>
> Hi everyone,
>
>
> Over at CIDER we're adding a feature where the author of a macro (or
> function) can specify how that macro should be indented by adding an
> :indent metadata to its definition. This way the editor (and other tools,
> like cljfmt) will know what's the proper way of indenting any macro (even
> those custom-defined) without having to hardcode a bajillion names.
>
> Here's an example of how you specify the indent spec for your macros
>
>
> (defmacro with-out-str
>   "[DOCSTRING]"
>   {:indent 0}
>   [& body]
>   ...cut for brevity...)
>
> (defmacro defrecord
>   "[DOCSTRING]"
>   {:indent [2 nil nil [1]]}
>   [name fields & opts+specs]
>   ...cut for brevity)
>
> (defmacro with-in-str
>   "[DOCSTRING]"
>   {:indent 1}
>   [s & body]
>   ...cut for brevity...)
>
>
> We'd like to hear any opinions on the practicality of this (specially from
> authors of other editors).
> Below, I'll be saying “macros” all the time, but this applies just the
> same to functions.
>
> *Special arguments*
>
>
> Many macros have a number of “special” arguments, followed by an arbitrary
> number of “non-special” arguments (sometimes called the body). The
> “non-special” arguments have a small indentation (usually 2 spaces). These
> special arguments are usually on the same line as the macro name, but, when
> necessary, they are placed on a separate line with additional indentation.
>
> For instance, defrecord has two special arguments, and here's how it
> might be indented:
>
>
> (defrecord TheNameOfTheRecord
> [a pretty long argument list]
>   SomeType
>   (assoc [_ x]
> (.assoc pretty x 10)))
>
>
> Here's another way one could do it:
>
>
> (defrecord TheNameOfTheRecord
>[a pretty long argument list]
>   SomeType
>   (assoc [_ x]
> (.assoc pretty x 10)))
>
>
> *The point of the indent spec is not to specify how many spaces to use.*
>
>
> The point is just to say “a defrecord has *2* special arguments”, and
> then let the editor and the user come to an agreement on how many spaces
> they like to use for special and non-special arguments.
>
> *Internal indentation*
>
>
> The issue goes a bit deeper. Note the last argument in that defrecord. A
> regular function call would be internally indented as
>
> (assoc [_ x]
>(.assoc pretty x 10))
>
> But this is not a regular function call, it's a definition. So we want to
> specify this form internally has 1 special argument (the arglist vector),
> so that it will be indented like this:
>
> (assoc [_ x]
>   (.assoc pretty x 10))
>
> The indent spec we're working on does this as well. It lets you specify
> that, for each argument beyond the 2nd, if it is a form, it should be
> internally indented as if it had 1 special argument.
>
> *The spec*
>
>
> An indent spec can be:
>
>- nil (or absent), meaning *“indent like a regular function call”*.
>- A vector (or list) meaning that this function/macro takes a number
>of special arguments, and then all other arguments are non-special.
>   - The first element of t

Re: Using metadata to specify how calls to a macro should be indented

[Bozhidar Batsov]

I'm kind of puzzled by the last couple of responses. Obviously very few
forms (probably only macros) would have indentation specifications and
editors can certainly disregard them, so I don't see the code being
littered with indentation specs any time soon or some indentation being
forced on everyone.

This idea is not something new - in Emacs Lisp there's a way to specify the
indentation of a macro form which is pretty similar (via `declare`). Maybe
there was something similar for CL as well, but right now I'm not 100% sure.

As for things like the one-space indent, I'm not sure how related they are
to Emacs's prominence in the Lisp world. It sounds more plausible that such
conventions were established before the age of `lisp-mode`.

On 17 September 2015 at 08:31, Colin Fleming 
wrote:

> Unfortunately as tools developers we can't force our indentation
> preferences on our users, although I'd be fine with it if you convinced
> everyone to just use two spaces for everything, even though it's not my
> preferred formatting. Cursive has supported this for ages (copied from
> Emacs) but I don't know how many people actually use it.
>
> As above, I agree that this shouldn't be in the code.
>
> I also agree very strongly that this shouldn't just adopt whatever Emacs
> does for formatting. The one-space indent for list forms, in particular,
> drives me nuts and is purely an implementation detail, not because that
> makes any sort of sense for code.
>
> You're right that the format spec is pretty obtuse, although we have far
> worse out there (the pprint format, ahem). Separating the format spec out
> into a separate doc would allow something more verbose to be used which
> could be more expressive.
>
> On 16 September 2015 at 23:34, Chas Emerick  wrote:
>
>> Hi all; here to satisfy the quarterly quota to maintain my status as
>> "that guy".
>>
>> This is a questionable proposal. It:
>>
>> * introduces completely orthogonal, transient concerns (presentation)
>> into code, ideally a canonical, long-lived source-of-truth
>> * sets up a bikeshed at the top of every def* form
>> * adopts idiosyncratic implementation details of a particular editor's
>> language support (the defrecord example's :indent is particularly obtuse
>> IMO, even if you are aware of how clojure-mode is implemented)
>>
>> I *think* I coined the "always two spaces" shorthand for the (admittedly,
>> minority) position that list forms should be formatted completely
>> regularly, so as to:
>>
>> * make formatting a trivial operation, not requiring any "real" reading
>> * eliminate this entire topic
>>
>> Here's the first time I talked about this IIRC:
>> https://groups.google.com/forum/#!msg/clojuredev-users/NzKTeY722-I/3hmNvJulcksJ
>>
>> Best,
>>
>> - Chas
>>
>>
>> On 09/13/2015 06:06 AM, Artur Malabarba wrote:
>>
>> Hi everyone,
>>
>>
>> Over at CIDER we're adding a feature where the author of a macro (or
>> function) can specify how that macro should be indented by adding an
>> :indent metadata to its definition. This way the editor (and other
>> tools, like cljfmt) will know what's the proper way of indenting any macro
>> (even those custom-defined) without having to hardcode a bajillion names.
>>
>> Here's an example of how you specify the indent spec for your macros
>>
>>
>> (defmacro with-out-str
>>   "[DOCSTRING]"
>>   {:indent 0}
>>   [& body]
>>   ...cut for brevity...)
>>
>> (defmacro defrecord
>>   "[DOCSTRING]"
>>   {:indent [2 nil nil [1]]}
>>   [name fields & opts+specs]
>>   ...cut for brevity)
>>
>> (defmacro with-in-str
>>   "[DOCSTRING]"
>>   {:indent 1}
>>   [s & body]
>>   ...cut for brevity...)
>>
>>
>> We'd like to hear any opinions on the practicality of this (specially
>> from authors of other editors).
>> Below, I'll be saying “macros” all the time, but this applies just the
>> same to functions.
>>
>> *Special arguments*
>>
>>
>> Many macros have a number of “special” arguments, followed by an
>> arbitrary number of “non-special” arguments (sometimes called the body).
>> The “non-special” arguments have a small indentation (usually 2 spaces).
>> These special arguments are usually on the same line as the macro name,
>> but, when necessary, they are placed on a separate line with additional
>> indentation.
>>
>> For instance, defrecord has two special arguments, and here's how it
>> might be indented:
>>
>>
>> (defrecord TheNameOfTheRecord
>> [a pretty long argument list]
>>   SomeType
>>   (assoc [_ x]
>> (.assoc pretty x 10)))
>>
>>
>> Here's another way one could do it:
>>
>>
>> (defrecord TheNameOfTheRecord
>>[a pretty long argument list]
>>   SomeType
>>   (assoc [_ x]
>> (.assoc pretty x 10)))
>>
>>
>> *The point of the indent spec is not to specify how many spaces to use.*
>>
>>
>> The point is just to say “a defrecord has *2* special arguments”, and
>> then let the editor and the user come to an agreement on how many spaces
>> they like to use for special and non-special arguments.
>>
>> *Inte