Re: Java Interop on steroids?

[Nathan Fisher]

They did cite a significant performance boost as a side effect.

On Fri, Jun 21, 2019 at 21:04, Sean Corfield  wrote:

> I got the impression this was the primary reason for Storm’s rewrite:
>
>
>
> While Storm's Clojure implementation served it well for many years, it was
> often cited as a barrier for entry to new contributors. Storm's codebase is
> now more accessible to developers who don't want to learn Clojure in order
> to contribute.
>
>
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> ----------
> *From:* clojure@googlegroups.com  on behalf of
> Nathan Fisher 
> *Sent:* Friday, June 21, 2019 4:17:43 PM
> *To:* clojure@googlegroups.com
> *Subject:* Re: Java Interop on steroids?
>
> Storm recently moved away from Clojure in its core.
>
> https://storm.apache.org/2019/05/30/storm200-released.html
>
> I wonder how much of the legacy Clojure core could be optimised or if they
> reached an upper limit imposed by the runtime/architecture. That being said
> I suspect for 90% of orgs they'll never hit that boundary.
>
> On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger 
> wrote:
>
>> Sean,
>>
>> That is an interesting blog post.  Sorry if I am not following everything
>> but why not use the annotation support in gen-class for those types of
>> things?
>>
>>
>> https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34
>>
>> On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:
>>>
>>> You might be interested in how we provide type-based annotations on
>>> Clojure functions so that tooling (in our case New Relic) sees those
>>> annotations:
>>>
>>>
>>>
>>>
>>> https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/
>>>
>>>
>>>
>>> I agree that this could be a lot easier.
>>>
>>>
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>>
>>> --
>>> *From:* clo...@googlegroups.com  on behalf of
>>> eglue 
>>> *Sent:* Thursday, June 20, 2019 9:03:45 PM
>>> *To:* Clojure
>>> *Subject:* Java Interop on steroids?
>>>
>>> Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶
>>> ̶H̶i̶c̶k̶e̶y̶  guy.
>>>
>>> However -- there are many popular Java frameworks that love to reflect
>>> on their annotations and their generic type signatures.
>>>
>>> To name a heavyweight: Spring. But also, of late: big data frameworks,
>>> many written in Java, love reflecting on generic type signatures. My org is
>>> looking at Beam and Flink, for example.
>>>
>>> These frameworks use types not for the static checking really but as
>>> parameters governing their own dynamic behavior. For example, Spring will
>>> use types at runtime to simply match objects to where they should be
>>> dynamically injected. Beam will look at your type signatures and do runtime
>>> validations to ensure it can process things appropriately. Of course this
>>> is unfortunate, using types this way, when it is all really just data.
>>> Clojure does -- or would do -- it better, simpler, directer, and all of
>>> that.
>>>
>>> Yet we would like to leverage these frameworks. Or rather, we must for
>>> various pragmatic and business reasons.
>>>
>>> And any time we need to "communicate" to these frameworks "through"
>>> their desired fashion of generic types and annotations, we can, of course,
>>> create the appropriate .java files to represent what is needed (and then do
>>> the invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes,
>>> this works.
>>>
>>> However this is quite tedious because in these frameworks I mentioned
>>> you end up having to create these Java files quite a bit. For example, when
>>> expressing a streaming data pipeline to Beam, you may specify multiple
>>> transforms, each a function with its own type signature.
>>>
>>> A little searching and it seems Clojure has shied away from generating
>>> generic type information in pla

Re: Java Interop on steroids?

[Nathan Fisher]

oxy and re-run
>> it through ASM to create a *new* class with simply the proxy-produced class
>> bytes filled-in with the desired, provided type parameters. I bet this
>> could be sufficient and fast, with the slight overhead of the extra class.
>>
>> To do this, I think I'd need access to these proxy-made bytes... either
>> by having proxy answer them somehow, or offering a hook to contribute to
>> the defined bytecode before it is committed to the classloader, or by
>> having DynamicClassLoader have these bytes on hand for inquiring parties,
>> or something else along these lines. This would likely be something that
>> Clojure core would have to expose .. correct me if I'm wrong.
>>
>> Would love to hear any other immediate thoughts on this.
>>
>> I think once you realize that this generic type information is not even
>> being used for "static typing" by these frameworks but rather as an (albeit
>> poor) means to receive semantic information from their clients (as
>> parameters to govern their own dynamic behavior), then the need/value of
>> being able to remain in Clojure and communicate to these libraries through
>> generic params and annotations perhaps becomes more understandable..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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
>> clo...@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 clo...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/beca47df-4227-4d08-a71f-0e98e34a7acf%40googlegroups.com
> <https://groups.google.com/d/msgid/clojure/beca47df-4227-4d08-a71f-0e98e34a7acf%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Nathan Fisher
 w: http://junctionbox.ca/

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

Re: Noob: Getting (re)started with Clojure on OS X

[Nathan Fisher]

I would even argue against using central profiles. I think it obscures
behavioural differences between machines and can impair reproducibility.
Arguably better to have all deps in project where possible.
On Wed, Mar 13, 2019 at 22:45, Mike Rodriguez  wrote:

>
> [cider/cider-nrepl "0.8.2"]
>
> is quite old. It looks like lein 2.9.1 (as of 2.8.2) uses a newer version
> of nrepl that requires cider-nrepl 0.18+ or something along those lines.
> In newer versions of cider, you may not need to include this plugin at
> all. I know that the "jack-in" commands of cider can do it automatically
> for you at least. If removing the dep works fine for your workflow, I'd
> stick with that. Less is more. :-P
>
>
>
> On Wednesday, March 13, 2019 at 1:54:35 PM UTC-4, Kenneth Reid Beesley
> wrote:
>
>>
>>
>> On 13Mar2019, at 10:19, Sean Corfield  wrote:
>>
>> Check what’s in your ~/.lein/profiles.clj file – that’s usually the cause
>> of bizarre errors that people report with Leiningen.
>>
>>
>> Hello Sean,
>>
>> Hah!  I changed my ~/.lein/profiles.clj from
>>
>> {:user {:plugins [[cider/cider-nrepl "0.8.2"]]}}
>>
>> to
>>
>> {:user {:plugins [[lein-pprint "1.1.1"]]
>> :dependencies [[slamhound "1.3.1"]]}}
>>
>> and now ‘lein repl’ launches.
>>
>> Anything else I should add to ~/.lein/profiles.clj ?
>>
>> Many thanks!
>>
>> Ken
>>
>> ***
>> Kenneth R. Beesley, D.Phil.
>> PO Box 540475
>> North Salt Lake UT 84054
>> USA
>>
>>
>>
>>
>>
>>
>> --
> 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.
>
-- 
- sent from my mobile

-- 
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(Script) web apps in 2018

[Nathan Fisher]

Duct looks interesting.

I found luminous useful for when I first started with web dev in clojure
but started running against its project layout.
On Sun, Sep 23, 2018 at 15:17, Rick Moynihan 
wrote:

> I really quite like weavejester's duct, because it's essentially a
> familiar / standard ring app, but with integrant based configuration
> modules, and sensible defaults.  It's not perfect though, e.g. ataraxy is
> somewhat under-developed, so I'd look at swapping it out for bidi or
> something more mature.
>
> https://github.com/duct-framework/duct
>
> I've built a fair few luminus apps over the years and find it hard to love
> because of mount; and I strongly feel the templates default layout is
> organised in the wrong way.  It's hard to argue that it's not well
> documented, and quick to start with though, and it's pretty easy to use
> integrant or component and delete the src directory and pick a more
> sensible layout (I recomend structuring by feature/route, rather than by
> the incidental complexity of a webapp).
>
> Ultimately all the main options mentioned work quite well, so it depends
> on what you need and like etc.  You might also consider backing it with
> lacinia as a graphql backend.  lacinia is pretty neat.
>
>
> R.
>
> On Mon, 17 Sep 2018 at 10:27, Tom Locke  wrote:
>
>> Hi all,
>>
>> I'm a reasonably experienced ClojureScript developer, finally starting to
>> think about the server side of a web app I've been working on for some
>> time. I was wondering if anyone could offer some pointers for libraries
>> worth looking at. What would you be building on top of if you were starting
>> a web app in 2018?
>>
>> It's a single page app. I've already committed to Reagent on the client.
>> Will very likely go with Dataomic as the DB. The rest is open for now.
>>
>> I realise there is no "right answer" to such a question. All I'm after
>> here is to take the pulse of the community - "take a look at so-and-so",
>> "such and such is becoming a de-facto standard", "a few people got burned
>> with thingumy"...
>>
>> I think there are two distinct sub-questions here. First off one is going
>> to need a general server-side library e.g. Luminus (more a collection of
>> libraries), and then there is the much bigger question of keeping data in
>> sync across multiple clients/servers. Here we get into the vast topic of
>> distributed systems, full of deep, open questions, but I'm hoping for
>> advice for the working programmer : )
>>
>> Of particular interest would be whether people feel any of the more
>> ambitious libraries (e.g. Replikative) are worth relying on for a serious
>> project, or are people generally still rolling their own, RPC style.
>>
>> Thanks very much, in advance!
>>
>> Tom
>>
>> --
>> 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.
>
-- 
- sent from my mobile

