This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
$ boot show -e
{:watcher-debounce 10,
:dependencies
[[org.clojure/clojure "1.7.0" :scope "provided"]
[adzerk/bootlaces "0.1.11" :scope "test"]
[adzerk/boot-cljs "1.7.48-2" :scope "test"]
[adzerk/boot-reload "0.3.2" :scope "test"]
[adzerk/boot-test "1.0.4" :scope "test"]
[adzerk/cljs-console "0.1.2" :scope "test"]
[org.clojure/clojurescript "1.7.48" :scope "test"]
[hoplon/javelin "3.8.4"]],
:directories
#{"/home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw/gg42n1"
"/home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw/7o2s6s"
"/home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw/-5nd64l"
"/home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw/-c4hx1l"},
:source-paths #{},
:resource-paths #{"src"},
:asset-paths #{},
:target-path "target",
:repositories
[["clojars" " "]
["maven-central" " "]]}
all the tempdirs will be under the /home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw
subtree
@micha: thanks for the tips; I can't seem to be able to find that file there for some reason though.
@micha: you substitute :output-to
in compiler opts to make it output to the temp dir, yes?
@jaen: what is the problem you are encountering?
you said it blows up 😉
@micha: so I guess I'll have to look at the source and/or try to attach a debugger to boot to figure out what I'm doing wrong with this, probably something I did behaves unexpectedly when it gets a dir like that. Thanks again for the help.
@flyboarder: long story short I made Clojurescript compiler output some additional files and it works fine when using the quickstart compilation method, but when I tried it through boot just now it blows up saying there's no such module.
@jaen: so are you trying to include this in a boot task?
can you post a snip of your task?
you're injecting your version of cljs compiler by specifying it as a dependency instead of the regular one, i suppose?
I think I just must have botched the way I update :libs
vector so it doesn't work with how boot works
see here https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L17-L22
and https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L108-L112
you can see when it builds the pod it will have both your cljs compiler and the regular one
it's also kind of unkosher to distribute the same classes/namespaces under different artifact ids
It probably is, but I can't really push to org.clojure.clojurescript
and it's kind of easier than have to check out from git and build it.
nobody could figure out which versions of various things worked with which other versions
so things were hardcoded into the task to at least warn you when things probably wouldn't work
As for the suggestion, yeah I suppose that could work so I can at least see if the behaviour is caused by clashing jars or by me doing something wrong
if you find that the problem was clashing jars, you can just fork boot-cljs and change that one place where it refers to org.clojure/clojurescript
Basically I'm trying to stuff this into the compiler - https://github.com/jaen/custom-module-loaders. Extending Maria Geller's module work from single files to whole libraries.
Changes to Clojurescript and GClosure are respectivele here - https://github.com/jaen/clojurescript/tree/feature/add-modular-lib-support - and here - https://github.com/jaen/closure-compiler/tree/feature/custom-module-loaders - but it's still mostly a spike to look around how all the moving parts fit, not anything that could be considered of good quality.
There's not much to it ; d But last time I checked the example actually did work. Right now I'm trying to be able to use reagent with raw React and it just occurred to me I could try and see if it would work with boot instead of the quickstart method
do you need to use the artifacts you made in clojars or can you just hack cljs and install locally?
Actually that was just for convenience, it's easier to point people to jars than have them get a couple of repos, compile that and so on. So not much problem with just installing this locally, really.
Hm - no, it didn't help unfortunately. I must have messed something up in my code. I'll have to hook Cursive into that or something to figure out what's going on. Thanks for all the help though
@micha: in the end I've gotten it working - first, I had some errors in my code in the end, then I tried to do lein install
on clojurescript, but it still tried to download the (nonexistent) jar from org.clojure/clojurescript
, so I forked boot-cljs
and did the changes you've suggested and it sorta got it working, at least up to the point where it turns out that absolute paths in :libs
wont' fly ; d
@jteneycke: :advanced
takes a long time, consider :simple
for faster single-file compilation during development. Also it’s probably worth trying to get :none
to work.
@jteneycke: depending on how you serve your files :asset-path
can probably help
Yeah, I’m just starting to wrap my head around it. Currently using :simple so it spits out a single file and doesn’t use the async loading, so I don’t have to worry about figuring out how to add it to my asset pipeline in Rails.
@jteneycke sweet!
I’v been holding out on React for so long because I wanted to use Haml for my component templates, but living in the land of the sexp is soooo much better.
Just gotta navigate to the lib/assets/cljs folder to run “boot dev”, and then bundle and setup your rails server like normal.
I’ve got a horrendous legacy rails app that I’ve been meaning to demolish the homespun js madness and replace with react, but I’ve been spoiled by Haml and JSX is an abomination. 😉
@jteneycke: for HAML you can jsut use boot-middleman
Yeah, I saw that. Very cool. Not sure how that would help me in a legacy Rails context tho.
But it plays pretty nice with kioo, so you can use something sane for the templates like HAML
i bet there are a lot of people wanting to extract themselves from a similar situation, your setup would save lives
Yeah, I’ll do that. I think this is going to be my last Rails project. Quite sick of the monolith spaghetti jquery piles. :poop:
The Rails Way seems to encourage tightly coupled applications that just keep on getting more unmaintainable as time goes. There totally can be nice code in Ruby/Rails it's just that stock Rails doesn't really encourage it.
First thing I do when I “rails new” is nuke half the gems and replace the other half.
http://www.quickmeme.com/img/ca/ca352cd3358c682d99a8f482fab5611d07eb83872cf71ac78ab64c1d453550c5.jpg
@jteneycke good work! thanks for taking the time to do that
Good night; sleepless compulsive hacks seems like I theme, that cljs compiler + boot issue kept me awake until 0500 hours ; d
@micha: hmm, should I even be using :output-to
and :asset-path
with boot-clljs
? At some point I noticed it ignores :output-dir
and just outputs to build-id.out
.
@jaen: You can use :asset-path
but boot-cljs does indeed overwrite :output-dir
and :output-to
@juhoteperi: What should the :asset-path
be then? Say I have my application.cljs.edn
in resources/public/assets/javascripts/application.cljs.edn
, should :asset-path
(assuming I serve resources/public
be then assets/javascripts
or assets/javascripts/build-id.out
?
In the second case I assume it should be then set per cljs.edn
file in :compiler-options
of the edn, right?
"assets/javascripts/build-id.out"
Yeah it should be set per .cljs.edn file
We hope to implement some easier way to set this more easily in future
Yeah, setting a root path for resources and boot-cljs
appending build output suffix would be nice
It would be a quick fix
But another problem is that boot-reload needs to also know the asset-path
And possibly other tasks also
So we want to have some general way to set the asset-path (or something similar) so that all tasks can use the same method
Would another task be able to pass options on to boot-cljs
task or would it have to wrap it completely?
Other tasks can read and modify .cljs.edn
So say, I would be able to write a task that reads package.json
, gets npm to resolve all the libraries and then add them to :libs
keys, yes?
@juhoteperi: small perun/pegdown question: I just cleared pegdown from my .m2 then installed pegdown with sbt publish-m2
, checked it’s properly installed. then running my stuff no other version of pegdown is downloaded but still I get the errors about things like aside
not being recognized. Any ideas what I could be missing?
@jaen: that sounds possible
@martinklepsch: Did you update pegdown dependency in all the necessary places?
= endophile
I think so. Also there is no Retrieving …
message about other versions being downloaded + no other versions of pegdown in .m2
If that sounds possible then nice, I'll have to investigate that after I get CommonJS libraries working completely. Any task on github that does something similar I could check out?
This should be enough I guess but I also made a new endophile jar depending on 1.6.0 explicitly
Yeah looks proper
@jaen: reload and repl tasks modify cljs.edn files
pegdown should have a test for aside so it should work
@martinklepsch: thanks, I'll take a loot at those then
@juhoteperi: fwiw, I just saw that they released 1.6.0 but the issue persists
Lol sbt is slow
started running publish-m2 4min ago and still going 😄
Retrieving pegdown-1.6.0.jar from https://repo1.maven.org/maven2/ Processing Markdown: 2013-09-24-A-Trip-To-The-US.markdown line 1 column 8 - Error: <aside> is not recognized!
all tests pass though o.O
Yeah I can reproduce this
I wonder if it's pegdown or endophile
@juhoteperi: I can’t find the word recognized
in pegdown, parboiled or endophile
@martinklepsch: Aside works for me in endophile
Endophile dev version is 0.2.0-SNAPSHOT
Update perun to use that and it should work
Works for me
@juhoteperi: that indeed works. Thanks a ton!
maybe I can get my blog migrated today
I try to get new endophile released
The other PR works with the new pegdown
@micha: version comparison functions
version-clj looks the best option
i was also thinking we might want to make a section of the boot wiki for things like .cljs.edn, similar to https://github.com/mmcgrana/ring/blob/master/SPEC
New namespace for wrappers sounds good
@micha/@deraen: since removing Clojurescript in adzerk.boot-cljs/deps
helped me, would you want a patch to add an option to the cljs task to optionally disable the injection?
I would be open for some change for automatic cljs dep injection
the reasons for the version stuff is because depenedncies of this type, eg. framework deps, are hard to manage
One idea I had would be to only check artifactId
so the only way to know hwich version you're going to get is to explicitly depend on cljs in your project deps
but this isn't great because now you have that hairy dependency in your project, and you probbly only need it in the pod where you're compiling cljs
so i was thinking maybe to use the :exclusions
key in set-env!
to globally exclude cljs
Hmm global exclusions sound useful
like if boot-cljs sees that cljs.core
namespace is on the classpath it could assume that you added your own cljs dependency
and it could then forgo the version checks because you presumably know what you're doing
I was thinking about that but what would be good way to check if ns exists?
also if we enforce the cljs compiler version in boot-cljs we don't need as much of the warning code
That would have to be run in the pod
Either having a check for cljs.core
(but wouldn't that not solve the transitive dep problems?) or forcing a version by `exclusion/injection combination seem reasonable, but in either case having a flag saying "trust me boot, I added clojurescript" would be handy (lik in this obscure case I had here)
so currently we strongly recommend that users specify an explicit cljs dependency in their project
what do you mean "let boot-cljs handle the compiler dependency"?
so if the user does (set-env! :exclusions #{'org.clojure/clojurescript} :dependencies '[[...] ...] ...)
then we know that no cljs dependency will be on the classpath unless they are doing something special like what jaen was doing
But won't that result in the two compiler problem as the code is now? At least I don't see it checking to not inject clojurescript
, so it seems to me that if you have a clojurescript dep you'll end up with two.
Okay so, boot-cljs would always add dependency to specific cljs version unless there is exclusions which removes that?
Would make sense
Then we wouldn't need to even do any version comparisons
@juhoteperi not exactly, but yes i think it would eliminate version checking
i think if we document :exclusions
as mandatory boot-cljs can assume one of two cases exists:
if cljs.core
is on the classpath then we know that jaen is trying an experiment, and boot-cljs doesn't add any cljs dependency of its own
if cljs.core
isn't on the classpath then boot-cljs can safely add org.clojure/clojurescript
to the pod deps, with the correct version
it would be a good idea to have a warning if cljs.core
is on the classpath, in case someone forgot to add the :exclusions
I think boot-cljs should work without warnings in case user has direct dependency on cljs
It's perfectly fine to use newer test version of cljs
1. org.clojure/clojurescript
in project (nontransitive) deps --- do nothing, user knows what they're doing
3. cljs.core
not on classpath, org.clojure/clojurescript
not in project deps --- add cljs dep to pod
Sounds right
Do we need the version comparison utils now? 😄
@micha: that means that I should leave out a explicit dependency on clojurescript on the project templates?
@juhoteperi: does the cljs compiler api provide a way to get the compiler version? that would be a good way to test if cljs is on the classpath
mynomoto: when this is implemented we should add :exclusions
and omit the explicit cljs dependency, yes
(cljs.util/clojurescript-version)
It's not exposed in api namespaces though
(def existing-cljs-version (guard (require 'cljs.util) ((refer 'cljs.util/clojurescript-version))))
if there is explicit dep, there shouldn't be need to exclusions
we probably don't want exclusions in the hoplon demos, because the hoplon task uses cljs compiler api to do some things itself
what would be a good name for the section of the wiki where we'll document things like .cljs,edn
?
Implemented new logic without version check
instead of require, io/resource should also work
I wonder if there is any case where require might be loading clj namespaces using different classloader than io/resource?
Hmh, io/resource uses current treads context classloader
Looks like clojure.lang.RT/load also uses that... in some cases at least
There are some alternative branches but I don't know if and when they are used
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L2135-L2141
becase we're configuring a pod we need to make sure that the source is either on the classpath as a file or in a jar on the classpath
Is there any benefit to using require?
It needs guard and has probably takes some time to compile cljs sources
I don't it's boot-cljs' responsibility to check if cljs namespace can be loaded
build will anyway fail the the file exists but doens't compile
I guess I could make new boot-cljs release with the change
No reason to wait
oh, one thing that would trim down compile times slightly: have some kind of caching mechanism for the .cljs.edn modifications
@martinklepsch: how do you mean?
currenly when using reload/repl they always modify the cljs.edn files in a watch cycle even if not a single cljs file of the relevant build has changed
We talked about this before I think, maybe in different words 😉
Ugh, cljs-repl dependency logic needs some work also
@mynomoto: https://github.com/martinklepsch/electron-and-clojurescript/blob/master/build.boot
they work great, above is a more involved example with different options for different builds
@martinklepsch: so if no different compile options are necessary I can pass more :ids
to the same cljs
task? And the id is the name of the .cljs.edn
file?
If compiler-options are different, it should be possible to se the compiler options on .cljs.edn
file
And then it should be possible to just use one cljs task
In the case of the electron example I needed different options for dev/prod which isn’t easily possible if you have two builds
can anyone point me to an example that programatically composes a variable number of tasks?
I want to compose tasks based on the fileset. So plain composition doesn’t work. I assume I need to compose my list of tasks with the next-task
as it’s described here: https://github.com/boot-clj/boot/wiki/Tasks#the-null-task
let me fiddle a bit more, I think my question might have been a bit premature 😛
@martinklepsch: There could be something useful here: https://github.com/metosin/palikka/blob/master/build.boot#L40-L75
@micha: @juhoteperi I hope the above illustrates the problem
(the code doesn’t work)
I think I can’t just to (apply comp…
and then later use comp
again can I?
I think it's possible but not very clean
@martinklepsch: try that
It does recreate collection middlewares for each :page
each time
So it creates another tmp-dir and pod-pool each time
if it works
@juhoteperi: there’s no passing of the fileset to the task anywhere
oh hm
((reduce …) fileset)
< trying this
Call the function returned by reduce with fileset?
that works
amazing 🌟
it will leak memory overtime or something 😄
Hm could be useful to have another render task in perun
render is now 1-1 from post to output
and collection is 1 output from all posts
But there could be something where you control the output files yourself
yeah. if composing like this isn’t easily possible probably something worth adding to perun
Collection tasks should be constructed just once and then the same task should run multiple times
But it's not possible to compose it that way as pages can only be known in runtime
It's hard to explain as I don't know what to call the different phases and functions 😄
hmh, task creates middleware, middleware creates handler
maybe also the collection task could be generalized to something like group-by
where the key becomes the filename
I'm not sure if it's good idea to change collection task as it currently only writes one output file
in the case of index the group by fn just always returns “index” in other cases it returns something else.
@juhoteperi: can also be another task, just api-wise similar.
would the renderer fn be called multiple times?
only if there’s more than one entry in the grouped map
and :group-by key would be used for output name?
Could work
:page would not be used with :group-by
:filterer wouldn't make sense either maybe?
I think you might want to filter things before grouping them (drafts etc)
@juhoteperi: ":page would not be used with :group-by” < didnt understand that?
:page option is not useful if there is going to be more than one file?
filtering happens before grouping, sorting happens after
@juhoteperi: ah yeah, that :page
. true. (thought you were referring to some of my pagination stuff)
@juhoteperi: In general I think filenames should not be considered too important. sift
can do all this.
@juhoteperi: :page could even stay around and just be mapped to group-by
behind the scenes
@martinklepsch: do you remember when we were talking about the jar
task not trying to figure out the project and version from the pom?
for some time I loved markdown but since I use it in Clojure/Java I’m more and more growing to freak out about it
(*this* should be bold no?
@martinklepsch: Yes and works for me
@juhoteperi: https://github.com/sirthias/pegdown/issues/196#issuecomment-141707117
also having other fun now:
Would be cool if it would be possible to support Pandoc
It's probably one of most complete markdown implementations
or sane
Or at least it supports several dialects with options
yeah, more and more getting annoyed with pegdown and my inability/unwantingness to fix/modify it 😄
looks like CommonMark specifies that strong emphasis should work inside parenthesis
"Note: pegdown differs from the original Markdown in that it ignores in-word emphasis as in"
yeah saw that too
Hmph, perun needs a option for Endophile options
Looks like sirthias didn't pay too much attention when merging some PRs, the docs and comments on code don't reflect the implementation
I’ll see if I can get pandoc going tomorrow shouldn’t be that hard after all.
It's hard to do properly
That is, compile Pandoc as static library, package it for all systems as JAR and call that using JNA