Fork me on GitHub
#boot
<
2015-09-19
>
micha00:09:02

like for instance, show -e prints this for my project:

micha00:09:11

$ 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" ""]]}

micha00:09:59

all the tempdirs will be under the /home/micha/.boot/cache/tmp/home/micha/git/micha/asdf/7nw subtree

micha00:09:13

then i grep around in there

jaen00:09:18

@micha: thanks for the tips; I can't seem to be able to find that file there for some reason though.

micha00:09:28

maybe it wasn't created

jaen00:09:07

@micha: you substitute :output-to in compiler opts to make it output to the temp dir, yes?

micha00:09:49

all the compiler opts are computed based on various rules

micha00:09:04

there's a ton of coupling in weird ways between the various options

micha00:09:28

we use middleware to process that and emit the correct compiler options

micha00:09:42

but yeah, cljs emits to temp dirs for sure

micha00:09:59

no files are created outside of temp dirs during a build

flyboarder00:09:06

@jaen: what is the problem you are encountering?

flyboarder00:09:21

you said it blows up 😉

jaen00:09:20

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

jaen00:09:18

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

flyboarder00:09:50

@jaen: so are you trying to include this in a boot task?

flyboarder00:09:12

can you post a snip of your task?

micha00:09:36

you're injecting your version of cljs compiler by specifying it as a dependency instead of the regular one, i suppose?

micha00:09:48

like installing cljs to your local maven repo and whatnot

jaen00:09:49

and adding exclusions, yes

micha00:09:07

can you paste that part?

micha00:09:13

this might be your problem

micha00:09:03

you need to give your compiler the org.clojure/clojurescript group/artifact id

micha00:09:17

otherwise cljs task will add that dependency

micha00:09:25

in the pod

jaen00:09:54

That's how my build.boot currently looks

jaen00:09:23

I think I just must have botched the way I update :libs vector so it doesn't work with how boot works

micha00:09:51

ah yeah that's the problem

micha00:09:05

the cljs task is hardcoded to org.clojure/clojurescript

jaen00:09:03

Ah, so if I have different group/artifact it will just inject cljs anyway, yes?

micha00:09:09

you can see when it builds the pod it will have both your cljs compiler and the regular one

micha00:09:20

yeah it will have both on the classpath

micha00:09:27

which is kind of undefined behavior

micha00:09:20

it's also kind of unkosher to distribute the same classes/namespaces under different artifact ids

jaen00:09:26

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.

micha00:09:56

for now why not build it and install locally under the org.clojure/clojurescript ids?

micha00:09:12

you don't need to push to maven central for that

micha00:09:36

the reason all that's in there is because there was a lot of churn with cljs

micha00:09:57

nobody could figure out which versions of various things worked with which other versions

micha00:09:22

so things were hardcoded into the task to at least warn you when things probably wouldn't work

jaen00:09:59

I suppose that makes sense, cljs ecosystem used to be really rough around the edges

micha00:09:11

probably not so necessary now

jaen00:09:28

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

micha00:09:44

yeah i'm almost certain that's the problem

micha00:09:55

clashing jars

jaen00:09:10

Though I'm surprised this other cljs compiler didn't show in boot show -d

micha00:09:26

show -d doesn't go into pods

micha00:09:32

it's to show you your project deps

micha00:09:47

cljs compiler dep is being loaded into the pod only, not into your project

micha00:09:55

so show -d doesn't show it

micha00:09:29

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

micha00:09:44

jaen: what kind of modifications did you make? just curious

jaen00:09:05

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.

micha00:09:09

interesting

jaen00:09:09

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.

micha00:09:27

i like the README lol

jaen00:09:23

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

jaen00:09:26

And here I am

micha00:09:28

do you need to use the artifacts you made in clojars or can you just hack cljs and install locally?

jaen00:09:27

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.

micha00:09:54

the suspense is building

micha00:09:09

does it work?

jaen00:09:00

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

jteneycke03:09:48

ah. used “advanced” optimizations and it totally did it. nevermind! 😄

jaen11:09:28

@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

martinklepsch11:09:35

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

martinklepsch11:09:32

@jteneycke: depending on how you serve your files :asset-path can probably help

jteneycke11:09:24

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.

jteneycke11:09:36

Current problem: csrf-tokens 😄