-- 
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: Webassembly as a Clojure target platform

[Nathan Fisher]

I haven’t been following it that closely. I thought GC is planned but not
targeted for MVP or has that changed?

On Thu, Jul 26, 2018 at 20:32, Gerard Klijs  wrote:

> Kotlin native can also target wasm. But I don't know enough of it to know
> if it's usefull for the clojure story. Since there is very little you can
> do with wasm, it's highly dependent on interacting with JavaScript. It's
> possible some computational heavy stuff might better be done in wasm then
> JavaScript. But as wasm doesn't have baked in garbage collection, and for
> closure(script) we depend on the host for garbage collection, it will
> probably be a lot of work to pull this off.
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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: Rusts Upgrades

[Nathan Fisher]

If it’s run on CircleCI or Travis and has readonly access to github, I
wouldn’t be too concerned.

The most frequent downloads API in Clojars is a good idea. Could use it as
a basis for the hand rolled site for now and target it for automation in
the future. I’m wondering how amenable/suitable it would be for the data to
live in Clojars.

On Mon, Jul 30, 2018 at 02:17, Alan Moore 
wrote:

> Has anyone looked for vulnerabilities exposed by pulling random libraries
> from github.com (or gitlab.com?) and building them? Macros come mind
> (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code.
>
> Also instead of choosing "top-N projects on Github" I would begin with
> the "most used projects on clojars" (# downloads in the last 12 months?) as
> that might be a better metric/signal for prioritizing which libraries to
> include. #RememberLeftPad
>
> Don't get me wrong, I like the idea. I'm just trying to think through the
> possible hazards.
>
> Alan
>
>
> On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi Folks,
>>
>> Reading up the recent blog post “What is Rust 2018” and happened upon
>> this;
>>
>> “We put in a lot of work to make upgrades painless; for example, we run a
>> tool (called “crater”) before each Rust release that downloads every
>> package on crates.io and attempts to build their code and run their
>> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>>
>> Seems an interesting idea and with Travis and other CI services providing
>> free builds for OSS it doesn’t need to put a heavy financial/operational
>> burden on a single entity. The main benefit for this is for people could
>> get a quick centralised overview of compatibility of various projects and
>> impending releases of Clojure.
>>
>> The main idea would be to have a grid view of the latest Clojure projects
>> and their status against HEAD of Clojure (are snapshots pushed to a maven
>> repo automatically as a result of a commit build?). Travis allows periodic
>> builds so that could be used to trigger verification even when changes
>> haven’t occurred.
>>
>> In terms of initial focus targeting the top-N projects on Github makes
>> the most sense to me. The bit I’m still thinking through is providing some
>> form of dashboard/aggregation without requiring a large investment in
>> changes, infrastructure, etc. Might fit in nicely with something like
>> clojars? Was thinking initially having a Github page with a table of
>> projects and their build badges and talking to maintainers about
>> configuring periodic builds with the latest Clojure snapshot.
>>
>> Thoughts?
>>
>> Cheers,
>> Nathan
>> --
>> - sent from my mobile
>>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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: Improving Library Status Visibility - was Re: Rusts Upgrades

[Nathan Fisher]

Hi Alex,

I don't think it would be necessary to scrape the Jenkins server too often.
I speculate daily would be enough, hourly at most.

Cheers,
Nathan

On Sun, 29 Jul 2018 at 03:42 Alex Miller  wrote:

> On contribs, I just added the emeddable build status plugin - that’s easy.
> Migrating to Travis or Circle is not really a viable option based on my
> last research on this. I’d be a little worried about adding a lot of
> traffic that parsed the feeds. The box running Jenkins is already
> underpowered and Is hate to add load just for that.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Improving Library Status Visibility - was Re: Rusts Upgrades

[Nathan Fisher]

There's basically 3 ways I could see addressing the Jenkins builds;

1. Install the Jenkins badge plugin (
https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin).
2. Migrate them to a SaaS provider like Travis or Circle.
3. Write a mapper that consumes the CC tray feed and outputs badges (
https://build.clojure.org/cc.xml?recursive).

Given the limited bandwidth of the Cognitect folks 3 seems the most likely
immediate solution. SaaS CI services provide CC Tray feeds (
https://api.travis-ci.org/repos/boot-clj/boot/cc.xml?branch=master) so
using them as an aggregation method could be useful for 10s to 100s of
projects. It lacks the commit revision but does have time and status which
would be an incremental improvement over reams of pages with red and green
badges. The SaaS providers provide aggregates up to the org level so I
would want to use that for some of the more prolific Clojure community
authors. That being said I don't see cc tray feeds as a scalable solution
for all known libraries;

a) it's dependent on author discipline in keeping a given branch green.
b) it'll be a lot of potential requests to the SaaS providers and I'd like
to be a good netizen.
c) it's not a great way to isolate if a build broke due to a change in a
Clojure SNAPSHOT.
d) it requires community authors to "buy-in" to creating a periodic build
against SNAPSHOT.

Another approach I'm considering is using the org I created to host "sample
projects" that can be community owned with periodic builds that exercise an
"app" with common libraries and plugins against the latest Clojure SNAPSHOT
builds. Something similar to how TechEmpower Web Framework Benchmarks has a
number of authors submit a subproject to the repo (
https://github.com/TechEmpower/FrameworkBenchmarks). I plan to be fairly
liberal in delegating admin access to the org to minimise bottlenecks and
hopefully through that we could get good coverage that doesn't put too much
demand on any one person.

On Sat, 28 Jul 2018 at 21:44 Sean Corfield  wrote:

> Have you had any thoughts about incorporating Clojure Contrib projects?
> They all have JVM/Clojure version grids as part of their Jenkins CI builds
> but there isn’t a badge you could link to (although you could link to the
> CI matrix page for each of them). They’re all tested against 1.9 / 1.10 and
> several are tested against earlier versions too. E.g.,
>
>
>
> https://build.clojure.org/job/core.cache-test-matrix/
>
> https://build.clojure.org/job/data.priority-map-test-matrix/
>
> https://build.clojure.org/job/java.jdbc-test-matrix/
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> *From:* clojure@googlegroups.com  on behalf of
> Nathan Fisher 
> *Sent:* Saturday, July 28, 2018 4:11:13 PM
> *To:* clojure@googlegroups.com
> *Subject:* Re: Rusts Upgrades
>
> Hi Sean,
>
> It would be great if there was a general report that we could integrate
> with Lein, Boot and anything else people happen to be using.
>
> I think for an MVP having folks update the status of their project
> manually as it is verified might not be a bad first step.
>
> To that end I've created a Github page site here;
>
> - https://clojurestatus.github.io/dashboard/
> - https://github.com/ClojureStatus/dashboard
>
> I know it won't scale well to all the projects out there but if we can get
> some of the major ones I think it could be useful. It'll probably need some
> thought about how to improve the aggregate view, date of last build, etc.
>
> Cheers,
> Nathan
>
> On Sat, 28 Jul 2018 at 19:50 Sean Corfield  wrote:
>
>> I suspect quite a few Travis-enabled Clojure projects do full
>> multi-version testing – but it’s hard to tell at a glance from Travis’s
>> logs. For example, both HoneySQL and clj-time perform multi-version testing
>> on Travis, but they do it through Leiningen aliases so there’s only one
>> “build” – no grid of Clojure versions. I’d be interested in hearing of
>> techniques to surface a grid of Clojure versions being tested on Travis.
>>
>>
>>
>> Note that clj-time is tested against a grid of JVM versions and that does
>> surface on Travis – and I’ve just noticed that testing against Clojure
>> master on OpenJDK 7 fails, presumably because Clojure master now requires
>> Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail).
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>>

Re: Rusts Upgrades

[Nathan Fisher]

Hi Sean,

It would be great if there was a general report that we could integrate
with Lein, Boot and anything else people happen to be using.

I think for an MVP having folks update the status of their project manually
as it is verified might not be a bad first step.

To that end I've created a Github page site here;

- https://clojurestatus.github.io/dashboard/
- https://github.com/ClojureStatus/dashboard

I know it won't scale well to all the projects out there but if we can get
some of the major ones I think it could be useful. It'll probably need some
thought about how to improve the aggregate view, date of last build, etc.

Cheers,
Nathan

On Sat, 28 Jul 2018 at 19:50 Sean Corfield  wrote:

> I suspect quite a few Travis-enabled Clojure projects do full
> multi-version testing – but it’s hard to tell at a glance from Travis’s
> logs. For example, both HoneySQL and clj-time perform multi-version testing
> on Travis, but they do it through Leiningen aliases so there’s only one
> “build” – no grid of Clojure versions. I’d be interested in hearing of
> techniques to surface a grid of Clojure versions being tested on Travis.
>
>
>
> Note that clj-time is tested against a grid of JVM versions and that does
> surface on Travis – and I’ve just noticed that testing against Clojure
> master on OpenJDK 7 fails, presumably because Clojure master now requires
> Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail).
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> ------
> *From:* clojure@googlegroups.com  on behalf of
> Nathan Fisher 
> *Sent:* Friday, July 27, 2018 4:11:05 PM
> *To:* clojure@googlegroups.com
> *Subject:* Rusts Upgrades
>
> Hi Folks,
>
> Reading up the recent blog post “What is Rust 2018” and happened upon this;
>
> “We put in a lot of work to make upgrades painless; for example, we run a
> tool (called “crater”) before each Rust release that downloads every
> package on crates.io and attempts to build their code and run their
> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>
> Seems an interesting idea and with Travis and other CI services providing
> free builds for OSS it doesn’t need to put a heavy financial/operational
> burden on a single entity. The main benefit for this is for people could
> get a quick centralised overview of compatibility of various projects and
> impending releases of Clojure.
>
> The main idea would be to have a grid view of the latest Clojure projects
> and their status against HEAD of Clojure (are snapshots pushed to a maven
> repo automatically as a result of a commit build?). Travis allows periodic
> builds so that could be used to trigger verification even when changes
> haven’t occurred.
>
> In terms of initial focus targeting the top-N projects on Github makes the
> most sense to me. The bit I’m still thinking through is providing some form
> of dashboard/aggregation without requiring a large investment in changes,
> infrastructure, etc. Might fit in nicely with something like clojars? Was
> thinking initially having a Github page with a table of projects and their
> build badges and talking to maintainers about configuring periodic builds
> with the latest Clojure snapshot.
>
> Thoughts?
>
> Cheers,
> Nathan
> --
> - sent from my mobile
>
> --
> 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 G

Rusts Upgrades

[Nathan Fisher]

Hi Folks,

Reading up the recent blog post “What is Rust 2018” and happened upon this;

“We put in a lot of work to make upgrades painless; for example, we run a
tool (called “crater”) before each Rust release that downloads every
package on crates.io and attempts to build their code and run their tests.”
 - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html

Seems an interesting idea and with Travis and other CI services providing
free builds for OSS it doesn’t need to put a heavy financial/operational
burden on a single entity. The main benefit for this is for people could
get a quick centralised overview of compatibility of various projects and
impending releases of Clojure.

The main idea would be to have a grid view of the latest Clojure projects
and their status against HEAD of Clojure (are snapshots pushed to a maven
repo automatically as a result of a commit build?). Travis allows periodic
builds so that could be used to trigger verification even when changes
haven’t occurred.

In terms of initial focus targeting the top-N projects on Github makes the
most sense to me. The bit I’m still thinking through is providing some form
of dashboard/aggregation without requiring a large investment in changes,
infrastructure, etc. Might fit in nicely with something like clojars? Was
thinking initially having a Github page with a table of projects and their
build badges and talking to maintainers about configuring periodic builds
with the latest Clojure snapshot.

Thoughts?

Cheers,
Nathan
-- 
- sent from my mobile

-- 
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: Webassembly as a Clojure target platform

[Nathan Fisher]

Think Rust and Golang both have the ability to target WASM now too. I'm not
sure how well Java Byte-Code to WASM would work in practise. Found this
project that seems able to transpile from Java ByteCode to JS/WASM;

http://teavm.org/

On Thu, 26 Jul 2018 at 12:34 Bo Yao  wrote:

> Not true.Wasm is a a kind of assembly and it's browser runtime:
> https://webassembly.github.io/spec/. The emscripten project is doing
> compile c/c++ to wasm. There's a another team working on rust to wasm
> compiler and toolchains: https://webassembly.github.io/spec/
>
> On Friday, September 15, 2017 at 3:08:18 AM UTC-4, Nur Azhar wrote:
>>
>> Correct me if I am wrong, webassembly is just a compiler currently only
>> supports C,C++ and rust and we might be able to compile clojure to
>> webassembly in the far future?
>>
>> On Thursday, September 14, 2017 at 5:03:25 AM UTC+8, Hlöðver Sigurðsson
>> wrote:
>>>
>>> https://github.com/AssemblyScript/assemblyscript
>>>
>>>
>>> Looks like the Typescript people are attempting exactly this.
>>>
>>> On Monday, 4 April 2016 08:50:06 UTC+2, JvJ wrote:

 Is there any plan in the future to have clojure (or some dialect of
 clojure) compile to webassembly?  I can't say for sure if it is the "next
 big thing" for the web, but it is a very interesting concept.

 I suppose that, if Java bytecode could cross-compile to Webassembly, we
 would essentially get this for free, but I'm not sure if that will happen.

>>> --
> 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.
>
-- 
- sent from my mobile

-- 
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: Bazel as Clojure build tool

[Nathan Fisher]

It's not something that as a user you'd be exposed to. The easiest way to 
demonstrate the impact is to write a library and test target in two 
different ways for a Java project.

1. using java_library target for the library.
2. using genrule for the library that calls out to javac.

Run the test target, introduce whitespace into the library, and run the 
test target again. It should only do a full execution in the 2nd example.

On Sunday, 15 April 2018 17:09:12 UTC-3, Gregg Reynolds wrote:
>
>
>
> On Mon, Jan 29, 2018, 2:07 PM Nathan Fisher  > wrote:
>
>> ...
>
>>  In order to get the speed that the build tool promises you need the 
>> ability to efficiently parse the ABI of each file and only build its 
>> dependents when the ABI has changed.
>>
>
> Can you please elaborate on this a bit? I've been using Bazel for a 
> project that involve C and Java, with cross-compiles, and ABI parsing has 
> never come up. It just works.
>
>>
>> I’m not certain you can do that with Clojures compiler but someone else 
>> might be able to chime in with a way that you could.
>>
>
> I like boot for clojure stuff, not sure Bazel offers any advantage. 
> Clojurescript may be a different story, tho.
>
> So far I cannot see a good reason to switch from boot to Bazel for 100% 
> clojure projects. Mixed language - clojure, clojurescript, js, Java, 
> kotlin, JNI,etc - may be a different story, still not sure.
>
> Then there's remote caching: 
> https://docs.bazel.build/versions/master/remote-caching.html. a hyge 
> win for many scenarios, not so sure about clojure.
>
> G
> G
>

-- 
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: Understanding GraalVM and Clojure

[Nathan Fisher]

Is there a runnable language test suite that is used to verify CLJ, CLJS,
and CLR compatibility? Thinking something similar to RubySpec that could be
used to validate the completeness/gaps in a particular implementation (eg
GraalVM).
On Sun, Apr 29, 2018 at 7:16 AM, Khalid Jebbari <khalid.jebb...@gmail.com>
wrote:

> I've read it, it's really interesting. Alex Miller mentioned on Twitter
> that they'll work on removing some limitations over time. @Alex, can you
> confirm and expand a bit more ?
>
> Le sam. 28 avr. 2018 à 23:14, Nathan Fisher <nfis...@junctionbox.ca> a
> écrit :
>
>> Another interesting post on Clojure and Graal
>>
>> https://www.innoq.com/en/blog/native-clojure-and-graalvm/
>> On Sat, Apr 28, 2018 at 10:01 AM, Khalid Jebbari <
>> khalid.jebb...@gmail.com> wrote:
>>
>>> Thank you for the link.
>>>
>>> Le sam. 28 avr. 2018 à 00:35, Egg Syntax <eggsyn...@gmail.com> a écrit :
>>>
>>>> Karin Meier has done some experimentation using Clojure on GraalVM to
>>>> call R and Python, and has a blog post
>>>> <http://gigasquidsoftware.com/blog/2017/10/22/embedded-interop-between-clojure-r-and-python-with-graalvm/>
>>>>  and repo
>>>> <https://github.com/gigasquid/graal-test/blob/master/src/graal_test/core.clj>
>>>>  that
>>>> you may find interesting.
>>>>
>>>>
>>>> On Thursday, April 19, 2018 at 6:00:14 AM UTC-4, Khalid Jebbari wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Oracle has just announced GraalVM 1.0 release candidate:
>>>>> https://blogs.oracle.com/developers/announcing-graalvm
>>>>>
>>>>> It mentions a few JVM-based language but not Clojure (maybe just
>>>>> because of popularity).
>>>>> - Does it mean Clojure is not "compatible" with GraalVM ?
>>>>> - Does it mean Clojure needs to be reimplemented in terms of GraalVM's
>>>>> Truffle framework ?
>>>>> - Does it mean Clojure can be run as a native binary with fast startup
>>>>> time and minimized memory footprint ?
>>>>>
>>>>> If someone with some knowledge could explain to me the relationships
>>>>> between Clojure and GraalVM ? Bonus points if Alex Miller answers and 
>>>>> share
>>>>> the plans, if any, about their integration/interaction.
>>>>>
>>>>> Thanks a lot in advance. really curious to understand more.
>>>>>
>>>> --
>>>> 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/iBY6hwqqp5c/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.
>>>
>> --
>> - sent from my mobile
>>
>> --
>> You received this message because 

Re: Understanding GraalVM and Clojure

[Nathan Fisher]

Another interesting post on Clojure and Graal

https://www.innoq.com/en/blog/native-clojure-and-graalvm/
On Sat, Apr 28, 2018 at 10:01 AM, Khalid Jebbari 
wrote:

> Thank you for the link.
>
> Le sam. 28 avr. 2018 à 00:35, Egg Syntax  a écrit :
>
>> Karin Meier has done some experimentation using Clojure on GraalVM to
>> call R and Python, and has a blog post
>> 
>>  and repo
>> 
>>  that
>> you may find interesting.
>>
>>
>> On Thursday, April 19, 2018 at 6:00:14 AM UTC-4, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> Oracle has just announced GraalVM 1.0 release candidate:
>>> https://blogs.oracle.com/developers/announcing-graalvm
>>>
>>> It mentions a few JVM-based language but not Clojure (maybe just because
>>> of popularity).
>>> - Does it mean Clojure is not "compatible" with GraalVM ?
>>> - Does it mean Clojure needs to be reimplemented in terms of GraalVM's
>>> Truffle framework ?
>>> - Does it mean Clojure can be run as a native binary with fast startup
>>> time and minimized memory footprint ?
>>>
>>> If someone with some knowledge could explain to me the relationships
>>> between Clojure and GraalVM ? Bonus points if Alex Miller answers and share
>>> the plans, if any, about their integration/interaction.
>>>
>>> Thanks a lot in advance. really curious to understand more.
>>>
>> --
>> 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/iBY6hwqqp5c/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.
>
-- 
- sent from my mobile

-- 
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: Understanding GraalVM and Clojure

[Nathan Fisher]

I was thinking it would be interesting to “remove” the use of Java interop
in core instead replacing it with a reserved namespace that maps to
whatever the underlying runtime/reader wants to. I suppose you can do the
same with the exisiting RT stuff but naively feels like it would be
cleaner/provide easier porting if it were one namespace which could have
Clojure docs generated for it.

On Thu, Apr 19, 2018 at 2:55 PM, Timothy Baldridge 
wrote:

> GraalVM does a lot of things, and I think it's important to separate these
> terms.
>
> GraalVM - most often this is used to refer to a project that was
> originally designed to be a implementation of the JVM in Java. So when
> people ask "does X run on GrallVM" the question is really "does X run in
> the JVM". Clojure runs on the JVM therefore it runs on GraalVM. I've done
> this, and it's not that hard to setup.
>
> Truffle - is an AST interpreter framework that allows for highly dynamic
> languages to run efficiently on GraalVM. Truffle is valid Java code, so you
> can run Truffle on a stock JVM, but it's much faster on GraalVM (or on JVM
> of version >= 9). Notice my use of "highly dynamic" earlier. Surprisingly,
> Clojure is mostly static, so there's no clear win here to translating
> Clojure to Truffle. The exception to this is primitive math, and situations
> that use lots of HOF where Truffle could perhaps offer more localized
> optimizations that fit into the Clojure programming model. However, you pay
> for all this with some rather massive startup time penalties. Most examples
> I've seen show Truffle adding seconds on to the startup time of a language.
>
> SubstrateVM - (aka native-image), SubstrateVM attempts to improve the
> performance of a Truffle based language by doing image freezing. This
> method has been used in other languages, and has existed in the PyPy
> toolchain (RPython) for well over a decade. The idea is that you write an
> interpreter, then hand SVM a pointer to the start of your interpreter (the
> main() function). The framework then analyzes the data needed by that
> function and all the functions it calls. All data required by those
> functions are also recorded. Then the call graph required to run all these
> functions is written out (normally to C or C++) and compiled. The
> side-effect is that all the startup time is removed since the interpreter
> is "frozen" in a started state. In the terms of Clojure this means that
> metadata would be serialized as-is, instead of running the code to create
> that metadata on every startup.
>
> Polyglot VM - so in truffle you can have multiple type systems, and
> multiple languages all running on Truffle. The framework then allows cheap
> interop between these languages. So when GraalVM docs talk about "zero
> overhead interop" what they mean is that it's possible to inline a Truffle
> based function inside any other truffle based function. Since Truffle
> implementations exist for Ruby, Python, LLVM bytecode (think C/C++),
> JavaScript, etc. It's easy to see how its possible to have all of these
> languages efficiently calling each other on the same VM.
>
> It's not all awesome though. By using SubstrateVM you give up Java
> reflection/interop, or have to find a way to embed a full JVM as a Truffle
> language (this is being worked on), but every language you add into your
> SVM image comes at a cost of startup times, memory usage etc. So most of
> the time SVM images stick to a few languages. TruffleRuby for example only
> uses Ruby and LLVM (for c interop).
>
> To finish, I think Clojure on Truffle is possible, but it would take a TON
> of work. Basically most of clojure.lang.RT would need to be rewritten from
> scratch, and I'm not sure how much more in clojure.lang.* would also need
> to be rewritten. So the tradeoff is:
>
> A. Current state
> - Good enough performance
> - Fast enough startup (Clojure starts quickly, it's the deps/tooling that
> are slow)
> - Requires type hinting to avoid reflection
>
> B. Clojure on Truffle
> - More-or-less the same performance
> - Faster un-type-hinted math
> - (Possibly) Faster transducers/HOF over primitive collections
> - No need for type hints
> - Massive rewrite
> - Huge startup time penalty
> - Requires a modern/uncommon JVM (JVM9+ or GraalVM)
>
> Comparing these side-by-side, it looks to me to be a wash. And because of
> that I doubt we'll see a TruffleClojure any time soon.
>
> Timothy
>
> On Thu, Apr 19, 2018 at 4:00 AM, Khalid Jebbari 
> wrote:
>
>> Hello,
>>
>> Oracle has just announced GraalVM 1.0 release candidate:
>> https://blogs.oracle.com/developers/announcing-graalvm
>>
>> It mentions a few JVM-based language but not Clojure (maybe just because
>> of popularity).
>> - Does it mean Clojure is not "compatible" with GraalVM ?
>> - Does it mean Clojure needs to be reimplemented in terms of GraalVM's
>> Truffle framework ?
>> - Does it mean Clojure can be run as a native binary with fast 

Re: Bazel as Clojure build tool

[Nathan Fisher]

Hi Kiril,

I think you’d need to set your expectations. Faster builds are unlikely to
be one of the benefits. A unified build tool is one.

I’ve seen a few similar attempts with Buck which was inspired by Bazel.
They either generate lein projects on the fly or call into the Clojure
compiler directly.

I think Clojure’s build model works against these tools in part because
it’s a dynamic language, in part because it doesn’t implicitly forward
declare functions, in part because (I believe) it does breadth first
traversal if dependencies, and in part it’s non-trivial/inefficient to
create a clean Clojure VM per dependency in the build graph.

Typical usage of these build tools is to have a build file per directory
with one or more targets in each file. In order to get the speed that the
build tool promises you need the ability to efficiently parse the ABI of
each file and only build its dependents when the ABI has changed.

I’m not certain you can do that with Clojures compiler but someone else
might be able to chime in with a way that you could.

Cheers,
Nathan

On Mon, 29 Jan 2018 at 13:16, Kiril Videlov  wrote:

> Hello,
> I have been looking at the Bazel  build tool for a
> multi-language mono-repo and I was wondering if anybody has tried it in the
> context of Clojure projects. I have only found the lein-monolith
>  plugin which appears to
> address a similar use case sans the polyglot requirement. Do you think
> there is any value in attempting to build a rule set
>  similar to
> the bazel rules for Scala ?
>
> Regards,
> Kiril Videlov
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

[Nathan Fisher]

Also what I was referencing in terms of the CAS was deferring submission
until the namespace is fully initialised. Something akin to a SQL
transaction where it could use mutable state and then transform it to the
immutable map at commit (eg end of the file). Until a ns fully parsed and
processed (by a single thread) there wouldn’t be any need for the
intermediate data structure to be thread-safe. Kind of like Guava data
structures but for Namespaces.
On Fri, 26 Jan 2018 at 16:57, Nathan Fisher <nfis...@junctionbox.ca> wrote:

> Hi Alex,
>
> That’s cool!
>
> I was looking to explore alternatives optimisations to what you had
> already outlined and which I could potentially do with little effort. I
> started writing something to do parallel loads back in Sept/Oct. and was
> replicating some of what Buck/Blaze/Basel do in terms of a DAG. I wanted
> “pristine” Clojure VMs for each node in the dependency graph but startup
> time was an issue and I couldn’t see an easy way to bring it down.
>
> For point one I was noticing some amount of non-trivial latency in Var
> interning and RT map. Agree Java CAS performance won’t be the issue but (I
> think) there’s something in Clojure that I’m working to improve my
> understanding. For the map I noticed once I eliminated class loading via
> prefetching the map initialisation in RT was a non-trivial amount of time
> (double digit ms). Not something that I think needs prioritisation by any
> means but just a “huh wonder why that is?”.
>
> Justin in terms of Java it’s not a matter of JIT or anything like that.
> It’ll be relatively efficient out of the box, it’s a handful of cpu
> instructions to execute and is around 20 CPU cycles per try (eg
> nanoseconds). It should succeed on or about the first time within the
> context of Clojure startup. An atomic load side depends on how far up the
> memory chain it has to go but shouldn’t be “too expensive” either, more
> expensive than a local variable for sure but not enough to worry about in
> most cases.
>
> Cheers,
> Nathan
> On Fri, 26 Jan 2018 at 15:38, Justin Smith <noisesm...@gmail.com> wrote:
>
>> a nitpick on point 1 - I would assume you can't expect hotspot to improve
>> anything in the timescale of a program startup
>>
>> am I missing something here?
>>
>> On Fri, Jan 26, 2018 at 10:32 AM Alex Miller <a...@puredanger.com> wrote:
>>
>>> With a few custom patches (which are pending in jira) + AOT + direct
>>> linking + lazy vars + var meta elision + jvm flags, I have gotten raw
>>> startup as low as ~450 ms. Past that, radical changes are probably required
>>> which are unlikely to be worth doing.
>>>
>>> On your conclusions:
>>>
>>> 1. minimize CAS'es - I'm doubtful this would make much difference.
>>> Hotspot is usually pretty good at optimizing that stuff in single-threaded
>>> uncontended scenarios. I will wave in the general direction of immutable
>>> namespaces to a place that I think is an opportunity to improve a range of
>>> issues like this.
>>>
>>> 2. Lazy vars effectively do this (in tandem with AOT and direct linking)
>>> and it can help 20-30% (presuming you have compiled stuff to use). However,
>>> most startup cases don't have AOT compiled code to work with and thus this
>>> won't help at all.
>>>
>>> 3. Prefetching - as you found, I would not expect this to be useful
>>> enough to be worth the pain and fragility involved.
>>>
>>> 4. jaotc - I think this *is* likely to be useful for cases where you can
>>> pre-stage stuff like this, in particular core itself is a perfect
>>> opportunity. People have already tested this (
>>> https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html) and found
>>> it useful. But again, requires pre-AOT'ed code.
>>>
>>> I don't think most of these changes help at all though in the most
>>> common case where you are spinning up a project with a lot of non-AOT'ed
>>> code - the 10s of seconds of read/compile/init times dwarf this stuff. Rich
>>> and I working on an idea to help with this.
>>>
>>> On Thursday, January 25, 2018 at 11:47:32 PM UTC-6, Nathan Fisher wrote:
>>>>
>>>> It's not a huge contributor but Class loading isn't free and Clojure
>>>> could optimise it in a couple of places. I think with a couple of months
>>>> effort in optimisation you might be able to get it down to 500ms for a
>>>> simple "hello world". I'm doubtful you can get it much lower than that. TBH
>>>> I'm not sure if the engineering effort would necessarily be worth i

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

[Nathan Fisher]

Hi Alex,

That’s cool!

I was looking to explore alternatives optimisations to what you had already
outlined and which I could potentially do with little effort. I started
writing something to do parallel loads back in Sept/Oct. and was
replicating some of what Buck/Blaze/Basel do in terms of a DAG. I wanted
“pristine” Clojure VMs for each node in the dependency graph but startup
time was an issue and I couldn’t see an easy way to bring it down.

For point one I was noticing some amount of non-trivial latency in Var
interning and RT map. Agree Java CAS performance won’t be the issue but (I
think) there’s something in Clojure that I’m working to improve my
understanding. For the map I noticed once I eliminated class loading via
prefetching the map initialisation in RT was a non-trivial amount of time
(double digit ms). Not something that I think needs prioritisation by any
means but just a “huh wonder why that is?”.

Justin in terms of Java it’s not a matter of JIT or anything like that.
It’ll be relatively efficient out of the box, it’s a handful of cpu
instructions to execute and is around 20 CPU cycles per try (eg
nanoseconds). It should succeed on or about the first time within the
context of Clojure startup. An atomic load side depends on how far up the
memory chain it has to go but shouldn’t be “too expensive” either, more
expensive than a local variable for sure but not enough to worry about in
most cases.

Cheers,
Nathan
On Fri, 26 Jan 2018 at 15:38, Justin Smith <noisesm...@gmail.com> wrote:

> a nitpick on point 1 - I would assume you can't expect hotspot to improve
> anything in the timescale of a program startup
>
> am I missing something here?
>
> On Fri, Jan 26, 2018 at 10:32 AM Alex Miller <a...@puredanger.com> wrote:
>
>> With a few custom patches (which are pending in jira) + AOT + direct
>> linking + lazy vars + var meta elision + jvm flags, I have gotten raw
>> startup as low as ~450 ms. Past that, radical changes are probably required
>> which are unlikely to be worth doing.
>>
>> On your conclusions:
>>
>> 1. minimize CAS'es - I'm doubtful this would make much difference.
>> Hotspot is usually pretty good at optimizing that stuff in single-threaded
>> uncontended scenarios. I will wave in the general direction of immutable
>> namespaces to a place that I think is an opportunity to improve a range of
>> issues like this.
>>
>> 2. Lazy vars effectively do this (in tandem with AOT and direct linking)
>> and it can help 20-30% (presuming you have compiled stuff to use). However,
>> most startup cases don't have AOT compiled code to work with and thus this
>> won't help at all.
>>
>> 3. Prefetching - as you found, I would not expect this to be useful
>> enough to be worth the pain and fragility involved.
>>
>> 4. jaotc - I think this *is* likely to be useful for cases where you can
>> pre-stage stuff like this, in particular core itself is a perfect
>> opportunity. People have already tested this (
>> https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html) and found
>> it useful. But again, requires pre-AOT'ed code.
>>
>> I don't think most of these changes help at all though in the most common
>> case where you are spinning up a project with a lot of non-AOT'ed code -
>> the 10s of seconds of read/compile/init times dwarf this stuff. Rich and I
>> working on an idea to help with this.
>>
>> On Thursday, January 25, 2018 at 11:47:32 PM UTC-6, Nathan Fisher wrote:
>>>
>>> It's not a huge contributor but Class loading isn't free and Clojure
>>> could optimise it in a couple of places. I think with a couple of months
>>> effort in optimisation you might be able to get it down to 500ms for a
>>> simple "hello world". I'm doubtful you can get it much lower than that. TBH
>>> I'm not sure if the engineering effort would necessarily be worth it for
>>> many users.
>>>
>>> I wanted to test dynamic loading and docker before I shared the article
>>> more broadly but here's the results from implementing prefetching in
>>> Clojure;
>>>
>>> https://junctionbox.ca/2018/01/04/clojure-class-prefetching.html
>>> <https://www.google.com/url?q=https%3A%2F%2Fjunctionbox.ca%2F2018%2F01%2F04%2Fclojure-class-prefetching.html=D=1=AFQjCNGztHxa9E7A5PbzIdoK_5PK_bqzVw>
>>>
>>> It's a part of a series that I'm slowly plodding through as I have time.
>>> I hope to cover off the 4 items from the conclusion of this article;
>>>
>>>
>>> https://junctionbox.ca/2017/12/26/clojure-startup-walkthrough.html#conclusions
>>> <https://www.google.com/url?q=https%3A%2F%2Fjunction

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

[Nathan Fisher]

art/ on 1.9,
>>>>>> >
>>>>>> > It looks like clojure/core__init.load is the slowest bit with load
>>>>>> and
>>>>>> > requiring spending the most time on, as well as loadClass, followed
>>>>>> by
>>>>>> > clojure/lang/Var.invoke.
>>>>>> >
>>>>>> > Wouldn't ClojureScript also need to initialize all Vars and execute
>>>>>> top
>>>>>> > level forms? You'd think that part would be slower in JavaScript no?
>>>>>> >
>>>>>> > --
>>>>>> > 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 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.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Stephen Nelson | Platform Lead Developer | Montoux
>>>>> e.  ste...@montoux.com
>>>>> t.  @montoux
>>>>> w.  montoux.com
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> “One of the main causes of the fall of the Roman Empire was
>>>> that–lacking zero–they had no way to indicate successful termination of
>>>> their C programs.”
>>>> (Robert Firth)
>>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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.
>



-- 
Nathan Fisher
 w: http://junctionbox.ca/

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

Re: [ANN] Git Deps for Clojure!

[Nathan Fisher]

You could do it by “rooting” the package (aka change the package path).
Most JVM languages root their dependencies to avoid collisions with user
space dependencies. ASM is the most common Clojure does and I think Kotlin
and Scala do as well. I think Guavas murmur3 is rooted in Clojure as well
for the maps.
On Mon, 8 Jan 2018 at 05:47, Gary Verhaegen <gary.verhae...@gmail.com>
wrote:

> Have you considered adding an equivalent to lein’s pedantic option, i.e.
> an option that would die on ambiguous versions rather than make a choice,
> thereby forcing users to make that choice explicit as a top-level entry?
> (Or through exclusions etc.)
>
> As an aside, is it even possible on the JVM to have multiple versions of a
> dependency loaded? Wouldn’t the last version loaded override all the common
> classes, leaving you with a sort of hybrid that doesn’t correspond to any
> single version? I’d really like a dependency system that makes each dep’s
> transitive dependencies only visible to itself, so there would never be any
> reason to resolve dependencies.
>
> Also, how realistic do you think it is today to expect all of our
> transitive dependencies to be developed according to that growth mindset
> you mention? It’s one thing to adopt it in my code, but quite another to
> assume it’s followed correctly by all of the underlying Java libs.
>
> On 8 Jan 2018, at 01:24, Alex Miller <a...@puredanger.com> wrote:
>
>
> On Sun, Jan 7, 2018 at 6:53 PM, Nathan Fisher <nfis...@junctionbox.ca>
> wrote:
>
>
>> I strongly agree with your decision of “pick the latest”. While I do
>> understand multiple active versions can make it easier for a developer I
>> don’t think that’s the “right” decision. Besides I can only imagine how
>> much of a pain it would be to implement reliably. I’d expect if I specify a
>> patched version of struts that a transitive dependency wouldn’t have the
>> ability to override that for its own purpose.
>>
>
> I guess I didn't mention that top-level deps always win, so if desired you
> are always able to decide the specific version in your project.
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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] Git Deps for Clojure!

