Anyone using boot-reload on windows? I can't seem to get CSS reload to work

@dominic: I used to feel that way about frameworks too, but now I feel more like this http://blog.ryanflorence.com/you-cant-not-have-a-framework.html

@laggybit: there was some css reload issue with chrome i think, last year still but it was an long outstanding issue, so not sure if it's fixed yet. we just setup a sandbox project for testing auth0, but we used it to fine-tune the whole page load process: http://github.com/exicon/auth you can try in that repo whether the css reload works for u. it worked for us on mac chrome.

@onetom: I just figured it out: the changed path is sent as-is to the client, that is, with backslash separators

Gotta love windows...

I guess adding string/replace #"\\" "/" somewhere in https://github.com/adzerk-oss/boot-reload/blob/9372def7bdf32c15a4bc85baf7239b21179dfd67/src/adzerk/boot_reload/server.clj#L16 will do the trick

Hmm

@seancorfield: Yeah. A nice little simple thing really.

@alandipert: That's an interesting view actually. The important distinction I think is that you can "update" your framework to your requirements.

@alandipert: yeah the FW/1 framework has existed in CFML since 2009 and is used by thousands so it's evolved based on constant usage. I ported it to Clojure with inspiration from Chas Emerick originally in 2011 I think. Now I'm moving CFML FW/1 apps - that are already used in production - to Clojure in FW/1. It's an interesting exercise.

I hadn't realized how much imperative, state-based thinking (and OOP) was baked into the CFML version.

Oh my, I didn't realise what CFML was. I bet you're glad to be shifting away from that.

It's a modern, dynamic scripting language for the JVM with multiple free open source implementations. But it's not what we want to be building apps with going forward.

Most people still think about the old tag-based proprietary language that Allaire created.

The reason we're moving to Clojure is immutability and concurrency.

Wait, it isn't Adobe's thing?

@dominicm: Allaire created CFML in '95 and Microsoft nearly bought it. They bought another company that created what became asp.

Macromedia bought Allaire in 2001 (I worked at Macromedia at the time).

Adobe bought Macromedia in 2006. I left adobe in 2007.

The free open source versions of CFML appeared around that time and have led the field in terms of language enhancements since.

Oh wow, you've got quite a background @seancorfield. The CFML I've looked at is definitely the tag-based language, that makes me feel like it's an enterprise PHP.

I'll have to look into CFML and see if I can learn much else from it.

@dominicm if you're curious about modern CFML take a look at https://github.com/seancorfield/datamapper which is our CFML wrapper around our Clojure persistence layer (yes, we use Clojure inside our CFML web apps!)

@seancorfield I'll check that out, probably perfect for satisfying curiosity. Thanks.

(The indentation is messed up - we were moving from tabs to spaces back when I posted those but it should give a flavor of the scripting language CFML has become - it has closures, map / filter / reduce on collection types, dynamic meta programming: that code has onMissingMethod at its core, for example, but you can add methods to objects on the fly etc)

just came across http://12factor.net/config which recommends env vars for config stuff. I would've prolly agreed bb. (before boot) now i think not. has boot perverted my mind? wondering how the boot masters would respond to that.

ps. maybe you guys should write a manifesto.

Is it the case that BOOT_JVM_OPTIONS must be set in the shell env, not from a boot.properties file?

@mobileink: i really like using environment variables for configuring the application

@aiba: yes, because the build.boot files is a clojure program, which runs in the JVM

there is no way to have a JVM program tell the JVM how to start up

OK, that makes sense. Might be worth noting on https://github.com/boot-clj/boot/wiki/Configuring-Boot that this particular variable is special in that regard

(I could propose an edit if that’d be helpful)

it could be done in linux, but in windows it would be more difficult

on unix it would be pretty easy to inspect the boot.properties and set jvm options before the jvm starts

@aiba: sure, feel free to add a note as you wish

Actually, that’d be even better, if it could read that var from boot.properties. I assume that’d involve editing the embedded script that exists at the beginning of the boot.jar file?

yes

but that approach doesn't work on windows

If the majority of users are on unixy systems, it could be worth adding it even if it doesn’t work on windows. Personally I’d like that feature and I use osx.

haha yes we've considered that, but it seems like a slippery slope

you can make a shell wrapper for boot

Being able to check in JVM options (for production) to the git repo was a feature I liked about lein. Yeah, in the boot world i just made a ./boot.sh file in git, but it’s an extra file.

for production i will usually make an upstart config or something like that

And i worry about someone accidentally typing “boot dev” instead of “./boot.sh dev” and having different jvm options without realizing it

and i configure the environment there, usually from a file that's checked into git

because i usually want the service to start when the machine boots and respawn if it is killed etc

yeah that sounds like a great solution for production that i should adopt :thum

:thumbsup:

but i guess i also use this for dev. i suppose it’s tricky since there are some jvm options that we want shared among all developers (like which gc to use) and some we want to be personalized (like how much ram to use)

lein profiles worked OK for that

interesting

i can't remember the last time i messed with jvm options for development

i used to have the insanemode speedup jvm options set

but now i just use normal jvm defaults