jteneycke11:09:10

scratch that - no longer a problem 😉

micha11:09:37

@jteneycke sweet!

micha11:09:36

if you push a minimal repo i might be able to see a way to get :none working

micha11:09:55

not really skilled with rails though

jteneycke11:09:10

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.

micha11:09:10

so simpler would be better :)

jteneycke11:09:25

Just gotta navigate to the lib/assets/cljs folder to run “boot dev”, and then bundle and setup your rails server like normal.

micha11:09:39

perfect! please feel free to add to the community tasks section of the boot wiki

micha11:09:51

that's a cool task!

jteneycke11:09:43

oooh - now that’s a healthy wiki

jaen11:09:11

jteneycke: out o curiosity why with Rails?

micha11:09:23

ooh interesting, you didn't need to make a special task to integrate with rails

jteneycke11:09:16

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

micha11:09:56

if you want to make a section in the wiki for boot+rails that would be very awesome :)

micha11:09:15

no pressure though :)

jaen11:09:36

@jteneycke: for HAML you can jsut use boot-middleman

jteneycke11:09:40

I’d love to make this easier on the next poor sucker that is stuck with Rails. 😄

jaen11:09:10

Though if you need to keep the backend then I suppose it doesn't help as much

jteneycke11:09:24

Yeah, I saw that. Very cool. Not sure how that would help me in a legacy Rails context tho.

micha11:09:31

also people will leave info there for you as new stuff comes to light

jaen11:09:42

Yeah, realised that hence the comment under the link '

jaen11:09:04

But it plays pretty nice with kioo, so you can use something sane for the templates like HAML

micha11:09:07

i bet there are a lot of people wanting to extract themselves from a similar situation, your setup would save lives

micha11:09:24

think of the children

jteneycke11:09:39

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:

jaen11:09:27

#rails-don't-scale ; d

jaen11:09:35

Well, at least structurally it seems

jteneycke11:09:48

Far as I can judge, Phoenix is going to outright kill Rails.

jaen11:09:40

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.

jaen11:09:44

Yeah, Phoenix is interesting

jteneycke11:09:10

First thing I do when I “rails new” is nuke half the gems and replace the other half. simple_smile

jteneycke11:09:55

And so ends tonights sleepless compulsive hack. G’nite!

micha11:09:18

@jteneycke good work! thanks for taking the time to do that

jaen12:09:42

Good night; sleepless compulsive hacks seems like I theme, that cljs compiler + boot issue kept me awake until 0500 hours ; d

jaen12:09:56

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

juhoteperi12:09:29

@jaen: You can use :asset-path but boot-cljs does indeed overwrite :output-dir and :output-to

jaen12:09:49

@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?

jaen12:09:21

In the second case I assume it should be then set per cljs.edn file in :compiler-options of the edn, right?

juhoteperi12:09:46

"assets/javascripts/build-id.out"

juhoteperi12:09:57

Yeah it should be set per .cljs.edn file

jaen12:09:24

Ok, gotcha

juhoteperi12:09:45

We hope to implement some easier way to set this more easily in future

jaen12:09:26

Yeah, setting a root path for resources and boot-cljs appending build output suffix would be nice

jaen12:09:34

But at least now I understand how this works exactly

juhoteperi12:09:43

It would be a quick fix

juhoteperi12:09:05

But another problem is that boot-reload needs to also know the asset-path

juhoteperi12:09:16

And possibly other tasks also

jaen12:09:25

Ah, yeah, that makes sense

juhoteperi12:09:51

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

jaen12:09:54

Yeah, that makes sense

jaen12:09:56

Incidentally

jaen12:09:35

Would another task be able to pass options on to boot-cljs task or would it have to wrap it completely?

juhoteperi12:09:09

Other tasks can read and modify .cljs.edn

jaen12:09:21

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?

martinklepsch12:09:06

@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?

martinklepsch12:09:21

@jaen: that sounds possible

juhoteperi12:09:09

@martinklepsch: Did you update pegdown dependency in all the necessary places?

martinklepsch12:09:58

I think so. Also there is no Retrieving … message about other versions being downloaded + no other versions of pegdown in .m2

jaen12:09:26

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?

martinklepsch12:09:29

This should be enough I guess but I also made a new endophile jar depending on 1.6.0 explicitly

juhoteperi12:09:39

