@bronsa In case you want to get rid of some refer :alls in tools.reader: https://twitter.com/borkdude/status/1154319272539295744/photo/1 🙂

I'll add sorting to that message

@borkdude the refer :alls are there for a good reason :)

t.r supports older versions of clojure, providing custom versions of missing features

there are vars in the util namespace that are only present in those older versions, so we can't refer them statically

aha.

to be honest, there's probably little point in supporting those older versions of clojure nowadays, so may aswell bump the minimum requirement and get rid of that ugly hack

would mean bumping minimum supported version from 1.4 to 1.7

I think that should be fine, I'll check with Alex later

1.7 was released in June 2015, which means a 4 year old version. Seems reasonable.

IIRC the stats for people on <= 1.7 are in the low single digits if at all

Question Q15 on the 2019 Clojure survey showed 3.3% on 1.7 or earlier. It did not break down within that: https://www.surveymonkey.com/results/SM-S9JVNXNQV/

thank you @andy.fingerhut

A while back I stopped matrix testing all contribs on anything older than 1.7

Did anyone have an issue with tools.deps crashing when specifying Timbre log level in a system property? The failing code is inside tools.deps. https://github.com/ptaoussanis/timbre/issues/294

that's pack calling into tools.deps, so could be pack too

clj is using latest tools.deps here, but pack is calling into an older version 0.6.496 from March. that should be fine, just pulling the thread.

hmm, pack needs a deps.edn file, the above script provices inline deps

same error with a local deps.edn file

Thanks @viesti Yes, it's the same error with local file. I've updated the issue now though (echo > deps.edn)

And thanks Alex

I'd bet on :paths ["."] causing trouble

works with :paths ["src"] with a src/myapp/main.clj and -m myapp.main for pack invocation

mkdir -p src/run_app || true
echo '(ns run-app.main) (defn -main [& _] (println "Hello world"))' > src/run_app/main.clj
echo '
{:paths ["src"]
 :deps {com.taoensso/timbre        {:mvn/version "4.10.0"}
        com.fzakaria/slf4j-timbre  {:mvn/version "0.3.14"}
        org.slf4j/log4j-over-slf4j {:mvn/version "1.7.14"}
        org.slf4j/jcl-over-slf4j   {:mvn/version "1.7.14"}
        org.slf4j/jul-to-slf4j     {:mvn/version "1.7.14"}
        pack/pack.alpha            {:git/url    ""
                                    :sha        "9911c70bcfd6e94383d3d54b6e8befa492222926"
                                    :exclusions [org.slf4j/slf4j-nop]}}}' > deps.edn

clojure \
-J-DTIMBRE_LEVEL=warn \
-Sverbose \
-m mach.pack.alpha.jib \
--verbose \
--quiet \
--image-name ivarref/demo:latest \
--image-type docker \
-m run-app.main

ah, forgot the -J-DTIMBRE_LEVEL=warn \ here

Yes that is causing the issue...

were you trying to pass -DTIMBRE_LEVEL=warn into the container?

No, into the build process

If you remove it, you will get tons of DEBUG output from apache stuff

that is because of --verbose

No, removing --verbose and keeping --quiet still gives e.g.: 19-07-25 13:53:38 nsd367 DEBUG [org.apache.http.impl.client.DefaultHttpClient:509] - Connection can be kept alive indefinitely

hmm...

-Sverbose

why is that there? 🙂

Also happens without -Sverbose... That is for printing Clojure versions

+ clojure -m mach.pack.alpha.jib --quiet --image-name ivarref/demo:latest --image-type docker -m run-app.main
+ wc -l
516

Timbre sets the logging level to DEBUG by default

interesting 🙂

hmm, so the logging deps in :deps bleed to the pack invocation

not sure if it is timbre, but somehow logging setup defaults to being verbose

you can prevent bleeding by putting the application dependencies behind an alias, and pass that to pack invocation

something like:

{:paths ["src"]
 :aliases {:pack {:extra-deps {pack/pack.alpha            {:git/url    ""
                                                           :sha        "9911c70bcfd6e94383d3d54b6e8befa492222926"}}}
           :main {:extra-deps {com.taoensso/timbre        {:mvn/version "4.10.0"}
                               com.fzakaria/slf4j-timbre  {:mvn/version "0.3.14"}
                               org.slf4j/log4j-over-slf4j {:mvn/version "1.7.14"}
                               org.slf4j/jcl-over-slf4j   {:mvn/version "1.7.14"}
                               org.slf4j/jul-to-slf4j     {:mvn/version "1.7.14"}}}}}

clojure \
    -A:pack \ <-- alias where pack itself lives
    -m mach.pack.alpha.jib \
    --image-name foo/demo:latest \
    --image-type docker \
    -A main \  # <-- tell pack which aliases to include
    -m myapp.main

two hard things, naming, logging setup

Namings things: Hehe... Thanks @viesti Yes, I think the error here is that the default deps bleed back to the pack invocation. So this is a pack.alpha issue I guess. I will have a closer look tomorrow at work. Thanks for the input.

Kiitos Kimmo!

:D thanks!

Driving Clojure and Finnish onwards to the world :)

pack dep itself is best to put behind an alias, to not include it into the application dependencies

I have the following under :plugins in my ~/.lein/profiles.clj: [lein-clique "0.1.2" :exclusions [org.clojure/clojure]] Regardless, when I run lein clique within my project, I get the following errors:

Warning: implicit hook found: lein-environ.plugin/hooks
Hooks are deprecated and will be removed in a future version.
Generating dependency graph for  /Users/chris/dev/clojure-sso/src/clojure
WARNING!!! version ranges found for:
[lein-clique "0.1.2"] -> [lacij "0.8.0"] -> [org.clojure/clojure "[1.2.0,)"]
Consider using [lein-clique "0.1.2" :exclusions [org.clojure/clojure]].
[lein-clique "0.1.2"] -> [lacij "0.8.0"] -> [tikkba "0.4.0"] -> [org.clojure/clojure "[1.2.0,)"]
Consider using [lein-clique "0.1.2" :exclusions [org.clojure/clojure]].
[lein-clique "0.1.2"] -> [lacij "0.8.0"] -> [tikkba "0.4.0"] -> [org.clojars.pallix/analemma "1.0.0"] -> [org.clojure/clojure "[1.2.0,)"]
Consider using [lein-clique "0.1.2" :exclusions [org.clojure/clojure]].

Exception in thread "main" Syntax error macroexpanding clojure.core/ns at (clojure/tools/namespace/find.clj:9:1).
Call to clojure.core/ns did not conform to spec.
	at clojure.lang.Compiler.checkSpecs(Compiler.java:6971)
	at clojure.lang.Compiler.macroexpand1(Compiler.java:6987)
	at clojure.lang.Compiler.macroexpand(Compiler.java:7074)
	at clojure.lang.Compiler.eval(Compiler.java:7160)
	at clojure.lang.Compiler.load(Compiler.java:7635)
[...]

the spec error is at clojure/tools/namespace/find.clj:9:1, which is in org.clojure/tools.namespace

that is a known issue, fixed long ago

I expect one of your deps or plugins is using an old version of tools.namespace

lein deps :tree might help track it down

and if you need to get past it to be able to track it down, you can turn off macro spec checking with the jvm option -Dclojure.spec.skip-macros=true

you'd set this in project.clj under :jvm-opts

i'm guessing it must be an issue in lein-clique's deps, seeing as i don't have a similar issue when compiling my project. is there something analogous to lein deps :tree for the plugin rather than the project?

i guess maybe if i cloned the plugin repo and ran it inside as a project

@bronsa I take this as a yes: https://clojurians.slack.com/archives/C03S1KBA2/p1564058589189000

@csd lein help deps shows lein deps :plugin-tree

@csd what's the reason you want a graph of namespaces, just out of curiosity

including a newer version of tools.reader in a profile might help and then call clique with lein with-profiles +tools.reader clique

congrats on the new forum. I cast my first vote: https://ask.clojure.org/index.php/740/locking-macro-fails-bytecode-verification-native-runtime I see this thing is built in PHP, is it an off the shelf SO clone?