since i am mostly working in a persistent build environment

like watch mode incremental compiles

yeah, in my case the jvm options are for runtime performance of JVM clojure code that’s sensitive to things like the GC tuning and whether strings are interned, etc., so sometimes we want to change the default JVM options and sync among all developers

but right now i’d be happy just to have the boot.jar shell header read JVM_OPTIONS from a boot.properties file. Would that be a welcome PR if I took at stab at it?

hmm

the windows issue though

it seems like it would complicate things even more for windows users

if windows boot is configured differently than unix boot

actually it just occured to me that i could somehow check whether boot was invoked via “./boot.sh …” or “boot …” and abort if the latter, which would solve my present concern about people not picking up the desired jvm options

yes boot actually binds a dynamic var

i mean a system property

boot.app.path

like the equivalent of “$0” ?

more or less yeah

it has some things to get the full path even if $0 is in your PATH

cool i’m going opt for this and put all the boot vars in this ./boot.sh file, removing boot.properties, so the total number of boot-related files in git remains at 2

thanks for talking this through!

i like it!

oh, and i’ll propose the edit i would have liked to have on that wiki page noting the special status of BOOT_JVM_OPTIONS

if you find it works and solves your problem it would be most appreciated if you could make a note on the wiki

will do!

man, programming at all levels

super into it

way better than adding more configuration!

@micha me too, bb. at least for some kinds of config, e.g a password. but having learned how to work with edn files in boot I'm rethinking. can't really think of an argument against env vars, except maybe that it involves the os. I like the idea of everything hermetically sealed in a clojure env. FWIW I'm soon going to be doing work with the intel edison, which now officially supports java. eager to see how boot works there. think std Linux os env will be available.

yeah the main thing i like about env vars is that you don't need to have a file, so i don't ever need to have anything sensitive in a plaintext file anywhere

like passwords i can have in a gpg encrypted file and just decrpty the file and pipe to eval

to get the secret passwords into my environment

i mean in the shell when i'm developing

hmm, yes. but perhaps you misunderestimate the genius of boot? ;) you can put them in a file in a fileset, no?

where do they come from though? the values?

like my usual workflow is to do something like

eval "$(gpg -d some_secrets.asc)"

then i can do boot build-and-serve or whatever

and it will have whatever passwords it needs, etc from the environment

i have a bash function to automate the eval and gpg part

well I guess they have to start somewhere. btw I'm talking out my butt here. I'm just thinking whatever you can do to get something from e.g some_secrets.asc into the env you could also do to put it in a fileset. sorry, I've gone fileset mad.

oh i see what you mean

that's interesting, i haven't tried that

boot does have gpg support via bouncycastle built in

and also various functions to use the gpg program if it's available on your system

and what if you need diff. pwds for different parts of the build? never thought of this before, but once you erase the distinction between build and app coding anything is possible.

https://github.com/boot-clj/boot/blob/master/doc/boot.core.md#gpg-decrypt

it has an :as :edn kwarg option to support loading encrypted config files

nice. I'll get to it, someday. ;)

fortunately I don't have to worry about that kinda stuff quite yet.

e.g. some builds can only be made by peeps with the right creds. runtime creds are completely different.

very true

like you don't want the noobs building prod stuff.

or you need more access to create resources

but once the resources are created other users with less access can use them

boot has completely blown my mind. I'm beginning to see things I didn't know existed. ;)

like if you have various environments for testing etc

yes!

env stuff is total. with filesets you get security scope!

or at least less gassle.

hassle.

thesis: 12 factor is premised on particular technologies. boot exposes that and make mo' better possible.

yep, Lisp Can Do It

LCDI?

it's a good thing I have a patient bosd. have I mentioned Knuth's warning about Metafont? "May be harmful to your normal intersts." Or sth like that.

precisely!

boss, not bosd.

so you've mentioned models before, I think wrt boot-gae. maybe some kind of boot model (or best practices) wrt config, esp. security stuff is in order for the todo list?

yes i bet there would be some interesting discussion there

when are you guys gonna have a boot conference? your drinks are on me, I promise!

there is @danielsz's boot-system work which is an interesting model

haha where are you located in the wide world?

chicago

we're in Durham NC

have you considered a conf? I think boot is gating to that point.

can't typppe

we have not, but if it's something that people would be interested in we can see what we can do

link to Daniel's stuff? the slack profile is sparese.

https://github.com/danielsz/system

also https://github.com/danielsz/holygrail

he has an excellent video too

ah cool, it's embedded in the readme

thx. let's not forget some kind of conf. by now I'm pretty well convinced boot is beyond category as far as build tools go, that that's just one apical ion of the core cocepts.

no, I don't know what an apical ion is. in on my phone, since #!/&^#comcast went down, again. I think I meant application.

i don't have any experience organizing such a thing, but alan has done similar things in the past

I'm sure that amongst the community we can figure sth out.

yep sounds good to me

World Domination starts in N.C. Everybody knows that.

is boot a framework? I'm inclined to view boot as 2 things. 1. a kernel (mainly filesets), which has no essential connection with build stuff; and 2. an app, which leverages the kernel to support domain - specific (I.e.build) solutions. here's the cool thing: we can view the boot kernel as a language extension, just like e.g. core.async.

