This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (3)
- # boot (205)
- # cider (41)
- # clojars (1)
- # clojure (76)
- # clojure-colombia (1)
- # clojure-dusseldorf (3)
- # clojure-russia (314)
- # clojure-sg (1)
- # clojurebridge (1)
- # clojurescript (115)
- # css (2)
- # cursive (5)
- # editors (2)
- # funcool (2)
- # hoplon (18)
- # jobs (62)
- # jobs-discuss (28)
- # ldnclj (1)
- # leiningen (10)
- # mount (9)
- # off-topic (4)
- # om (93)
- # parinfer (10)
- # proton (1)
- # re-frame (19)
- # ring-swagger (18)
@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
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
@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.
@dominicm: Allaire created CFML in '95 and Microsoft nearly bought it. They bought another company that created what became asp.
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.
@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.
Is it the case that BOOT_JVM_OPTIONS must be set in the shell env, not from a boot.properties file?
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
on unix it would be pretty easy to inspect the boot.properties and set jvm options before the jvm starts
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?
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.
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.
And i worry about someone accidentally typing “boot dev” instead of “./boot.sh dev” and having different jvm options without realizing it
because i usually want the service to start when the machine boots and respawn if it is killed etc
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)
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?
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
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
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
@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
hmm, yes. but perhaps you misunderestimate the genius of boot? ;) you can put them in a file in a fileset, no?
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.
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.
e.g. some builds can only be made by peeps with the right creds. runtime creds are completely different.
boot has completely blown my mind. I'm beginning to see things I didn't know existed. ;)
thesis: 12 factor is premised on particular technologies. boot exposes that and make mo' better possible.
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.
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?
we have not, but if it's something that people would be interested in we can see what we can do
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
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.
like clojure.core is just a collection of functions, which you can choose to use or not use as you wish
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 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.
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
so the fileset is a way of isolating interactions with the fileset in the same way that pods isolate interactions with the JVM classpath
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
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.
ok the adservers write "logfiles". are they really files? they don't have to be - they're just bytestreams.
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
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.
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
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?
"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.
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.
cool thing is, pods and filesets are orthogonal - you could have either without the other. I think. ?
you might evaluate expressions in there that do, but the pod implementation doesn't use filesets at all