yeah, it's an oss thing

probably pre-dates SO :)

what is the name of this product?

question2answer

https://www.question2answer.org/

nice

who downvoted that issue! 😠 😉

me 🙂

it's not enough to fix Graal

I'll have a chance to talk to the native-image people on Tuesday -- I have a lot of questions

Happy to bring along any questions anyone has, too

I think you're approaching it from the wrong direction. Not everything in Clojure is possible in Graal, but some things are fixable.

Ghadi is but one vote. Make your voice known... :)

^

e.g. now you cannot use spec or pprint in a graalvm binary due to the locking issue. but still a lot of useful things work can be made with it

are votes in that system prioritised over the ones in JIRA?

this is a place for users to vote

we look at many things when deciding what to do

so neither is prioritized over the other; they are both inputs

is this forum an official thing ?

oh indeed

Yes

Is the forum kept up to date with jira? e.g. when a new jira ticket is created a new question (?) is opened? and when the same jira is resolved, the question becomes resolved? Are jira comments also mirrored?

no, not linked in either direction, was just seeded

the idea is that users will add problems and enhancements on https://ask.clojure.org

as needed, we'll turn new issues into jiras

is there any way to filter for unanswered questions? that’s a fun way for people to help out

yes, there are filters on the questions page

oh, actually maybe there isn't there

is this going to replace the current https://clojure.atlassian.net/servicedesk/customer/portals ?

Ah. Previously I was subscribed to a number of jira issues to know when they got merged in, what people were saying, etc. I found that quite useful. Is there a way to do that?

boom, now unanswered tab: https://ask.clojure.org/index.php/unanswered

@kenny yes, you can star a question to "watch" it

Further, given jira and ask are not linked, how do users vote on issues to inform decisions about future releases?

then go to https://ask.clojure.org/index.php/favorites

But jira and ask aren't linked, right?

vote on ask

they are not linked in either direction, other than manually

it's possible that could change

If they aren't linked then how do you keep up to date with the jira changes?

you can't automatically get that (other than by looking at the jira page)

I think by watching the JIRA issue.

as before

Right - I used that a lot before. Quite useful.

you can't watch the jira issue as most people will not have an account

the idea is most of the traffic will be on ask

Well, you know, for the super-elite that get a free Clojure JIRA account 🙂

The smiley there was because there is nothing super-elite about it, in case that wasn't clear

we only get a fixed number of those - we are trying to build a system here for users (without a CA or a JIRA account) to ask questions, register problems, vote on them, etc

It seems important for users to be kept up to date with what is going on in the jira.

well, that's not a problem we're going to solve right now

the ask page will have a link to the jira page

Ok. Just voicing that I think that is important 🙂 Also seems like if a jira is created, an ask should automatically get created to ensure users have a way to vote on the jira.

also not something we're going to solve right now

relax your hold on jira :)

Haha, I just like following along. Helps inform decisions.

Alex while you’re removing Jira from my free time could you go ahead and remove it from my day job as well?

no, I cannot

rats

i worry about the visibility to the clojure team of issues raised in that forum

I am watching it like a hawk :)

=)

or a shark

I am certain that this will not be the last change we ever make in managing Clojure development

move to gitlab confirmed

bitbucket

integrated jira :)

savannah.gnu

shudders in freedom

time to switch to CL i guess =)

clojure's source was in sourceforge at one time, and issues in assembla

maybe import SO questions into the new QA site? https://www.brentozar.com/archive/2018/06/new-stack-overflow-public-database-available-2018-06/

I’m going to take a break from ask and work on spec 2 for a while :)

But if someone was real excited about it, I’d be happy to give you a tabular data format to target

would be cool, maybe even the vote could be preserved

it seems a fun task for someone who wants to practice their Clojure skills. you could post an issue with specs (!) somewhere and then make a link in: https://clojureverse.org/t/about-the-starter-issues-category/4593

or just JIRA and then someone will read it on the new QA site 🙂

Does SO frown on such scraping and reusing of their data elsewhere, in bulk like that? Link to their official policy in that regard, if anyone knows of one, welcome.