and clojure.core is something i would consider a framework, too

like clojure.core is just a collection of functions, which you can choose to use or not use as you wish

but they are universally available

which allows you to coordinate around those abstractions

like consider the issues in scheme with lazy lists and streams

it's hard to coordinate around them because they're not universally available

vs in clojure if you use functions in clojure.core you're going to be able to use lazy seqs

and you can pass lazy seqs to other code that you don't control that also uses clojure.core functions

the word framework pushes people's buttons sometimes but i think frameworks are a good thing

i mean if they're good, of course

I guess I think of a "framework" as an add-on that uses the language. but Clojure's meta programming facilities let us extend the language itself. clojure.core might contain a lot of stuff that is not really primitive, but it does (imo) define the language in some sense. Any defmacro extends the language insofar as it introduces new syntax. So deftask counts as a language extension. But that's specific to build stuff. I think Fileset is a much more general language extension. You haven't broken it out, but you could. you could build an immutable file system lib on filesets, one that doesn't care about builds, just lets you do fs stuff for ant reason with immutability.

ant reason -> any reason

I'm guessing you guys came up with Fileset to solve a specific problem. Which it does. But it seems uchicago more general than that to me.

we haven't really needed an immutable fileset type of thing at the application level yet

the reason we spent so much time on it in boot is because the existing paradigms for bootstrapping a system all revolve around files

uchicago? ? damn this autocorrecting phone! I wrote "much".

so the fileset is a way of isolating interactions with the fileset in the same way that pods isolate interactions with the JVM classpath

haha

also the classpath si intrinsically coupled to files

so to correctly manage one you need to be able to correctly manage the other

ok, but let's forget about classpaths for now. I just want to futz with the filesys, immutably. Filesets! A thing of beauty!

also another thing that's weird about building vs applications is the need for lots of temporary directories

coupling of filesets and cp is specific to the task.

i imagine that applications will probably not want to use temp directories because if something crashes you will want to respawn with those files intact to the application can continue processing them

ah, temp dirs. no! a 1000 time no! ;) that's an implementation detail. don't think about files, think about mamespaced.

i mean like the adservers i work on for example

they write log files that contain the important information they're processing

that's the ultimate failsafe, like if everything crashes those files will be there

boot kernel could be implemented using in-mem db, or remote db, or anything.

and we can pump them back into the data pipeline somehow

ok the adservers write "logfiles". are they really files? they don't have to be - they're just bytestreams.

they're files because they need to be lowest possible technology

like if everything else is down at least you can write to a file

as long as you don't let the disk get full

they're actually files that contain one json object per line, which means you can do things with them manually with shell tools, if you really need to

which is also good when things go horribly wrong someday

do you see what I'm getting at? maybe stoopid, I'm blabbing, filesystem, in-mem database, remote db - who cares? what counts is the interface.

yeah i agree there

that's the beauty of boot, as far as I can see.

that's a cool thing about the classpath btw, too

they engineered it so you don't know or care if it's files, memory, or even some URL that's on a server on the internet

you just interact with "resources"

man, I wish I had about 6 months to write sw based on boot!

I wasn't joking when I said it was Clojure's killer app!

the nicest thing i've heard yet

yeah, I've just begun to see what you guys mean by saying the other tools rely on file locations and boot doesnt. it's really critical but far fromobvious.

now I'm thinking of fs paths as namespaces, which have no location. makes perfect sense!

and when you interact with programs that need named places on the filesystem you can copy things into a temp dir from the fileset, run the program in a pod, and collect the files that program creates and integrate them into the fileset

so you can isolate the pieces that expect the filesystem to have special named places in it

so they don't all need to work together with the same assumptions about the filesystem (when you have multiple pieces like that)

I think of Fileset as kernel, and Pods as orthogonal to that. Neither of which has any essential connection with builds, they're just programming. Sound ok?

totally

"programs that need named places" Step back and look at that a bit. there are no named "places", there are only names. we're tricked into thinking they're places by the filesystem conventions. boot fixes this - when you io/file sth into a tmp-dir your not giving the name of a locn, you're just giving an identifier in a namespace - "location" be damned. in the os fs, the identifier is connected to a locn - exactly like a var is connected to a member locn. Filesets hide the one just like clojure hides the other. The mind boggles.

that's why I think Fileset goes far beyond the boot app.

iow, if you say (def a 0), 'a' is just a name. behind the curtains it is certainly a mem locn, but we don't care - clojure handles it. I think (?) Fileset does the same - you add a "file", which means you map a filename to a bytestream, and you don't care where it is. boot (or Fileset) deals with it.

yep, exactly

beyond awesome.

takes a little work to grok at first, but once you get it there's no turning back.

cool thing is, pods and filesets are orthogonal - you could have either without the other. I think. ?

yep, in fact in boot pods don't have any interaction with filesets directly

you might evaluate expressions in there that do, but the pod implementation doesn't use filesets at all

like you said before, the classpath is orthogonal

and pods are just about the classpath

and the clojure runtime, of course