Fork me on GitHub
#boot
<
2017-04-14
>
qqq01:04:14

:optimizations :none

souenzzo01:04:32

Hey, there is some How to run boot Direct on cljs, using lumo or something like?

borkdude11:04:43

I’m running a clojure.spec test from a boot task. When I invoke the test from the REPL it works fine, but when I invoke it from the task, it executes zero tests…

(deftask run []
  (with-pass-thru [_]
    (let [res (stest/check `run-script-with-deps)
          summary (stest/summarize-results res)]
      (println res)
      (println summary))))
Any idea why?

borkdude12:04:29

I moved code to normal source files, now it works

kommen13:04:25

I have boot tasks which look like this:

(deftask scss []
  (merge-env! :source-paths ["scss"])
  (comp
   (sass)
   (sift :move {#"main.css$" "css/main.css"})))

(deftask dev []
  (merge-env! :source-paths ["src"])
  (comp
   (watch :verbose true)
   (cljs-devtools)
   (reload)
   (cljs-repl)
   (scss)
   (cljs)))
 
this works fine 90% of the time. but sometimes the css i not compiled, and the scss files don’t show up in the initial output from watch :verbose. can the merge-env! :source-paths in the scss task be a problem because this is only called after watch?

mobileink18:04:36

saw a q on #clojure about compiling kotlin, scala etc. with leiningen. seems like it would be pretty easy with boot but googsearch turns up zilch. anybody do that?

alandipert18:04:08

i haven't seen, i would enjoy a kotlin one tho

alandipert18:04:21

i made one for an obscure language called yeti, boot-yeti

alandipert18:04:34

i didn't actually learn its compiler api. i just call its main method in a pod

alandipert18:04:45

same approach could probably used for scala etc

alandipert18:04:11

there were downsides tho, like it wanted to exit the jvm when compile fails. i worked around that with jvm security craziness lol

matan18:04:00

I wonder how would jvm security help without crashing the yeti build tool itself?

alandipert18:04:46

yeah, i haven't used it very much. i'm sure there are problems. better solution is to learn actual compiler api for language you want to make task for

matan18:04:22

compiler api is very low level. language-specialized build tools provide a lot of stuff besides compiling: they track whether dependencies and artefacts need to be fetched (or are already present) and which parts of the project need to be re-built, to name a few concerns they handle.

matan18:04:09

weaving different languages at the compiler level would constrain your fluency with each language's part of your project, or you'd need to re-write major swaths of your language-specific build tool in order to avoid some of them..

mobileink18:04:40

the idea of boot-gcc has been haunting me for some time.

matan18:04:55

I wonder if there are other examples of cross-language building made with boot

alandipert18:04:22

i use the javac task all the time

matan18:04:36

well that can be done even in lein

alandipert18:04:46

i don't agree that language variety decreases fluency, because fluency is not zero-sum

matan18:04:12

ummm no offense to yeti of course 🙂

alandipert18:04:16

and a large project is indistinguishable from a small project with lots of library dependencies produced by other languages

mobileink18:04:28

the nice thing about boot is you can sequester all the stuff using pods and filesets.

mobileink18:04:45

there are various boot libs that do this, eg css stuff, for example. i've used it for the Great NetRexx.

alandipert18:04:12

good point. i use the sass task every day

alandipert18:04:58

also the hoplon task, but even more contrived use case than yeti since i co-invented the hoplon language 😁

matan18:04:30

@alandipert and until now I thought clojure was an original choice of me 🙂

matan18:04:18

Do any of these examples synchronize dependencies between different languages such that one builds when the other has changed and so forth? I am not sure how the css stuff mentioned here provides a parallel to this, probably in my own fault

matan18:04:23

I still think you'd never use e.g. the scala compiler directly, because then you'll need to change your code for every source directory you add and the like, stuff that sbt abstracts away

alandipert18:04:48

the generall recipe is, to start from nothing, and put tasks in dependency order

alandipert18:04:06

ie if i'm making a clj program with a .java dep, i'd compile the java first, then pass the fileset to the part that AOTs clojure

alandipert18:04:37

in this respect you're right, css isn't really a good example, since it doesn't produce compile-time dependencies

alandipert18:04:45

the dependencies are resolved in the browser at runtime

mobileink18:04:46

haven't used scala, just rashly assuming you could wrap sbt in some fiendishly clever way.

matan18:04:40

of course it is easy to wrap sbt, but it is notoriously heavy on the jvm, if everything needs to run in the same jvm sbt will not work well, it does some crazy stuff to the jvm, internally. it should probably run as a shell command.. which might defeat the purpose of boot's architecture (?!)

mobileink18:04:50

i've used templating engines, which technically are compilers kindasorta, to produced clj and java source that gets compiled by a later task and then discarded.

mobileink18:04:22

ah, that's different.

matan18:04:13

if boot in some way helps, alleviates or a similar verb of your choice, the running of an external build tool beyond what I'd get with ant or my own clojure code, I'd use it for sbt.

mobileink18:04:15

i work with google appengine test server which also mucks things up by forking its own jvm and classpath. i end up dumping all to target and serving from that instead of a fileset.

alandipert18:04:26

the big difference is, boot delivers a filesystem value that it manages efficiently. an immutable value type you can "add files" to, test for equality, store for caching, etc

mobileink18:04:58

define "external build tool"?

alandipert18:04:06

and so you can compose tasks like compilers functionally, without worrying about filesystem hygiene

matan18:04:18

Oh, because file systems are in fact virtualized through filesets?

matan18:04:33

this reminds me a little of gulp, a node.js abomination

matan19:04:08

@mbjarland I should have said build tools which cannot be run inside the same JVM but rather as a shell command.

alandipert19:04:31

@matan precisely. similar to gulp, except instead of individual files getting piped through, entire "filesystem values" get piped through, composites.

mobileink19:04:54

sorry i dunno anything about sbt. really sorry you brought it up, because now i won't be able to sleep until i figure it out. 😂

matan19:04:55

are filesets also persistent? or should they be created from scratch on each run of a step?

alandipert19:04:19

their lifecycle is that of the jvm

matan19:04:32

@mobileink sbt is the main/only scala build tool. it is quite horrific as it was predicated on scala being a good language for DSL, which it is not, really

alandipert19:04:36

there is a separate mechanism for caching things across jvm invocations

alandipert19:04:58

a content-addressed kv store type thing, not as featureful

mobileink19:04:38

@alandipert wait, i thought i read somewhere filesets should not be thought of as a virtual fs?

alandipert19:04:41

but a typical pattern is for a task to store the "last seen" fileset, and if none of the files changed, to add previously-created files without doing work

matan19:04:03

It sounds like boot can be used for this job, but certainly not deeply designed for it. I'd avoid trying at this state of affairs, unless I had some mileage with boot already 🙂

alandipert19:04:17

@mobileink yeah it's not a great analogy, since filesystems are mutable

mobileink19:04:29

i think of the fs stuff as a kind of opaque memory, just like clojure uses memory when you e.g. assoc a map.

matan19:04:08

@alandipert I like that pattern you mentioned, that should nail some of the complication.

matan19:04:48

@mobileink not sure the url is working, but I can guess the idea. being given two weeks of extra life in a parallel universe where there is boot and clojure but no schedules might be needed as well.

mobileink19:04:45

stupid link! https://g.co/kgs/LrrwgA these boots are made for walking

alandipert19:04:11

another value of just using sbt you wouldn't get with boot

alandipert19:04:14

is intellij wouldn't work

alandipert19:04:22

same for kotlin

mobileink19:04:23

well, i've been thinking about discovering why clojure is better than scala, maybe now's the time. a while back i saw a video of the main scala guy at the time explaining why it sucks and why he left. ouch. so i've stayed away.

alandipert19:04:49

what people do there is generate a project.clj for IDEs use, would probably need to do something similar in order for scala/kotlin to be usable

matan19:04:57

yeah, meshing different tools would undermine any chances of using an IDE (which clojure guys don't use much anyway).

alandipert19:04:31

of course, you can get pretty far with auto compile/reload and ctags

alandipert19:04:45

just depends how much you think you need what IDEs do, which varies by human

mobileink19:04:52

no gui ides? no intellij, eclipse? that's a feature!

matan19:04:47

to the point of boot being used to weave different jvm languages in a single project, do the docs nail it as a resonating No? https://github.com/boot-clj/boot/wiki/Pods > Boot's primary purpose is to bootstrap Clojure applications. I fail to see how you'd get e.g. an uberjar of a mixed-language project, with pods, but more essentially if that's really the core aim of boot, I posit that it is the wrong tool for such integrations like the task this discussion evolved from.

mobileink19:04:58

i'm going to push back on the idea that the primary purpose of boot is to bootstrap Clojure applications. That might have been the original goal, but i think the devs, like many geniuses, did not fully appreciate the earth-shattering significance of what they had wrought. boot is the Job Control Language par excellance: JCL done right. It leverages Clojure, but is not limited to it.

mobileink19:04:58

and you can use it for any job control (batch) pipeline; software construction is just a special case.

mobileink19:04:33

the classic mainframe dataprocessing pipeline: run n batch programs each of which takes data from the preceeding step, maybe reads some other files, and passes the transformed data to the next step.