Does the following mean that I am chaining to many tasks?

clojure.lang.ExceptionInfo: java.lang.RuntimeException: Method code too large!, compiling:(NO_SOURCE_PATH:0:0)
    data: {:file "/tmp/boot.user1305866973653506383.clj", :line 67}
clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Method code too large!, compiling:(NO_SOURCE_PATH:0:0)
             java.lang.RuntimeException: Method code too large!
          clojure.asm.MethodWriter.getSize                 MethodWriter.java: 1872
       clojure.asm.ClassWriter.toByteArray                  ClassWriter.java:  775
                                       ...                                        
                         clojure.core/eval                          core.clj: 3081
                         boot.pod/eval-in*                           pod.clj:  437
                                       ...                                        
                         boot.pod/eval-in*                           pod.clj:  440
  confetti.boot-confetti/eval2819/fn/fn/fn                 boot_confetti.clj:  155
replumb.boot-pack-source/eval2560/fn/fn/fn              boot_pack_source.clj:   45
            boot.task.built-in/fn/fn/fn/fn                      built_in.clj:  416
... repeating tasks over and over

@richiardiandrea: https://github.com/boot-clj/boot/issues/339

If any emacs cider users here would like to test this PR that would be awesome!

Hey I am trying to get a bare bones boot build working so I can figure out how it works but I am struggling. I am trying to make a task that will compile my cljs files, automatically reload them, and then start a cljs repl but I can’t seem to get it to happen. I have put together a demo repo here: https://github.com/adam-r-kowalski/demo When I run my dev task it seems as if no javascript files are ever made but it goes through and it says compiling js/main.js in the terminal.

hi @adamkowalski

hey

one thing you can do to start debugging is to add the show task to the pipeline

like this:

boot dev show -f

that will print the fileset as a tree each time the pipeline is run

so you can see which things were created and where they are

however i think the problem you're seeing in this specific case is the order of the tasks in your pipeline

the reload and cljs-repl tasks actually emit clojurescript that needs to be compiled by the cljs task

can you try reordering the tasks like this:

oops durr

disregard that, what you have looks correct

interesting, when I run it with the show task it seems like a bunch of things are being created, and I even get notified that the build succeeded, yet I still can’t actually use the js files

your project looks fine to me, what exactly isn't working?

here is the output of boot show http://pastebin.com/gpwkr3w0

well the thing that isn't working is actually using the compiled js index.html. It seems like nothing actually gets served js wise

I can serve the index hiccup page, but it says that there isnt any js/main.js

i don't see the serve task anywhere

try doing boot dev serve

im not using the http serve task, I just wrote a really basic aleph server

its in src/clj/demo/server.clj

i son't see it in the pipeline

*don't

well I wanted to have two repls, one for the client and one for the server

so rather then having the dev task start the server, I first ran a boot repl and just called (server/start) which would fire up the server and show my index.html

ok cool, that seems fine

then i started the boot task and wanted to get a cljs repl with that

sure

i think you want one repl server

and two separate clients perhaps

yeah I think what i was doing was running boot dev boot repl -> (server/start) boot repl -> (start-repl)

that way I was thinking that I would have the dev task which takes care of reloading, compiling, etc, and I would have one repl for the client, and another for the server

but it seems like the server has no way of actually getting the generated files from boot dev

@adamkowalski: ok i cloned the repo

i have the server working

i made just one repl server

and connected to it from multiple clients

one client is doing (boot (dev))

another client has the http server via (server/start)

and it loaded the js/main.js?

i think all it should be doing is log that the application started for now

i got the html from localhost:3000

one sec i check the js

any luck?

computing...

looks like a compojure problem maybe

it serves the hiccup for any URI

ah that's the not-found route

yeah I wanted to do that on purpose

that way I can manage all my routing clientside

i can see the js file on the classpath

(-> "js/main.js" io/resource slurp print)

so i think it must be something with compojure

