Re: Poor parallelization performance across 18 cores (but not 4)

[Herwig Hochleitner]

This reminds me of another thread, where performance issues related to
concurrent allocation were explored in depth:
https://groups.google.com/d/topic/clojure/48W2eff3caU/discussion
The main takeaway for me was, that Hotspot will slow down pretty
dramatically, as soon as there are two threads allocating.

Could you try:

a) how performance develops, when you take out the allocation (assoc)
b) if increasing Hotspot's TLAB size will make any difference?
​

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

Re: Any plan to add log4j 2 support to tools.logging?

[William la Forge]

See https://logging.apache.org/log4j/2.x/maven-artifacts.html#SLF4J_Bridge

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

Re: Any plan to add log4j 2 support to tools.logging?

[William la Forge]

log4j2: While the Log4j 2 API will provide the best performance, Log4j 2 
provides support for the SLF4J and Commons Logging APIs.

Doesn't this mean that log4j 2 now works directly with tools.logging 
without having to go via slf4j-log4j12?

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

Any plan to add log4j 2 support to tools.logging?

[Didier A.]

Hi all,

I was wondering if any work is being planned on tools.logging to add log4j 
2 support?

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

Re: Any plan to add log4j 2 support to tools.logging?

[William la Forge]

You mean something besides this?


[org.clojure/tools.logging "0.3.1"]
[org.slf4j/slf4j-log4j12 "1.7.1"]
[log4j/log4j "1.2.17" :exclusions [javax.mail/mail
   javax.jms/jms
   com.sun.jmdk/jmxtools
   com.sun.jmx/jmxri]]

-- 
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: Poor parallelization performance across 18 cores (but not 4)

[Andy Fingerhut]

David:

No new suggestions to add right now.  Herwig's suggestion that it could be
the Java allocator has some evidence for it given your results.  I'm not
sure whether this StackOverflow Q on TLAB is fully accurate, but it may
provide some useful info:

http://stackoverflow.com/questions/26351243/allocations-in-new-tlab-vs-allocations-outside-tlab

I mainly wanted to give you a virtual high-five, kudos, and thank-you
thank-you thank-you thank-you thank-you for taking the time to run these
experiments.  Similar performance issues with many threads in the same JVM
on a many-core machine have come up before in the past, and so far I don't
know if anyone has gotten to the bottom of it yet.

Andy


On Wed, Nov 18, 2015 at 10:36 PM, David Iba  wrote:

> OK, have a few updates to report:
>
>- Oracle vs OpenJDK did not make a difference
>- Whenever I run N>1 threads calling any of these functions with
>swap/vswap, there is some overhead compared to running 18 separate
>single-run processes in parallel.  This overhead seems to increase as N
>increases.
>- For both swap and vswap, the function timings from running 18
>   futures (from one JVM) show about 1.5X the time from running 18 separate
>   JVM processes.
>   - For the swap version (f2), very often a few of the calls would go
>   rogue and take around 3X the time of the others.
>  - this did not happen for the vswap version of f2.
>   - Running 9 processes with 2 f2-calling threads each was maybe 4%
>slower than 18 processes of 1.
>- Running 4 processes with 4 f2-calling threads each was mostly the
>same speed as the 18x1, but there were a couple of those rogue threads that
>took 2-3X the time of the others.
>
> Any ideas?
>
> On Thursday, November 19, 2015 at 1:08:14 AM UTC+9, David Iba wrote:
>>
>> No worries.  Thanks, I'll give that a try as well!
>>
>> On Thursday, November 19, 2015 at 1:04:04 AM UTC+9, tbc++ wrote:
>>>
>>> Oh, then I completely mis-understood the problem at hand here. If that's
>>> the case then do the following:
>>>
>>> Change "atom" to "volatile!" and "swap!" to "vswap!". See if that
>>> changes anything.
>>>
>>> Timothy
>>>
>>>
>>> On Wed, Nov 18, 2015 at 9:00 AM, David Iba  wrote:
>>>
 Timothy:  Each thread (call of f2) creates its own "local" atom, so I
 don't think there should be any swap retries.

 Gianluca:  Good idea!  I've only tried OpenJDK, but I will look into
 trying Oracle and report back.

 Andy:  jvisualvm was showing pretty much all of the memory allocated in
 the eden space and a little in the first survivor (no major/full GC's), and
 total GC Time was very minimal.

 I'm in the middle of running some more tests and will report back when
 I get a chance today or tomorrow.  Thanks for all the feedback on this!

 On Thursday, November 19, 2015 at 12:38:55 AM UTC+9, tbc++ wrote:
>
> This sort of code is somewhat the worst case situation for atoms (or
> really for CAS). Clojure's swap! is based off the "compare-and-swap" or 
> CAS
> operation that most x86 CPUs have as an instruction. If we expand swap! it
> looks something like this:
>
> (loop [old-val @x*]
>   (let [new-val (assoc old-val :k i)]
> (if (compare-and-swap x* old-val new-val)
>new-val
>(recur @x*)))
>
> Compare-and-swap can be defined as "updates the content of the
> reference to new-val only if the current value of the reference is equal 
> to
> the old-val).
>
> So in essence, only one core can be modifying the contents of an atom
> at a time, if the atom is modified during the execution of the swap! call,
> then swap! will continue to re-run your function until it's able to update
> the atom without it being modified during the function's execution.
>
> So let's say you have some super long task that you need to integrate
> into a ref, he's one way to do it, but probably not the best:
>
> (let [a (atom 0)]
>   (dotimes [x 18]
> (future
> (swap! a long-operation-on-score some-param
>
>
> In this case long-operation-on-score will need to be re-run every time
> a thread modifies the atom. However if our function only needs the state 
> of
> the ref to add to it, then we can do something like this instead:
>
> (let [a (atom 0)]
>   (dotimes [x 18]
> (future
> (let [score (long-operation-on-score some-param)
>   (swap! a + score)
>
> Now we only have a simple addition inside the swap! and we will have
> less contention between the CPUs because they will most likely be spending
> more time inside 'long-operation-on-score' instead of inside the swap.
>
> *TL;DR*: do as little work as possible inside swap! the more you have
> inside swap! the higher 

Re: [ANN] pex, a powerful PEG parsing library

[Colin Fleming]

I'm really impressed by how fast it is out of the box with basically no
optimisations. Tatu Saloranta is fanatical about Jackson performance,
getting to within 6x on the first attempt is very promising.

On 20 November 2015 at 02:43, Ghadi Shayban  wrote:

> Thanks for taking a look.
>
> User-level bytecode allows me an easier choice to build a JIT or tracing
> infrastructure, while being far less complex than writing out JVM bytecode
> during grammar compile.
>
> Christophe has certainly been a help offline with design choices.  I
> wanted PEG, no ambiguity, unlike instaparse or parsnip.  Most of the API
> inspiration was from LPEG & Scala's Parboiled2.  Some of the VM internals
> are close to JRuby's Joni regex engine.
>
>
>
> On Thursday, November 19, 2015 at 8:24:37 AM UTC-5, bernardH wrote:
>>
>> This is interesting !
>> It reminds me of Parsnip from C.Grand [0], have you considered it when
>> desining pex ? As your parser is focusing of characters, I am wondering :
>> could the operations triggered by the execution of your pex code be simple
>> enough to warrant actual compiling to JVM bytecode (at run time, with ASM
>> [1]) for maximum performance ?
>>
>> Best Regards,
>>
>> Bernard
>>
>> [0] https://github.com/cgrand/parsnip/
>> [1] http://asm.ow2.org/
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Any plan to add log4j 2 support to tools.logging?

[William la Forge]

Got it working with aatree. Here's my dependencies:

[org.clojure/tools.logging "0.3.1"]
[org.apache.logging.log4j/log4j-core "2.4.1"]
[org.apache.logging.log4j/log4j-api "2.4.1"]
[org.apache.logging.log4j/log4j-slf4j-impl "2.4.1"]


Bill

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

Re: Any plan to add log4j 2 support to tools.logging?

[William la Forge]

Interesting. The log4j-api is not needed. log4j-slf4j-impl directly 
interfaces with log4j-core.

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

Blog post on Cider

[Miguel Ping]

Hi guys,

As promised here's my intro on 
emacs/cider: http://mping.github.io/2015/11/17/clojure-emacs-cider.html

Thanks to everyone that pointed me the way 
at https://groups.google.com/forum/#!topic/clojure/E1FHI_RIWp8

Please feel free to send comments, corrections or whatever.

-- 
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: Data visualization workshops post-mortem

[Raoul Duke]

Wow, thank you for sharing the info! Cool.

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

Re: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

I don't think CLJ-1845  had
the intended effect.

user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f
args
#object[user$eval1241$fn__1242$fn__1243 0x1c857e6
"user$eval1241$fn__1242$fn__1243@1c857e6"]
user=> (load)
"patched"
nil
user=> (require 'clojure.core :reload)
nil
user=> (require 'clojure.tools.analyzer :reload)
nil
user=> (require 'clojure.tools.analyzer :reload-all)
nil

I was expected "patched" to be printed with each call to `load` via
`require`.

Do others observe this also?

Thanks,
Ambrose


On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller  wrote:

> Clojure 1.8.0-RC2 is now available. *This build is a "release candidate"!* We
> would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems.
>
> Try it via
>
>- Download:
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
>- Leiningen: [org.clojure/clojure "1.8.0-RC2"]
>
> Below are the changes since 1.8.0-RC1. See the full 1.8 change log here:
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1846  Fix
>VerifyError when primitive type hints are incorrect. These cases now throw
>compiler errors.
>   - Example: (defn foo ^long [] 1)  (Integer/bitCount ^int (foo))
>   - In this example, foo returns a long but is type hinted
>   (incorrectly) as an int. This case will now throw a compilation error. 
> The
>   correct way to do this is with a cast:  (Integer/bitCount (int
>   (foo)))
>- CLJ-1825  Fix
>compilation errors on direct linking of anonymous recursive functions
>
> --
> 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] lein-virgil, a plugin for mixed Clojure/Java development

[Mike Rodriguez]

Nice! I'm excited to try this one out. Good idea. 

-- 
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] Okku 0.1.5 - Akka from Clojure

[Gary Verhaegen]

Okku, the Clojure (thin) wrapper for Akka.

Github: https://github.com/gaverhae/okku
Leiningen: [org.clojure.gaverhae/okku "0.1.5"]

New in this release:

* Updated Akka dependency to 2.3.14
* Updated Clojure dependency to 1.7.0
* Support for Akka's ask pattern

Thanks go to David Orme for this release.

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

Re: [ANN] pex, a powerful PEG parsing library

[bernardH]

This is interesting !
It reminds me of Parsnip from C.Grand [0], have you considered it when 
desining pex ? As your parser is focusing of characters, I am wondering : 
could the operations triggered by the execution of your pex code be simple 
enough to warrant actual compiling to JVM bytecode (at run time, with ASM 
[1]) for maximum performance ?

Best Regards,

Bernard

[0] https://github.com/cgrand/parsnip/
[1] http://asm.ow2.org/

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

Re: Poor parallelization performance across 18 cores (but not 4)

[Fluid Dynamics]

On Thursday, November 19, 2015 at 1:36:59 AM UTC-5, David Iba wrote:
>
> OK, have a few updates to report:
>
>- Oracle vs OpenJDK did not make a difference
>- Whenever I run N>1 threads calling any of these functions with 
>swap/vswap, there is some overhead compared to running 18 separate 
>single-run processes in parallel.  This overhead seems to increase as N 
>increases.
>- For both swap and vswap, the function timings from running 18 
>   futures (from one JVM) show about 1.5X the time from running 18 
> separate 
>   JVM processes.
>   - For the swap version (f2), very often a few of the calls would go 
>   rogue and take around 3X the time of the others.
>  - this did not happen for the vswap version of f2.
>   - Running 9 processes with 2 f2-calling threads each was maybe 4% 
>slower than 18 processes of 1.
>- Running 4 processes with 4 f2-calling threads each was mostly the 
>same speed as the 18x1, but there were a couple of those rogue threads 
> that 
>took 2-3X the time of the others.
>
> Any ideas?
>

Try a one-element array and aset, and see if that's faster than atom/swap 
and volatile/vswap. The latter two have memory barriers, the former does 
not, so if it's flushing the CPU cache that's the key here, aset should be 
faster, but if it's something else, it will probably be the same speed. 

-- 
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: Poor parallelization performance across 18 cores (but not 4)

[David Iba]

Yeah, I actually tried using aset as well, and was still seeing these
"rogue" threads taking much longer (although the ones that did finish in a
normal amount of time had very similar completion times to those running in
their own process.)

Herwig: I will try those suggestions when I get a chance.



On Thu, Nov 19, 2015 at 6:19 PM, Fluid Dynamics  wrote:

> On Thursday, November 19, 2015 at 1:36:59 AM UTC-5, David Iba wrote:
>>
>> OK, have a few updates to report:
>>
>>- Oracle vs OpenJDK did not make a difference
>>- Whenever I run N>1 threads calling any of these functions with
>>swap/vswap, there is some overhead compared to running 18 separate
>>single-run processes in parallel.  This overhead seems to increase as N
>>increases.
>>- For both swap and vswap, the function timings from running 18
>>   futures (from one JVM) show about 1.5X the time from running 18 
>> separate
>>   JVM processes.
>>   - For the swap version (f2), very often a few of the calls would
>>   go rogue and take around 3X the time of the others.
>>  - this did not happen for the vswap version of f2.
>>   - Running 9 processes with 2 f2-calling threads each was maybe 4%
>>slower than 18 processes of 1.
>>- Running 4 processes with 4 f2-calling threads each was mostly the
>>same speed as the 18x1, but there were a couple of those rogue threads 
>> that
>>took 2-3X the time of the others.
>>
>> Any ideas?
>>
>
> Try a one-element array and aset, and see if that's faster than atom/swap
> and volatile/vswap. The latter two have memory barriers, the former does
> not, so if it's flushing the CPU cache that's the key here, aset should be
> faster, but if it's something else, it will probably be the same speed.
>
> --
> 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/W-sddnit69Q/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: [ANN] pex, a powerful PEG parsing library

[Ghadi Shayban]

Thanks for taking a look.

User-level bytecode allows me an easier choice to build a JIT or tracing 
infrastructure, while being far less complex than writing out JVM bytecode 
during grammar compile.

Christophe has certainly been a help offline with design choices.  I wanted 
PEG, no ambiguity, unlike instaparse or parsnip.  Most of the API 
inspiration was from LPEG & Scala's Parboiled2.  Some of the VM internals 
are close to JRuby's Joni regex engine.


On Thursday, November 19, 2015 at 8:24:37 AM UTC-5, bernardH wrote:
>
> This is interesting !
> It reminds me of Parsnip from C.Grand [0], have you considered it when 
> desining pex ? As your parser is focusing of characters, I am wondering : 
> could the operations triggered by the execution of your pex code be simple 
> enough to warrant actual compiling to JVM bytecode (at run time, with ASM 
> [1]) for maximum performance ?
>
> Best Regards,
>
> Bernard
>
> [0] https://github.com/cgrand/parsnip/
> [1] http://asm.ow2.org/
>
>

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

Data visualization workshops post-mortem

[Karsten Schmidt]

For those interested in data visualization with CLJ/CLJS, my thi.ng
libs, reagent & figwheel, I've recently been teaching two 3-day
workshops in London and published repos with fully commented source
code, incl. a lengthy report of the last workshop here:

https://medium.com/@thi.ng/workshop-report-building-linked-data-heatmaps-with-clojurescript-thi-ng-102e0581225c

https://github.com/thi-ng/ws-ldn-1
https://github.com/thi-ng/ws-ldn-2

Best, K.

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