Yeah looks proper

martinklepsch12:09:54

@jaen: reload and repl tasks modify cljs.edn files

juhoteperi12:09:32

pegdown should have a test for aside so it should work

jaen12:09:31

@martinklepsch: thanks, I'll take a loot at those then

martinklepsch12:09:48

@juhoteperi: fwiw, I just saw that they released 1.6.0 but the issue persists

juhoteperi12:09:10

Lol sbt is slow

juhoteperi12:09:23

started running publish-m2 4min ago and still going 😄

martinklepsch12:09:35

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!

martinklepsch12:09:31

all tests pass though o.O

juhoteperi12:09:34

Yeah I can reproduce this

juhoteperi12:09:45

I wonder if it's pegdown or endophile

martinklepsch12:09:43

@juhoteperi: I can’t find the word recognized in pegdown, parboiled or endophile

juhoteperi12:09:54

@martinklepsch: Aside works for me in endophile

juhoteperi12:09:11

Endophile dev version is 0.2.0-SNAPSHOT

juhoteperi12:09:37

Update perun to use that and it should work

juhoteperi12:09:52

Works for me

martinklepsch13:09:47

@juhoteperi: that indeed works. Thanks a ton!

martinklepsch13:09:57

maybe I can get my blog migrated today simple_smile

juhoteperi13:09:20

I try to get new endophile released

juhoteperi13:09:29

The other PR works with the new pegdown

micha13:09:42

I'm going to take a day for Boot maintenance today

micha13:09:56

any special requests?

juhoteperi13:09:13

@micha: version comparison functions

micha13:09:25

awesome yes

micha13:09:48

OK cool I'll do that first

juhoteperi13:09:03

version-clj looks the best option

micha13:09:27

yep I'll add it to the worker pod

micha13:09:54

how about a new namespace for the wrapper fns, boot.version perhaps

micha13:09:10

available in all pods

micha13:09:36

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

micha13:09:00

since they're conventions that extend beyond any single task

micha13:09:10

we can have versioned specifications

juhoteperi13:09:46

New namespace for wrappers sounds good

jaen13:09:14

@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?

micha13:09:31

i was thinking about this

juhoteperi13:09:52

I would be open for some change for automatic cljs dep injection

micha13:09:10

the reasons for the version stuff is because depenedncies of this type, eg. framework deps, are hard to manage

juhoteperi13:09:11

One idea I had would be to only check artifactId

micha13:09:21

like every dep that uses cljs depends on a different version of it

micha13:09:44

so the only way to know hwich version you're going to get is to explicitly depend on cljs in your project deps

micha13:09:51

that will override all the transitive ones

micha13:09:17

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

micha13:09:42

so i was thinking maybe to use the :exclusions key in set-env! to globally exclude cljs

micha13:09:52

i mean exclude from all transitive deps

micha13:09:07

then boot-cljs could just use its own version of cljs

micha13:09:18

so you'd choose the version of cljs by choosing the version of boot-cljs

micha13:09:26

so you know they're in sync and will work

juhoteperi13:09:27

Hmm global exclusions sound useful

micha13:09:40

but boot-cljs could also be a little smarter

micha13:09:03

like if boot-cljs sees that cljs.core namespace is on the classpath it could assume that you added your own cljs dependency

micha13:09:27

and it could then forgo the version checks because you presumably know what you're doing

juhoteperi13:09:58

I was thinking about that but what would be good way to check if ns exists?

micha13:09:03

also if we enforce the cljs compiler version in boot-cljs we don't need as much of the warning code

micha13:09:56