hmm, so is there an example of like a barebones setup that shows how to get a backend, frontend, and boot working together?

just launch a server like jetty/http-kit/whatever, serve an index html and the javascript and get all the reloading?

https://github.com/Deraen/saapas

have you seen that?

thanks looks interesting

i think the problem you're seeing is with compojure

it does a lot of magical things that usually don't work

haha, do you have any recommendations for an alternative

im not opinionated about my stack

we sometimes use just the routing part

from compojure

that's the part that matches and destructures the URI

but like we were having a lot of problems with compojure automatically doing things that would cause problems

like encoding the response in a weird way

or trying to and then throwing exceptions when it didn't work

ah here is the problem

https://github.com/weavejester/compojure/blob/1.5.0/src/compojure/route.clj#L51

oh my resource path is not setup correctly?

i think that's just not a good way to do it (the way compojure does that)

you can use the wrap-resource ring middleware

instead of the compojure resources

that will work fine, (-> ... (wrap-resource :root ""))

ok thanks i’ll try that

@micha You should use bidi

@adamkowalski: let me know if that doesn't work i'll investigate further

No bias.

@dominicm: hey yeah!

oh that looks cool

our app is actually running in a proxy, with some requests being routed to a legacy backend, and some being processed locally

Compojure was one of the early recommendations, and I think people encounter it a lot in tutorials/blogs/etc. Bidi feels more Clojure-y. Data all the way down. Just routing.

yeah we have a lot of stats, logging and other things that we need to do in the proxy to process the responses

so things that make the assumption that they can return a response directly to the client won't work

@micha: Yeah. bidi is what you want.

NoBias

let me compute! that's the motto

ok this is really weird… i have [ring “1.4.0”] in my dependencies in my set-env! but I cant access the ring.middleware namespace

all that is available is ring.util lol

@adamkowalski: boot show -d and boot show -p are your friends there

oh and @dominicm: how is bidi on cljs? have you made it work with the html5 history api?

@micha: yeah its got it in boot show -d

oh wow boot show -p is awesome

ring.middleware.resource/wrap-resource

@richiardiandrea: did the send! stuff work out for you?

@adamkowalski: 90% of bidi is: take string and routes, resolve value in route structure. And also take routes and value, and return string.

@martinklepsch: I was trying than I noticed a problem on my side, I need to fix it and try again

I'm not sure if the html5 history api is implemented by bidi itself, but it might be, and I've just not used it

looks like you could pass the route from the callback to match-route

so you do hash based routing?

@micha: whats the boot equivalent of lein clean -> lein deps

@adamkowalski: there is no "clean" task!

boot doesn't make any stale things that could be cleaned

lein deps --> boot show -d

alright i gotta head out but thanks for all the help!

good luck!

@dominicm: bidi looks like a good thing to replace what we have in our frontend, too

@micha: Yeah, bidi is great that way

one thing that would be great is to be able to change the routes as they appear in the URI without changing the names of the routes (for the bi-directional rendering)

looks like bidi can handle that kind of thing pretty easily

@martinklepsch: I confirm that send! solves the problem, opening a PR as we speak

how can i make a clojure type hint for a native array of some java type?

@micha are you creating the array?

well i have this:

(Files/copy ^Path src ^Path tmp fs/copy-opts)

the last argument is of the type array of java.nio.file.attribute.StandardCopyOption

ok

i'm not sure how to make the type hint at the call site there

http://clojuredocs.org/clojure.core/make-array

ah sorry

you just need the type hint

yeah i'm jsut trying to avoid the reflection there

it's in a tight section of code in the fileset stuff

well yeah there is a weird way, let me find it

it actually follows the Java notation, I have it somewhere (when I was contributing to Counterclockwise I needed it)

maybe this: http://asymmetrical-view.com/2009/07/02/clojure-primitive-arrays.html

