Self host port

[arichiardi]

This is an initial port for lumo and #20.

hildebrand.core compiles, I don't know if it actually works yet :smile:

Many things have been embedded from eulalia and glossop which are unfortunately incompatible.

Also the b64 utilities have not been ported yet.

Still, a feedback is appreciated!

[arichiardi]

This almost looks like a separate project. Basically in bootstrap cljs the macros don't need to go in #?(:clj ...) clauses and that is why I have got rid of the eulalie: I would have needed to modify it as well. Not quite sure yet if I actually need it still.

Also some helpers like for-map can easily be converted to reduce. This is what happened when I got rid of plumbing core.

I opened the PR because I wanted to get feedback on possible approaches, for instance if you'd like to support such effort is have the need.

[moea]

@arichiardi Thanks for trying this out. glossop is a trivial library, but eulalie is responsible for issuing the requests to AWS, and so is a hard dependency, and probably would be the place to start if the goal is to get hildebrand to work in native cljs. If there's a source-compatible way to do the macro part of it (i.e. same source tree works with cljs compiled both on the JVM and in cljs) - by, e.g. defining macros in clj files, and trying to figure out whether it's safe to define cljs counterparts in the cljs files (by figuring out whether we're being compiled in the JVM or not I guess), or whatever people are doing - then I'd be more than happy to integrate whatever other changes are necessary to get the thing working. If it's the case that separate source is required in parts, we could probably get cute with leiningen profiles & source paths, and publish two separate artifacts. What'd be great is a self-contained example of a macro-containing Leiningen project which can be compiled both on and off the JVM.

One thing to note is that I'm working on a successor to this library, and to eulalie, which I should be releasing in the next month or so - which shrinks the number of third party dependencies, and adds browser support. The major user facing difference is comprehensive specs, and the use of promises for single-value results, only using core.async for stuff like streaming query results, etc. If any of that sounds attractive to you, I would strongly suggest making any source modifications to that project, once it's out - though I will continue to do my best to support hildebrand & eulalie in their current states.

[arichiardi]

Oh wow ok that is then a better project to make self-hosted compatible 😀 I can actually help you out and contribute the self hosted part, directly on the new one. Changing all the eulalia lib seemed a bit overwhelming on my side as I only needed the DynamoDB client...

Anyways let me know if you push out an alpha that I can contribute to OK?

I know only of andare as good example of lib that does self-host well and of course my personal Bible is http://blog.fikesfarm.com/tags/Bootstrap.html

Thanks a lot! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[arichiardi]

About leiningen, self host should not be necessary to compile at all, what I do is:

lumo -c $(lein classpath) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[arichiardi]

I still owe your an answer on portable macros: http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-musing.html

And I will close this branch for now, reiterating that I am willing to help on this new port/project and make it self-host compatible. In any case I am working on it and why not sharing the effort?

[moea]

@arichiardi Thanks, I'll give that a look. I'll let you know once I have a release of the updated code.