(boot.util/guard (require 'cljs.core) true)

micha13:09:18

that should return nil if the ns doesn't exist

juhoteperi13:09:33

That would have to be run in the pod

jaen13:09:43

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)

micha13:09:51

yeah, but the pod will have all the project deps by default

micha13:09:27

so currently we strongly recommend that users specify an explicit cljs dependency in their project

micha13:09:38

we could instead recommend the :exclusions

micha13:09:49

and let boot-cljs handle the compiler dependency

micha13:09:11

this seems simpler for people to understand

juhoteperi13:09:35

what do you mean "let boot-cljs handle the compiler dependency"?

micha13:09:15

so if the user does (set-env! :exclusions #{'org.clojure/clojurescript} :dependencies '[[...] ...] ...)

micha13:09:37

then we know that no cljs dependency will be on the classpath unless they are doing something special like what jaen was doing

micha13:09:58

jaen would also need the :exclusions in his case, but he'd be adding his own cljs dep

micha13:09:16

his cljs dep would provide cljs.core and the :exclusions would prevent jar clashing

jaen13:09:31

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.

juhoteperi13:09:34

Okay so, boot-cljs would always add dependency to specific cljs version unless there is exclusions which removes that?

juhoteperi13:09:37

Would make sense

jaen13:09:38

Or am I looking at this wrong?

juhoteperi13:09:49

Then we wouldn't need to even do any version comparisons

micha13:09:00

@juhoteperi not exactly, but yes i think it would eliminate version checking

micha13:09:20

i think if we document :exclusions as mandatory boot-cljs can assume one of two cases exists:

micha13:09:58

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

micha13:09:20

because we assume that everyone is excluding org.clojure/clojurescript via :exclusions

micha13:09:57

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

micha13:09:10

and the user can be confident that everything will work as expected

micha13:09:22

and we don't need to check versions

micha13:09:47

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

micha13:09:26

jaen will know the warning isn't meant for them

juhoteperi13:09:42

I think boot-cljs should work without warnings in case user has direct dependency on cljs

juhoteperi13:09:11

It's perfectly fine to use newer test version of cljs

micha13:09:18

ok so 3 cases

micha13:09:38

1. org.clojure/clojurescript in project (nontransitive) deps --- do nothing, user knows what they're doing

micha13:09:01

2. cljs.core on classpath, org.clojure/clojurescript not in project deps --- warning?

micha13:09:26

3. cljs.core not on classpath, org.clojure/clojurescript not in project deps --- add cljs dep to pod

juhoteperi13:09:33

Sounds right

micha13:09:01

yes this is awesome

juhoteperi13:09:12

Do we need the version comparison utils now? 😄

micha13:09:20

this feels like the right way to make build tasks

jaen13:09:21

I think that sounds like a good solution to me as well

micha13:09:37

haha i'll get those in forthwith

micha13:09:52

but we don't need them for boot-cljs anymore simple_smile

micha13:09:01

i'm sure they'll be useful to have though

micha13:09:16

if just for messing around in the repl or something

micha13:09:26

i suppose the build api namespace is a better thing to sniff out

micha13:09:46

basically the namespaces the boot-cljs build impl needs

micha13:09:56

as long as something provides that we'll take it

mynomoto13:09:48

@micha: that means that I should leave out a explicit dependency on clojurescript on the project templates?

micha13:09:13

@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

micha13:09:29

we could then add the version info to the warning in case 2

micha13:09:56

mynomoto: when this is implemented we should add :exclusions and omit the explicit cljs dependency, yes

juhoteperi13:09:17

(cljs.util/clojurescript-version)

micha13:09:36

awesome, we can access that from clojure, right?

juhoteperi13:09:49

It's not exposed in api namespaces though

micha13:09:11

(def existing-cljs-version (guard (require 'cljs.util) ((refer 'cljs.util/clojurescript-version))))

micha13:09:59

having the explicit dep is still probably a good idea though

micha13:09:10

if other tasks need access to the compiler api

micha13:09:23

so maybe this needs more thinking simple_smile

juhoteperi13:09:28

if there is explicit dep, there shouldn't be need to exclusions

micha13:09:43

so it's still fine

micha13:09:51

and it supports all cases

micha13:09:06

we just probably shouldn't recommend the :exclusions

micha13:09:29

people doing experiments can use them though and it would work great

micha13:09:06

mynomoto: so what i said just now was nonsense simple_smile

micha13:09:29

we probably don't want exclusions in the hoplon demos, because the hoplon task uses cljs compiler api to do some things itself

micha13:09:35

when it generates the cljs namespaces

micha13:09:39

i'm going to also work on a simple .web.cljs spec

micha13:09:29

what would be a good name for the section of the wiki where we'll document things like .cljs,edn?

mynomoto13:09:02

Ok, I will try to update the demos to the latest over the weekend.

micha13:09:13

!m mynomoto

juhoteperi14:09:53

Implemented new logic without version check

juhoteperi14:09:19

instead of require, io/resource should also work

micha14:09:34

very nice

micha14:09:46

removing code is always satisfying simple_smile

juhoteperi14:09:23

I wonder if there is any case where require might be loading clj namespaces using different classloader than io/resource?

juhoteperi14:09:37

Hmh, io/resource uses current treads context classloader

juhoteperi14:09:29

Looks like clojure.lang.RT/load also uses that... in some cases at least

micha14:09:20

yeah in all cases i think

micha14:09:42

it really shouldn't be fishing around in random classloaders

juhoteperi14:09:13

There are some alternative branches but I don't know if and when they are used

micha14:09:18

that would be really bad

micha14:09:33

as long as they're children of TCCL it's ok

micha14:09:28

yeah i htink the REPL might do some things with classloaders

micha14:09:35

like creating a new one for each expression

micha14:09:34

i like io/resource better than require for this use case for another reason, too

micha14:09:00

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

micha14:09:12

because if you create the namespace at the repl we don't want to find that

micha14:09:20

because it can't be used in the pod

micha14:09:27

oh actually nm

micha14:09:33

it wouldn't work in the pod anyway

micha14:09:42

so maybe require is the correct thing

micha14:09:51

since that's what we want to ensure we can do, really

juhoteperi14:09:16

Is there any benefit to using require?

micha14:09:20

i guess that would bail if the source file exists but has errors on require

micha14:09:28

do we want that?

micha14:09:42

perhaps both

juhoteperi14:09:50

It needs guard and has probably takes some time to compile cljs sources

micha14:09:57

if resource exists but require fails we can show a stack trace

micha14:09:16

ah you're right

micha14:09:22

resource is the way

micha14:09:37

the stack trace will come when we require the ns in the builder

juhoteperi14:09:53

I don't it's boot-cljs' responsibility to check if cljs namespace can be loaded

micha14:09:03

yeah you're right about that

juhoteperi14:09:12

build will anyway fail the the file exists but doens't compile

micha14:09:22

very nice

micha14:09:35

as they say in miami: "mas elegante"

juhoteperi15:09:45

I guess I could make new boot-cljs release with the change

juhoteperi15:09:00

No reason to wait

martinklepsch15:09:12

oh, one thing that would trim down compile times slightly: have some kind of caching mechanism for the .cljs.edn modifications

micha15:09:47

@martinklepsch: how do you mean?

martinklepsch15:09:37

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

martinklepsch15:09:01

We talked about this before I think, maybe in different words 😉

juhoteperi15:09:09

Ugh, cljs-repl dependency logic needs some work also

micha15:09:31

oh yeah we should have a thing in there to not do that simple_smile

mynomoto15:09:15

How is the situation of multiple cljs builds?

micha15:09:39

i think @onetom uses them with hoplon

martinklepsch15:09:26

they work great, above is a more involved example with different options for different builds

mynomoto15:09:43

@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?

juhoteperi15:09:45

If compiler-options are different, it should be possible to se the compiler options on .cljs.edn file

juhoteperi15:09:04

And then it should be possible to just use one cljs task

martinklepsch15:09:53

In the case of the electron example I needed different options for dev/prod which isn’t easily possible if you have two builds

martinklepsch16:09:58

can anyone point me to an example that programatically composes a variable number of tasks?

micha16:09:06

(deftask foo
  []
  (comp (if something? (task1) identity)
        (task2)))

micha16:09:11

like that?

martinklepsch16:09:18

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

martinklepsch16:09:28

let me fiddle a bit more, I think my question might have been a bit premature 😛

jaen16:09:01

The Clojrue deps change in 1.7.48-4 works for my use case, thanks a lot!

martinklepsch16:09:27

@micha: @juhoteperi I hope the above illustrates the problem

martinklepsch16:09:46

(the code doesn’t work)

martinklepsch16:09:09

I think I can’t just to (apply comp… and then later use comp again can I?

micha16:09:36

why not make a task that uses the underlying functions?

micha16:09:42

instead of the tasks themselves

micha16:09:23

you can't change the pipeline between compiles i think

micha16:09:40

because tasks already have references to next-task in their closures

micha16:09:03

at least i don't see a straightforward way to do it

juhoteperi16:09:12

I think it's possible but not very clean

juhoteperi16:09:54

@martinklepsch: try that

juhoteperi16:09:12

It does recreate collection middlewares for each :page each time

juhoteperi16:09:36

So it creates another tmp-dir and pod-pool each time

martinklepsch16:09:42

@juhoteperi: there’s no passing of the fileset to the task anywhere

martinklepsch16:09:42

((reduce …) fileset) < trying this

juhoteperi16:09:44

Call the function returned by reduce with fileset?

juhoteperi16:09:27

it will leak memory overtime or something 😄

juhoteperi17:09:16

Hm could be useful to have another render task in perun

juhoteperi17:09:34

render is now 1-1 from post to output

juhoteperi17:09:41

and collection is 1 output from all posts

juhoteperi17:09:10

But there could be something where you control the output files yourself

martinklepsch17:09:24

yeah. if composing like this isn’t easily possible probably something worth adding to perun

juhoteperi17:09:26

Collection tasks should be constructed just once and then the same task should run multiple times

juhoteperi17:09:10

But it's not possible to compose it that way as pages can only be known in runtime

juhoteperi17:09:42

It's hard to explain as I don't know what to call the different phases and functions 😄

juhoteperi17:09:29

hmh, task creates middleware, middleware creates handler

martinklepsch17:09:21

maybe also the collection task could be generalized to something like group-by where the key becomes the filename

juhoteperi17:09:00

I'm not sure if it's good idea to change collection task as it currently only writes one output file

martinklepsch17:09:15

in the case of index the group by fn just always returns “index” in other cases it returns something else.

martinklepsch17:09:37

@juhoteperi: can also be another task, just api-wise similar.

juhoteperi17:09:52

would the renderer fn be called multiple times?

martinklepsch17:09:29

only if there’s more than one entry in the grouped map

juhoteperi17:09:53

and :group-by key would be used for output name?

juhoteperi17:09:04

:page would not be used with :group-by

juhoteperi17:09:21

:filterer wouldn't make sense either maybe?

martinklepsch17:09:38

I think you might want to filter things before grouping them (drafts etc)

martinklepsch17:09:52

@juhoteperi: ":page would not be used with :group-by” < didnt understand that?

juhoteperi17:09:12

:page option is not useful if there is going to be more than one file?

martinklepsch17:09:14

filtering happens before grouping, sorting happens after

martinklepsch17:09:48

@juhoteperi: ah yeah, that :page. true. (thought you were referring to some of my pagination stuff)

martinklepsch17:09:39

@juhoteperi: In general I think filenames should not be considered too important. sift can do all this.

martinklepsch17:09:08

@juhoteperi: :page could even stay around and just be mapped to group-by behind the scenes

micha19:09:25

@martinklepsch: do you remember when we were talking about the jar task not trying to figure out the project and version from the pom?

micha19:09:39

i can't find it in the issues, maybe it was just in here?

micha19:09:48

i forgot where we ended up with that exactly

micha19:09:58

i seem to recall we figured out a good solution

micha19:09:48

ah awesome thanks

micha19:09:03

it was right in front of my face simple_smile

martinklepsch21:09:55

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

martinklepsch21:09:15

(*this* should be bold no?

juhoteperi21:09:17

@martinklepsch: Yes and works for me

martinklepsch21:09:17

also having other fun now:

juhoteperi21:09:40

Would be cool if it would be possible to support Pandoc

juhoteperi21:09:00

It's probably one of most complete markdown implementations

juhoteperi21:09:23

Or at least it supports several dialects with options

martinklepsch21:09:28

yeah, more and more getting annoyed with pegdown and my inability/unwantingness to fix/modify it 😄

juhoteperi21:09:47

looks like CommonMark specifies that strong emphasis should work inside parenthesis

juhoteperi21:09:27

"Note: pegdown differs from the original Markdown in that it ignores in-word emphasis as in"

martinklepsch21:09:42

yeah saw that too

juhoteperi22:09:39

Hmph, perun needs a option for Endophile options

juhoteperi22:09:11

Looks like sirthias didn't pay too much attention when merging some PRs, the docs and comments on code don't reflect the implementation

martinklepsch22:09:11

I’ll see if I can get pandoc going tomorrow shouldn’t be that hard after all.

juhoteperi22:09:00

It's hard to do properly

juhoteperi22:09:23

That is, compile Pandoc as static library, package it for all systems as JAR and call that using JNA