the java type name is [Ljava.nio.file.StandardCopyOption;

yeah

then there is a reader macro

so I think I found an old post where it is discussed, dunno if it has been improved: https://groups.google.com/forum/#!topic/clojure/TFLUw8GSAbY

oh wow ok

@richiardiandrea: i dont' really understand the issue with boot.main/-main and the reloading warnings

boot.App/runBoot should be creating fresh pods

yeah but from what I understood this line https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/main.clj#L200

loads the script again

probably not in an isolated pod

but boot.main/-main is called only once

runBoot makes a new pod and calls -main in that

so it only should run once in each pod

like in my multi-module demo

you don't see those warnings

i might be wrong, maybe I did not follow the threading properly, but

so maybe I am using runBoot in the wrong way?

https://github.com/arichiardi/boot/blob/parallel-boot/boot/core/src/boot/parallel.clj#L60

this was the original runboot

https://github.com/boot-clj/boot/blob/master/boot/base/src/main/java/boot/App.java#L389

the function accepts the core pod (that's where -main will be called) as an argument

yes

are you creating a new main pod each time you call runboot?

ah no

let me check

https://github.com/arichiardi/boot/blob/parallel-boot/boot/core/src/boot/parallel.clj#L54

yeah it looks like you're making a new pod there

well the first time

if the pipeline runs a second time you'll get the warnings

so there is maybe something else going on

because you're reusing the same core pod again

maybe create the new core pod inside the with-pass-thru scope

runboots are comp-ed https://github.com/arichiardi/boot/blob/parallel-boot/boot/core/src/boot/parallel.clj#L144

creating a new middleware every time

now I am worried that I have done something horrible 😄 😱

if you are using the watch task or something that runs the pipeline more than once

no no, no watch

hm

batching is here: https://github.com/arichiardi/boot/blob/parallel-boot/boot/core/src/boot/parallel.clj#L190

forcing the calls, but this was introduced later

it was generating warnings earlier

i don't see any changes to boot.App, so i don't think any regressions were introduced with this PR

yes I have not touched that, and runboot is your original task as well

this is very strange and curious

indeed

i wonder if somehow load-file is escaping the pod

yes I was checking the clojure source

i don't think so, because i think require ends up being load-file at the end, and require seems to work okay

but it's been a while since i traced that part of clojure.core

and how would it "escape" a pod for instance, it would need to modify the classpath basically right?

yeah

https://github.com/clojure/clojure/blob/d5708425995e8c83157ad49007ec2f8f43d8eac8/src/jvm/clojure/lang/RT.java#L215

it would need to modify the parent of the clojure classloader or something

it is static which is already scary 😄

ok I am not going to paste anymore source I swear 😉

Util.sneakyThrow(e);

love it

ah ah

yeah

what an invention he discovered

I see LOAD-FILE is interned but not declared anywhere...

Compiler/loadFile

i wonder if we want clojure.core/load instead of load-file

yeah, probably the former

lol ^^

lol

DDOS for boot

@micha but you see load calls RT.makeClassLoader() line 7200

so it is escaping the pod right?

good question

so in boot.main/-main a temp file is created

but perhaps a directory can be craeted instead

and the boot.user namespace written there

then we could add that dir to the classpath and use clojure.core/load on it

or just require really

yes probably better

then @micha my patch should not be changed right? do you want me to open an issue with this to keep track?

yeah i think we can merge what we have

the load-file thing will be a pain to fix

it's not easy to make a temp directory

i'm not sure if we have acess to the boot tempdirs stuff there

yeah...that's why I was thinking it requires you assistance and maybe some hammock time 😉

should i squash the commits?

or do you want to keep them as separate commits?

I would like to keep them separate, I already kept only the most "significant" but it depends on you too of course

well you have access to merge it however you prefer

it's all good, whichever you prefer

yeah I would merge like this (do I have access to merge myself?)

it is a pity that all these warnings are going to show up

you should

mmm...nope...in any case I have to fly in 4 mins..:D

and I still think that in case of parallel execution we should not reload the script, so we should not pass by that part of -main...

but at least we found the culprit

💥