This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-13
Channels
- # admin-announcements (6)
- # beginners (51)
- # boot (164)
- # braid-chat (49)
- # cider (10)
- # clara (17)
- # cljs-dev (13)
- # cljsjs (51)
- # cljsrn (10)
- # clojars (42)
- # clojure (195)
- # clojure-bangladesh (102)
- # clojure-berlin (8)
- # clojure-canada (1)
- # clojure-chicago (19)
- # clojure-colombia (4)
- # clojure-denmark (6)
- # clojure-russia (15)
- # clojure-ukraine (7)
- # clojurescript (257)
- # code-reviews (10)
- # community-development (292)
- # core-async (13)
- # datomic (26)
- # dirac (4)
- # dunaj (5)
- # dysphemism (5)
- # events (21)
- # funcool (15)
- # hoplon (115)
- # instaparse (31)
- # ldnclj (15)
- # mori-fork (43)
- # mount (5)
- # off-topic (18)
- # om (195)
- # onyx (13)
- # proton (9)
- # re-frame (11)
- # reagent (44)
- # slack-help (14)
- # slackpocalypse (1)
- # spacemacs (10)
- # yada (23)
But after trying to evaluate that same expression in the repl, it returns the correct result and my program works again
I can only assume my clojure src was compiled before the environ task executed, but environ is my first task
@jethroksy: are you using the serve task? Environ only sets things in the current pod and serve uses a fresh one
I havent pushed the db code up yet, although it's very much like the yesql example code
Hm, not seeing anything obviously wrong @jethroksy
Hmm, I remember an issue like that, but I'm not sure what I did about it; if I remember I'll let you know.
Here's my simple sample project for reference: https://gitlab.com/jaen/panda5/blob/master/code/panda-5/src/panda_5/core.clj (function to create system) https://gitlab.com/jaen/panda5/blob/master/code/panda-5/src/panda_5/config.clj (function to get config)
Well, I don't think it plays well with component, I don't remember there being a way to specify connection at query time.
Yeah, it would. You generate SQL with honeysql and querying is on you then, using either clojure.java.jdbc or clojure.jdbc (I suggest the latter, it's nicer).
I'm not 100% sure why environ map wouldn't be available at read time either, since that's when it is created; maybe it's order of initialisation? But that doesn't sound right. Either way I'm pretty sure creating the system maps at runtime with a function should solve this.
But I've found this - https://github.com/luminus-framework/conman
Oh, I think it was HugSQL - http://www.hugsql.org/
Also, convenience link to clojure.jdbc - https://github.com/funcool/clojure.jdbc - though I remember I had slight problems when using it with joplin for migrations and had to do a bit of alter-var-root
magic.
Hah, the answer is - I don't know. It seems like something that should be doable at read-time, but since moving it into a function fixed it I never bothered to figure out what's the reason the map comes up empty if you use it at read-time.
Also consider how it would interact with AOT - if value is set at read-time you would have to AOT with proper configuration in place already, which might be less than ideal.
Well, you are in so far as you're using :gen-class
, but maybe that's a non-issue. So far I never needed to AOT more than the main class.
I suspect a library conflict but how can I find out if boot show -d gets the exception as well ?
@pandeiro: I'd expect it to
@martinklepsch: ok thanks, i'm debugging something on circle but I just wanted to make sure I understood the expected behavior
it should, and does
can you share your build.boot? i would guess you are requiring code that requires core.cache, hitting the conflict while build.boot is running
to circumvent you could comment out any requires
and run boot show -d
@yenda: so in this situation... the normal route is to figure ou twhich version of core.cache works for both your purposes and ring middleware format's
since clojure libraries are usually backward compatible... especially core ones... i would start with [ring-middleware-format "0.7.0" :exclusions [org.clojure/core.cache]]
an alternative is to not bring in your own version, and instead rely on the one brought in by ring-middleware-format
a 3rd option is to do whatever you need to do with your specific core.cache version in a pod
since you could create a pod with different dependencies as the rest of your app, circumventing the conflict
sorry when I said "well I just added [org.clojure/core.cache "0.6.4"] to the dependencies" I meant that it worked that way
so I suppose ring-middleware-format is missing this library and yet requires it to work
thank you for your help though, I need to learn how to use pods someday it seems interesting
sure. they're kind of the nuclear option, but it's worth knowing that you can use them beyond build time
i used them once to manage multiple versions of the AWS SDK in an app at runtime
and yeah - it looks like middleware-format depends on core.cache transitively via core.memoize
is bootlaces not compatible with boot 2.5.5 or was there some other reason for not using it anymore in boot-cljs?
@juhoteperi doesn't like it 😛
@pandeiro: It is compatible but not necessary as Boot can handle clojars credentials easily now
I keep using it because I really like that it handles the readme version thing
oops, vimperator fail
@martinklepsch: i still love that too
@martinklepsch: feel free to make whatever modifications to bootlaces you want
@micha: I'm happy with it as is I think
but yeah, might be time to throw some of it over board
@meow: boot windows support should be much better on older windows now than it was before
@micha: oh, good. I'm moving to a different system tomorrow but at the moment I'm on Windows Vista - I know, kinda scary, right? And you know I ❤️ and can't or without it
haven't upgraded in a while so can't say for sure about the latest and I won't have time to test it for you as I'm super, super, super busy
trying to work on some of these for clojars: https://github.com/clojars/clojars-web/labels/ready
C:\Users\Patrick\code> boot -v
Acquired java.util.concurrent.Semaphore@ed4f4b[Permits = 0]...
Released java.util.concurrent.Semaphore@ed4f4b[Permits = 1]...
Boot App Version: 2.2.0
Boot Lib Version: 2.2.0
Clojure Version: 1.7.0
I would be willing to trade the testing of boot on Windows Vista for help with those easy tickets for Clojars
Not at the moment, but they did happen from time to time. But if so that would be caused by :parallel-build true
itself, not boot-cljs
if I understand correctly.
ah ok; yeah, right... I had heard the parallel-build was thread-safe as of 228 but I'm still seeing those warnings...
Well, one thing is whether the parallel build code is thread-safe, another is whether the dependency graph has enough constraints that compilation doesn't get reordered so that you end up with undeclared vars.
@pandeiro: what I mean is in order to parallelize the build the compiler needs to find parts of dependency graph that can be compiled separately, right?
But if the constraints you create through require
and such don't adequately describe dependencies between namespaces, it can reorder the compilation such that something a namespaces uses won't be defined yet.
At least that's how I understand the root issue behind Undeclared var
with parallel compilation is, as discussed on #C03S1L9DN at some point.
I am currently on a Windows Vista machine and can test the latest boot
C:\Users\Patrick\code> boot -V
#
#Wed Jan 13 11:36:50 CST 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.5.5
the -C / --no-colors option should get rid of them
@meow: i am good, thanks - how you doin?