This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
if you could make a demo uberjar that takes a long time to build i could use that for testing
BTW, yesterday I had to upgrade my VPS. The running app has something like 400 MB, but during compilation my 1GB VPS could not handle it.
hey @micha: i've almost got a "jar2bin" boot task working, it turns jar files into standalone unix executables
i don't think i have access to our clojars org -- at least i've never pushed anything to it
@micha: Well, my reasoning is that it has to do with the amount and order of dependencies, but I could be wrong.
BTW, my talk on boot-system that I gave after Clojutre, in Belgium and Spain, was recorded and published here: http://mattiasbuelens.github.io/interactiveprogrammingtalk/interactiveprogramming.html
Yeah, that's the work of mattias buelens, he wrote this slick reveal.js plugin to show video with slides. He's one of beClojure members, and I was lucky to be the first talk they produced with this technique
@juhoteperi: Would you like me to put a link in system's README to this or is internal stuff?
But would be cool if you have time to check the differences sometime and tell what you think
I guess some features have minor drawbacks, like it requires Schema and tools.logging
@juhoteperi I love this, you reinterpret everything to your taste. That's the spirit, young man.
We indeed do re-invent quite many things at Metosin, but at least in some cases we have managed to invent some new useful features 😄
yeah, that's actually what i did in my first iteration but then i realized that i couldn't use "target" as an explicit output directory
ah i see, so
(.mkdirs dir) is better because it will create the directory itself if it doesn't exist already
goog.require could not find: boot.cljs.main78961 and in my target folder I only have
goog.require could not find: boot.cljs.main1867. Any idea what could have caused such a mistmatch?
It must be caused by some recent changes, it's the first time I'm seeing it and I just bumped my cljs-related deps.
the cljs announcement clearly stated 2 days ago that there are some breaking changes, but since the boot-cljs version was also bumped i assumed it should work
hmmm… one difference from the project i get with
lein new hoplon - which is also using boot-cljs:1.7.170-2 is that im using boot-http, not boot-jetty
1.7.170-2 over here; restarting but just fixed this of course, but it may trigger again.
I thought you have to write out your cljs.edn files for each compilation artifact you want
(serve) to the end of the build pipeline - as i saw it in the hoplon template - and it works now.
i thought it was irrelevant where is it in the pipeline...
So it probably doesn't mean anything - for me restart without actually changing anything helped.
@juhoteperi: so if i have my own cljs.edn the file shouldn't be named
main1867 or whatever?
@jaen: i just had a quick look at the source to see if i can prove it easily.
i haven't found the exact spot which finds these .edn files but if u have a look at how the boot-cljs test is done, then you can see it's not assuming any specific names:
it's using the
index.cljs.edn and the
other.cljs.edn files from:
I understood @juhoteperi to mean that since it couldn't find
boot.cljs.main1867 he suspected my cljs.edn could be autogenerated, which is not the case.
the .cljs.edn file represents an application entry point, so the actual generated namespace doesn't need to have any particular name, since you will never be :requireing it from any of your namespaces
I see. The issue that it tried to require a different gensym'd name than was generated still stands though. Not sure what could have caused that.
yeah i'm not familiar enough with the most recent changes to say anything useful about that
im getting a few lines of logs with
2015-11-09 02:18:06.174:INFO::clojure-agent-send-off-pool-0: Logging initialized @30738ms 2015-11-09 02:18:06.227:INFO:oejs.Server:clojure-agent-send-off-pool-0: jetty-9.3.1.v20150714 2015-11-09 02:18:06.328:INFO:oejw.StandardDescriptorProcessor:clojure-agent-send-off-pool-0: NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet ... 2015-11-09 02:18:06.352:INFO:oejs.Server:clojure-agent-send-off-pool-0: Started @30916ms
im looking at the latest commit which is talking about this unconditional cljs.edn reload, but it seems it's always creating a new
i can see this changing name space in
target/index.html.out/cljs_deps.js, but the
target/index.html.out/cljs_deps.js still contains the initial value:
goog.addDependency("../boot/cljs/main852.js", ['boot.cljs.main852'], ['hoplon.app_pages._index_DOT_html', 'cljs.core']);
i always find myself learning a lot about software by looking at how the test harness is doing its instrumentation
I probably only checked that boot-reload reloads worked, didn't try full reload after a change
Test for this particular case should look something like
(let [compile-cljs (cljs)] (comp compile-cljs (test) (touch-files ["demo/core.cljs"]) compile-cljs (test))
And while end-to-end tests like boot-cljs currently does (starts a http server and loads the page on browser) are good, I would like to write unittests against the fileset contents
deraen: have you used generative testing before? im just wondering, because u mentioned unit testing vs e2e...
that's still a question to me but what i gathered from all around the internet it seems to be the same thing
im trying to do some datomic development (again, finally) using boot-test the memory usage grows with every run though and the time required to run my tests too
is there some reference setup somewhere on how to do this without such a "memory leak"?
Anyone seeing an obvious reason for
No matching method: newPod? in the above branch? (https://github.com/boot-clj/boot/pull/340/files)