[Nathan Fisher]

Hi Alex,

Sounds great!

I strongly agree with your decision of “pick the latest”. While I do
understand multiple active versions can make it easier for a developer I
don’t think that’s the “right” decision. Besides I can only imagine how
much of a pain it would be to implement reliably. I’d expect if I specify a
patched version of struts that a transitive dependency wouldn’t have the
ability to override that for its own purpose.

Cheers,
Nathan

On Sun, 7 Jan 2018 at 20:51, Alex Miller <a...@puredanger.com> wrote:

>
> On Sunday, January 7, 2018 at 3:41:34 PM UTC-6, Nathan Fisher wrote:
>>
>>
>> Not sure I would want to see duplicates either. If my code breaks because
>> of an old dependency I’d rather that than make the false assumption that
>> I’m running securely with the latest version of a lib.
>>
>
> Encountering duplicate libs in the transitive tree is common to almost
> every dependency trees (for example, it's typical to see multiple versions
> of Clojure as a dependency in *every* transitive tree). clj, like every
> other dependency tool, will continue to make choices about which version to
> include and tools to control which one is included.
>
> I do plan to add better tools to understand the tree and the choices made.
>
>> --
> 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.
>
-- 
- sent from my mobile

-- 
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] Git Deps for Clojure!

[Nathan Fisher]

Im probably not typical for this but I really value the ability to override
the location of where they’re placed. I actually commit my deps to SCM for
production code. The internet is fast enough these days that i don’t care
about a common code cache. I’m more interested in a reproducible build.

On Sat, 6 Jan 2018 at 11:25, Alex Miller  wrote:

>
>
> > On Jan 6, 2018, at 5:43 AM, Khalid Jebbari 
> wrote:
> >
> > Great news, great work ! Soon running Clojure will be dead easy.
> >
> > 2 questions :
> > - where do dependencies get downloaded ? `~/.m2` ? It depends on the
> procurer (mvn/git/etc.)
>
> It depends. Maven deps go to .m2, git deps go to .gitlibs.
>
> > - does it work for Cljs ? What does it mean for Cljs ?
>
> This is targeted at launching Clojure programs. ClojureScript itself is a
> Clojure program, so it’s relevant in that sense.
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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] Git Deps for Clojure!

[Nathan Fisher]

Great work Alex!

Not sure I would want to see duplicates either. If my code breaks because
of an old dependency I’d rather that than make the false assumption that
I’m running securely with the latest version of a lib.

On Fri, 5 Jan 2018 at 16:20, Gary Trakhman  wrote:

> Congrats on the release! It's exciting to see this vision move forward.
> Wondering if the logical next step is the npm style of trees of duplicate
> transitive git deps.  In general, how is this going to work for transitive
> deps?
>
> On Fri, Jan 5, 2018 at 1:49 PM Alex Miller  wrote:
>
>> Pleased to announce some new functionality for clj and tools.deps!
>>
>> https://clojure.org/news/2018/01/05/git-deps
>>
>> Additionally, there have been new releases of:
>> - Brew clojure formula (to get it: brew upgrade clojure)
>> - Linux clojure installer (see https://clojure.org/guides/getting_started
>> for info)
>> - tools.deps.alpha 
>> - NEW tools.gitlibs 
>>
>> Other than git deps, "clj -Spom" for pom generation has some fixes and an
>> addition to add Maven repositories if needed.
>>
>> --
>> 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.
>
-- 
- sent from my mobile

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

Illustrated Guide to Clojure Start-up Timings

[Nathan Fisher]

Hi All,

Over the holiday's I started to write up my analysis of the trace output I
mentioned previously. The article is posted below;

https://news.ycombinator.com/item?id=16056522

Cheers,
Nathan


-- 
- sent from my mobile

-- 
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 Start-up Time

[Nathan Fisher]

Thanks Alex!

Agreed I don’t think there is any easy quick win aside from putting a
conditional around the server section that’s controlled by an environment
variable.

There might be some optimisations that could be done by front loading
classes, similar to a prefetch in HTTP. Class loads from jars aren’t cheap
once it’s in the JVM code cache it isn’t expensive though. In RT.load the
getResource classfile and cljs is 38ms as an example. I was able to shave
off startup time in cljbuck by packing all of the class loading together
early. The extensive use of static initialisation could make this erroneous
though.

I started a branch that refactors the static methods and initialisation
into instance methods of another class. It uses a singleton factory to
maintain the behaviour of the RT ABI. With instances it would provide
isolation which could enable deterministic parallel builds, better core
test isolation, and possibly provide benefits to REPLs.

The refer ticket in particular is interesting.

Cheers,
Nathan

On Sat, 23 Dec 2017 at 11:23, Alex Miller >
wrote:

> Some related tickets:
>
> Server load (open) - https://dev.clojure.org/jira/browse/CLJ-1891
>
> Spec load (closed but some more info) -
> https://dev.clojure.org/jira/browse/CLJ-2108
>
> refer perf (open) - https://dev.clojure.org/jira/browse/CLJ-1730
>
> However, all of these are really just some easy one- time wins (can shave
> about 0.2 s maybe) and don’t give you any qualitatively different
> experience.
>
> For that something more is needed. If you are aot compiling, then
> aot+direct linking+lazy vars (patch is on the page you linked as an
> attachment) work together to load and run significantly less bytecode. If
> not aot, then the additional costs are primarily in reading and compiling
> (about 50/50) iirc. It’s unclear how to make those substantially faster.
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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: State & GUIs

[Nathan Fisher]

 Also take a look at re-frame (cljs) redux (js) libraries.
On Sat, 2 Dec 2017 at 10:18, Moe Aboulkheir  wrote:

> It may make sense to familiarise yourself with the architecture of a
> Clojurescript + React web application, if that's not something you've
> recently investigated.  Regardless of whether the techniques are directly
> applicable to your problem, I think the relationship between the state and
> the UI is something to aspire to.
>
> It may also be worth looking at https://github.com/halgari/fn-fx which is
> trying to do something similar with JavaFX.
>
> Take care,
> Moe
>
> --
> 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.
>
-- 
- sent from my mobile

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

Officially Supported JDKs?

[Nathan Fisher]

Hi All,

Curious what JDKs are officially supported?

Is it safe to assume the JDKs in Jenkins Clojure-test-matrix are the
officially supported jdks?

Is there any plans to deprecate support of EOL JDKs?

Cheers!
Nathan
-- 
- sent from my mobile

-- 
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: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

[Nathan Fisher]

It sounds like you have a memory leak. I would look at addressing that
before any performance tricks.
On Fri, 13 Oct 2017 at 05:35, <lawrence.krub...@gmail.com> wrote:

> Following Daniel Compton's suggestion, I turned on logging for GC. I don't
> see it happening more often, but the slow down does seem related to the
> moment when the app hits the maximum memory allowed. It had been running
> with 4G, so I increased that to 7G, so it goes longer now before it hits
> 98% memory usage, but it does hit it eventually and then everything crawls
> to a very slow speed. Not sure how much memory I would have to use to avoid
> using up almost all of the memory. I suppose I'll figure that out via trial
> and error. Until I can figure that out, nearly all other performance tricks
> seems a bit besides the point.
>
>
>
> On Thursday, October 12, 2017 at 9:01:23 PM UTC-4, Nathan Fisher wrote:
>
>> Hi!
>>
>> Can you change one of the variables? Specifically can you replicate this
>> on your local machine? If it happens locally then I would focus on
>> something in the JVM eco-system.
>>
>> If you can't replicate it locally then it's possibly AWS specific. It
>> sounds like you're using a t2.large or m4.xlarge. If it's the prior you may
>> very well be contending between with your network bandwidth. EC2's host
>> drive (EBS) is a networked drive which is split between your standard
>> network traffic and the drive volume. If that's the issue then you might
>> need to look at provisioned IOPs. A quick(ish) way to test that hypothesis
>> is to provision a host with high networking performance and provisioned
>> IOPs.
>>
>> Cheers,
>> Nathan
>>
>> On Fri, 13 Oct 2017 at 00:05 <lawrence...@gmail.com> wrote:
>>
>>> Daniel Compton, good suggestion. I've increased the memory to see if I
>>> can postpone the GCs, and I'll log that more carefully.
>>>
>>>
>>> On Wednesday, October 11, 2017 at 8:35:44 PM UTC-4, Daniel Compton wrote:
>>>
>>>> Without more information it's hard to tell, but this looks a like it
>>>> could be a garbage collection issue. Can you run your test again and add
>>>> some logging/monitoring to show each garbage collection? If my hunch is
>>>> right, you'll see garbage collections getting more and more frequent until
>>>> they take up nearly all the CPU time, preventing much forward progress
>>>> writing to the queue.
>>>>
>>>> If it's AWS based throttling, then CloudWatch monitoring
>>>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#using_cloudwatch_ebs
>>>>  might
>>>> show you some hints. You could also test with an NVMe drive attached, just
>>>> to see if disk bandwidth is the issue.
>>>>
>>>> On Thu, Oct 12, 2017 at 11:58 AM Justin Smith <noise...@gmail.com>
>>>> wrote:
>>>>
>>> a small thing here, if memory usage is important you should be building
>>>>> and running an uberjar instead of using lein on the server (this also has
>>>>> other benefits), and if you are doing that your project.clj jvm-opts are
>>>>> not used, you have to configure your java command line in aws instead
>>>>>
>>>>> On Wed, Oct 11, 2017 at 3:52 PM <lawrence...@gmail.com> wrote:
>>>>>
>>>> I can't figure out if this is a Clojure question or an AWS question.
>>>>>> And if it is a Clojure question, I can't figure out if it is more of a
>>>>>> general JVM question, or if it is specific to some library such as
>>>>>> durable-queue. I can redirect my question elsewhere, if people think this
>>>>>> is an AWS question.
>>>>>>
>>>>>> In my project.clj, I try to give my app a lot of memory:
>>>>>>
>>>>>>   :jvm-opts ["-Xms7g" "-Xmx7g" "-XX:-UseCompressedOops"])
>>>>>>
>>>>>> And the app starts off pulling data from MySQL and writing it to
>>>>>> Durable-Queue at a rapid rate. (
>>>>>> https://github.com/Factual/durable-queue )
>>>>>>
>>>>>> I have some logging set up to report every 30 seconds.
>>>>>>
>>>>>> :enqueued 370137,
>>>>>>
>>>>>> 30 seconds later:
>>>>>>
>>>>>> :enqueued 608967,
>>>>>>
>>>>>> 30 seconds later:
>>>>>>

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

[Nathan Fisher]

Hi!

Can you change one of the variables? Specifically can you replicate this on
your local machine? If it happens locally then I would focus on something
in the JVM eco-system.

If you can't replicate it locally then it's possibly AWS specific. It
sounds like you're using a t2.large or m4.xlarge. If it's the prior you may
very well be contending between with your network bandwidth. EC2's host
drive (EBS) is a networked drive which is split between your standard
network traffic and the drive volume. If that's the issue then you might
need to look at provisioned IOPs. A quick(ish) way to test that hypothesis
is to provision a host with high networking performance and provisioned
IOPs.

Cheers,
Nathan

On Fri, 13 Oct 2017 at 00:05  wrote:

> Daniel Compton, good suggestion. I've increased the memory to see if I can
> postpone the GCs, and I'll log that more carefully.
>
>
> On Wednesday, October 11, 2017 at 8:35:44 PM UTC-4, Daniel Compton wrote:
>
>> Without more information it's hard to tell, but this looks a like it
>> could be a garbage collection issue. Can you run your test again and add
>> some logging/monitoring to show each garbage collection? If my hunch is
>> right, you'll see garbage collections getting more and more frequent until
>> they take up nearly all the CPU time, preventing much forward progress
>> writing to the queue.
>>
>> If it's AWS based throttling, then CloudWatch monitoring
>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#using_cloudwatch_ebs
>>  might
>> show you some hints. You could also test with an NVMe drive attached, just
>> to see if disk bandwidth is the issue.
>>
>> On Thu, Oct 12, 2017 at 11:58 AM Justin Smith  wrote:
>>
> a small thing here, if memory usage is important you should be building
>>> and running an uberjar instead of using lein on the server (this also has
>>> other benefits), and if you are doing that your project.clj jvm-opts are
>>> not used, you have to configure your java command line in aws instead
>>>
>>> On Wed, Oct 11, 2017 at 3:52 PM  wrote:
>>>
>> I can't figure out if this is a Clojure question or an AWS question. And
 if it is a Clojure question, I can't figure out if it is more of a general
 JVM question, or if it is specific to some library such as durable-queue. I
 can redirect my question elsewhere, if people think this is an AWS
 question.

 In my project.clj, I try to give my app a lot of memory:

   :jvm-opts ["-Xms7g" "-Xmx7g" "-XX:-UseCompressedOops"])

 And the app starts off pulling data from MySQL and writing it to
 Durable-Queue at a rapid rate. (
 https://github.com/Factual/durable-queue )

 I have some logging set up to report every 30 seconds.

 :enqueued 370137,

 30 seconds later:

 :enqueued 608967,

 30 seconds later:

 :enqueued 828950,

 It's a dramatic slowdown. The app is initially writing to the queue at
 faster than 10,000 documents a second, but it slows steadily, and after 10
 minutes it writes less than 1,000 documents per second. Since I have to
 write a few million documents, 10,000 a second is the slowest speed I can
 live with.

 The queues are in the /tmp folder of an AWS instance that has plenty of
 disk space, 4 CPUs, and 16 gigs of RAM.

 Why does the app slow down so much? I had 4 thoughts:

 1.) the app struggles as it hits a memory limit

 2.) memory bandwidth is the problem

 3.) AWS is enforcing some weird IOPS limit

 4.) durable-queue is misbehaving

 As to possibility #1, I notice the app starts like this:

 Memory in use (percentage/used/max-heap): (\"66%\" \"2373M\" \"3568M\")

 but 60 seconds later I see:

 Memory in use (percentage/used/max-heap): (\"94%\" \"3613M\" \"3819M\")

 So I've run out of allowed memory. But why is that? I thought I gave
 this app 7 gigs:

   :jvm-opts ["-Xms7g" "-Xmx7g" "-XX:-UseCompressedOops"])

 As to possibility #2, I found this old post on the Clojure mailist:

 Andy Fingerhut wrote, "one thing I've found in the past on a 2-core
 machine that was achieving much less than 2x speedup was memory bandwidth
 being the limiting factor."


 https://groups.google.com/forum/#!searchin/clojure/xmx$20xms$20maximum%7Csort:relevance/clojure/48W2eff3caU/HS6u547gtrAJ

 But I am not sure how to test this.

 As to possibility #3, I'm not sure how AWS enforces its IOPS limits. If
 people think this is the most likely possibility, then I will repost my
 question in an AWS forum.

 As to possibility #4, durable-queue is well-tested and used in a lot of
 projects, and Zach Tellman is smart and makes few mistakes, so I'm doubtful
 that it is to blame, but I do notice that it starts off 

Re: How to try/catch Let bindings?

[Nathan Fisher]

You could use exceptions, is that a hard requirement or are you working to
transition your mental model for Java code to Clojure?

If you can catch the exceptions or not throw them to begin with there’s
some other options;

Another way you could do it is using core.async and channels as some others
have mentioned.

Yet another way would be using cats.

A similar solution to what the problem you described is outlined partway
through this article (there’s a lot there):

https://blog.skyliner.io/fourteen-months-with-clojure-beb8b3e4bf00

A friend of mine used to say “get it writ, then get it right”. As long as
you encapsulate the desired behaviour in the function you can try all of
the different suggestions and take a decision of what feels more readable
to you and others on your team.

On Sat, 30 Sep 2017 at 23:14, Didier  wrote:

> I'm curious how others handle this use case, which I feel should be pretty
> common.
>
> Given you have a series of business process steps, where the flow is too
> complex for the arrow macros, and you also like to name the step results
> descriptively, so you use let:
>
> (let [a (do-a ...)
>   b (do-b . a . .)
>   c (do-c . a . b)]
>   (log/info "Success" {:a a
>:b b
>:c c})
>   c)
>
> Now, say each steps could possibly throw an exception. So you want to
> try/catch the let bindings:
>
> (try
>   (let [a (do-a ...)
> b (do-b . a . .)
> c (do-c . a . b)]
> (log/info "Success" {:a a
>  :b b
>  :c c})
> c)
>   (catch Exception e
> (log/error "Failed" {:a a
>  :b b
>  :c c})
> (throw e)))
>
> But, inside the catch, you need access to the let bindings a,b,c, in order
> to recover from the failure, or like in my example, just to log so that
> debugging of the issue is easier.
>
> Now the catch will not be in scope of the bindings, and this won't even
> compile: "Can not find symbol a,b,c in context...".
>
> What would be the idomatic thing to do here?
>
> Is there another way to execute a set of complex steps which does not rely
> on let and can be try/catched in the manner I describe?
>
> Or is there a way to re-write the let that satisfies my case, and remains
> idiomatic, and does not add accidental complexities?
>
> Thank You.
>
> --
> 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.
>
-- 
- sent from my mobile

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

Re: ANN: ClojureScript 1.9.946

[Nathan Fisher]

Hi David!

I'm seeing an issue in one of my larger projects. Will try to isolate
tomorrow and get back to you.

The simple project in lein-cljsbuild works fine for me with beta1 and this
release.

Saludos!
Nathan

On Tue, 3 Oct 2017 at 22:52 David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.946"]
>
> This release contains many bug fixes and addresses feedback from the
> 1.9.908
> release. Important changes include parity with Clojure 1.9.0-beta1 and an
> updated Google Closure Compiler dependency. The later one in particular now
> means that ClojureScript has a dependency on JDK 8.
>
> As always feedback welcome!
>
> 1.9.946
>
> ### Changes
> * CLJS-2300: Delegate clojure.string/capitalize to goog.string/capitalize
> * CLJS-2374: Print js/Infinity, js/-Infinity, js/NaN using new reader
> literals
> * bump tools.reader (1.1.0)
> * CLJS-2372: update hash to use the new infinity literals
> * CLJS-2364: Bump Closure Compiler to the Sep 2017 version
> * CLJS-2340: Have js-keys delegate directly to good.object/getKeys
> * CLJS-2338: Support renamePrefix{Namespace} closure compiler option
>
> ### Fixes
> * CLJS-1576: fix source-map string encoding by applying encodeURIComponent
> and fixing string/replace call
> * CLJS-2294: Always use opts with implicit opts added
> * CLJS-2166: Add uri? predicate
> * CLJS-2368: Self-host: Never compile macro namespaces with
> `:optimize-constants true
> * CLJS-2367: Self-host: :def-emits-var leaks into loaded namespace
> processing
> * CLJS-2352: Emit valid JS for NaN etc. even when used w/ CLJ >=
> 1.9.0-alpha20
> * CLJS-2339: Significant code reload slowdown with :npm-deps
> * CLJS-2361: Self-host: circular dependency detection doesn't handle REPL
> self-require
> * CLJS-2356: Self-host: circular dependency detection is not correct
> * CLJS-2354: Self-host: `compile-str` doesn't handle `clojure` -> `cljs`
> aliasing
> * CLJS-2353: use portable `node-module-dep?` function in analyze-deps
> * CLJS-2345: escape paths emitted as args to cljs.core.load_file
> * CLJS-2349: Port reset-vals! and swap-vals! over from Clojure
> * CLJS-2336: Call alength once in areduce and amap
> * CLJS-2335: Avoid alength on strings
> * CLJS-2334: Also gather dependencies from foreign-libs that are modules
> * CLJS-2333: module-deps.js doesn't correctly compute `main` if aliased in
> browser field
> * CLJS-2332: module_deps.js doesn't process `export from` correctly
> * CLJS-2330: Don't set `"browser"` field for Closure if target is :nodejs
> * CLJS-2326: Indexing node_modules can't find `main` when it doesn't have
> an extension
> * CLJS-2328: Args are not provided to *main-cli-fn* with optimizations
> advanced
> * CLJS-2327: module_deps.js doesn't know about browser field advanced usage
>
> --
> 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.
>
-- 
- sent from my mobile

-- 
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: Help ship Clojure 1.9!

[Nathan Fisher]

Hi Stuart,

Looks like any project using lein-cljsbuild will be affected.

I forked and bumped the Clojure and ClojureScript version to latest and got
the same error with their simple project:

See Commit:
https://github.com/nfisher/lein-cljsbuild/commit/5df5d3c5bb447b51a75abbbccdc72447814883a0

STR

1. git clone https://github.com/nfisher/lein-cljsbuild
2. cd lein-cljsbuild/example/projects/simple
3. lein cljsbuild once

Patch attached if you want to apply directly to
https://github.com/emezeske/lein-cljsbuild

Cheers,
Nathan

On Thu, 28 Sep 2017 at 16:13 Stuart Halloway <stuart.hallo...@gmail.com>
wrote:

> Hi Nathan,
>
> I suspect that is the same as
> https://github.com/clojure/clojurescript/commit/89914d2ead964122f99e638edda0cd96d330cb66.
> I don't have a sense of how many CLJS project this is going to cascade
> into, or what all will be needed. Anyone?
>
> Stu
>
> On Thu, Sep 28, 2017 at 10:44 AM, Nathan Fisher <nfis...@junctionbox.ca>
> wrote:
>
>> Hi Stuart,
>>
>> Working to create a minimal test case but upgrading from alpha19 to beta1
>> seems to have broken lein-cljsbuild.
>>
>> I get the following error:
>>
>> >>>>>> snip >>>>>>
>>
>> *SEVERE:
>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579:
>> ERROR - Parse error. primary expression expected*
>>
>> *case ##Inf:*
>>
>> *  ^*
>>
>>
>> *Sep 28, 2017 3:23:10 PM com.google.javascript.jscomp.LoggerErrorManager
>> printSummary*
>>
>> *WARNING: 1 error(s), 0 warning(s)*
>>
>> *ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at
>> /Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js
>> line 3579 : 6*
>> <<<<<< snip <<<<<<
>>
>> Changes in my project.clj deps are as follows:
>>
>> *- [org.clojure/clojure "1.9.0-alpha19" :scope "provided"]*
>>
>> *+ [org.clojure/clojure "1.9.0-beta1" :scope "provided"]*
>>
>> A revert on my project.clj to alpha19 eliminates the error.
>>
>> Cheers!
>>
>> Nathan
>>
>> On Thu, 28 Sep 2017 at 15:00 Stuart Halloway <stuart.hallo...@gmail.com>
>> wrote:
>>
>>> Clojure 1.9 has been quite stable throughout the alpha period, and we
>>> now hope to release after a very short beta. Please test your existing
>>> programs on the latest beta (see below), and respond on this thread ASAP if
>>> you discover anything you believe to be a regression.
>>>
>>> Thanks!
>>> Stu
>>>
>>> ;; Clojure deps.edn
>>> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>>>
>>> ;; lein & boot
>>> [org.clojure/clojure "1.9.0-beta1"]
>>>
>>> --
>>> 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.
>>>
>> --
>> - sent from my mobile
>>
>> --
>> 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 

Re: Help ship Clojure 1.9!

[Nathan Fisher]

Hi Stuart,

Working to create a minimal test case but upgrading from alpha19 to beta1
seems to have broken lein-cljsbuild.

I get the following error:

>> snip >>

*SEVERE:
/Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js:3579:
ERROR - Parse error. primary expression expected*

*case ##Inf:*

*  ^*


*Sep 28, 2017 3:23:10 PM com.google.javascript.jscomp.LoggerErrorManager
printSummary*

*WARNING: 1 error(s), 0 warning(s)*

*ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at
/Users/nathanfisher/workspace/mklpq/target/cljsbuild-compiler-0/cljs/core.js
line 3579 : 6*
<< snip <<

Changes in my project.clj deps are as follows:

*- [org.clojure/clojure "1.9.0-alpha19" :scope "provided"]*

*+ [org.clojure/clojure "1.9.0-beta1" :scope "provided"]*

A revert on my project.clj to alpha19 eliminates the error.

Cheers!

Nathan

On Thu, 28 Sep 2017 at 15:00 Stuart Halloway 
wrote:

> Clojure 1.9 has been quite stable throughout the alpha period, and we now
> hope to release after a very short beta. Please test your existing programs
> on the latest beta (see below), and respond on this thread ASAP if you
> discover anything you believe to be a regression.
>
> Thanks!
> Stu
>
> ;; Clojure deps.edn
> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>
> ;; lein & boot
> [org.clojure/clojure "1.9.0-beta1"]
>
> --
> 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.
>
-- 
- sent from my mobile

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

[Nathan Fisher]

Hi Alex,

Understood, thanks for the quick reply! I recently came across Steve
Yegge's rant on Clojure accessibility to newbies and was reflecting on how
it could be improved. Thought it was a little thing but could be a nice
addition to ease people in and give them a flavour for the language.

Totally understand that a home page is an important space and you don't
want the kitchen sink thrown in peoples faces. :)

Cheers!
Nathan

On Fri, 22 Sep 2017 at 16:57 Alex Miller <a...@puredanger.com> wrote:

> It's there at: https://github.com/clojure/clojure-site
>
> We considered this when building the site and decided not to include it on
> the front page, so probably not interested in including it now. I expect
> we'll look at front page updates at some point though and we'll consider it
> again.
>
> Alex
>
>
> On Friday, September 22, 2017 at 10:51:18 AM UTC-5, Nathan Fisher wrote:
>>
>> Hi All,
>>
>> I'm probably dense but I didn't see the source for clojure.org on
>> https://github.com/clojure. It looks like it's served out of S3 based on
>> at the response headers so I'm guessing it's a static site of some sort...
>>
>> While I don't necessarily subscribe to "everyone else is doing it" I was
>> thinking it would be nice to add a sample snippet of "hello world" code on
>> the home page similar to Go and Ruby's site. I'd see it placed just above
>> the "Learn More" section.
>>
>> I wanted to make a PR with a snippet like:
>>
>> (ns cool.clojure
>>   (:gen-class))
>>
>> (defn -main []
>>   (prn "Hello world!"))
>>
>> Underneath it could link to a page "so you've decided to learn Clojure
>> here's how you map common idioms from OO/imperative to Clojure" obviously
>> it'll need something a little snappier.
>>
>> Kind regards,
>> Nathan
>>
> --
> 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.
>
-- 
- sent from my mobile

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