This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
The Github integration is quite verbose 😄
I don't mind either
Do you think it would be possible to get GPG changes to the next version?
It shouldn't
I don't think I have permission
@micha: Thanks
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
Woah cool way to integrate the video with slides
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
@danielsz: I have recently updated metosin's component library: https://github.com/metosin/palikka
@juhoteperi: Oh nice, I wasn't aware of this.
@juhoteperi: Would you like me to put a link in system's README to this or is internal stuff?
@danielsz: It's not internal but I don't think link is too useful
But would be cool if you have time to check the differences sometime and tell what you think
Could be useful to copy some ideas to System
I guess some features have minor drawbacks, like it requires Schema and tools.logging
Also, @micha, here is my take on environment configuration: https://github.com/metosin/maailma
@juhoteperi I love this, you reinterpret everything to your taste. That's the spirit, young man.
@danielsz: Thanks
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 😄
@juhoteperi: very interesting
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
I'm getting 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
How recent is the problem? Does -1 work?
Are you using automatically generated cljs.edn files?
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
That's preferred
but if you don't have any, boot-cljs will create one
that would explain the number on namespace name
i moved (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:
https://github.com/adzerk-oss/boot-cljs/blob/1894176517405d7d67d62b6a4adf73534b05d2f3/build.boot#L28-L32
it's using the index.cljs.edn
and the other.cljs.edn
files from:
https://github.com/adzerk-oss/boot-cljs/tree/1894176517405d7d67d62b6a4adf73534b05d2f3/test/demo
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 boot-jetty
, like:
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 main...
namespace
https://github.com/adzerk-oss/boot-cljs/commit/5a614c7ef8df1cd7f809a9204cac4eb49f329013
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']);
Oh, calling gensym each time is not good
I wonder why I didn't see the problem
I should probably also remember to run boot-cljs tests before releases...
Okay, I managed to reproduce this
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
I think I found good way to test this
I can reproduce the ns name changing in tests but the tests still pass
Well, there's the fix. No tests yet.
@onetom: Can you try master before I make a new release?
@jaen: -3
should fix the problem
Testing boot tasks is an interesting area, could use more investigating.
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...
hmh is generative testing different than property based (test.check)?
I keep looking for places to use test.check but haven't used it yet
that's still a question to me but what i gathered from all around the internet it seems to be the same thing
@micha: how about merging the boot builds boot branch? 😄
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)
the diff lists it as "renamed unchanged"