Fork me on GitHub
#lumo
<
2018-03-22
>
rickmoynihan12:03:20

Does lumo support defmacro??

rickmoynihan12:03:54

I understand clojurescript doesn’t (except through clojure & :require-macros)

rickmoynihan12:03:07

Oh just seen this issue opened the other day… which seems to be related to what I’m doing: https://github.com/anmonteiro/lumo/issues/377

rickmoynihan13:03:16

Interesting… Evaluating following in lumo:

13:02 $ lumo
Lumo 1.8.0
ClojureScript 1.9.946
Node.js v9.2.0
 Docs: (doc function-name-here)
       (find-doc "part-of-name-here")
 Source: (source function-name-here)
 Exit: Control+D or :cljs/quit or exit

cljs.user=> (defmacro foo [form] (println "macro executing with form: " form))
#'cljs.user/foo
cljs.user=> (foo {:some :form})
macro executing with form:  nil
nil

rickmoynihan13:03:42

looks like macro args are passed as nil

moxaj13:03:20

@rickmoynihan I think if you'd like to define macros in the repl. you have to do so in the pseudo macros namespace

rickmoynihan13:03:48

@dnolen: sorry this has got split across channels but related to my question in #clojurescript and to round off my understanding… what is up with defmacro in lumo? I understand in classic cljs macros are only supported in clj (and refered in via :require-macros but curious why defmacro doesn’t error sooner.

hlolli14:03:42

@rickmoynihan the macro won't work like this. You have to put it in .clj/c file and require it, so that lumo can compile it into cache. Runtime macros like in clojure don't work in clojurescript. It's hard to know with figwheel etc, then it gets compiled on save. But it's same when I start node repl with piggyback, shadow-cljs or planck

rickmoynihan16:03:25

Thanks will try later

hlolli14:03:13

also I don't think dnolen is on this channel

mfikes14:03:57

So, you fundamentally need defmacro to not blow up when compiled as ClojureScript so that self-hosted can work.

hlolli14:03:04

So I recently got new computer, installed nixOs on it, and was planing to start lumo now. @mfikes you were useing nixos some time ago right?

mfikes14:03:07

@hlolli Well, I have a build environment that I try to test Planck in. https://github.com/mfikes/planck/tree/master/build-envs

hlolli14:03:32

makes little sense to install it via npm on nixos, just need to make a derivation for lumo and push it to nixpackages 🙂 but I'm learning this slowly

hlolli14:03:12

ah you make nix-shell

mfikes14:03:41

Yeah, it seems that it is not possible to get away with the "single Linux binary" when it comes to nixOS

mfikes14:03:12

For the Planck build environments, they are bona-fide distros, just run via Vagrant

hlolli14:03:29

good thing about nixos is that we could make derivation that builds lumo in sandbox, with all dependencies in environment, and it should work easy for all users

mfikes14:03:10

If you are into nixOS, fix clj for it while you are at it 🙂

hlolli14:03:57

cool, my friend is deeply in it, I can mention this to him and we can take a session adding these derivaitons.

hlolli14:03:06

going to meet him this weekend

hlolli14:03:59

you say fix, is there already something started for clj on nixos?

mfikes14:03:27

I suppose this is off-topic for #lumo sorry. But someone should probably file a JIRA for this, fix it etc

hlolli14:03:50

hm yes, this shell script will never work properly on nixos, the bin path is immuteable and declareative, it would just get deleted I guess after restart or rebuild 🙂 but should be easy, I say as nix noob, to make a nix derivation out of this.

richiardiandrea15:03:48

@hlolli are you planning to use nixos for dev? I am interested in listening to your experience report as I was thinking about that as well. At the moment I use only the package manager. About lumo, there was for sure an issue open for that

hlolli15:03:56

@richiardiandrea yes I remember ticket being about that and static linking for lumo, but I think that's very un-nix-ish approach to solveing this. I'm useing nixos for dev, first week I regretted it, then, I accepted it, now I'm realizing that it's probably going to save me headaches in the long run. One doesn't have to configure absolutely everything in nix like some users to, enough to rely on system packages, and for example emacas, I still use use-package to be declareative. But the pro would be to get 100% replica of ones environment just with configuration file, and it will work.

richiardiandrea15:03:28

Yeah that is the aspect I am most interested in. I keep my conf files in a repo so that I can apply them to any (for now Ubuntu-based) distro. The next approach is better because I could have a custom package derived from system or something, dunno

richiardiandrea15:03:12

Still looks like a lot of work though 😃

hlolli15:03:16

good example last weekend I had to uninstall pulseaudio and nvidia dirvers, I could uninstall and install, and everything worked still. In fedora for example I would have to uninstall xserver if I uninstall pulseuadio. So every dependency is "sandboxed", it's really mind blowing.

👍 4
richiardiandrea15:03:26

Yeah that is cool

michaelwfogleman22:03:46

Can you use cljs libraries from lumo?

richiardiandrea22:03:03

@michaelwfogleman yes you can, you need to resolve them first, then you can call lumo -D lib-name:version

🙏 4
richiardiandrea22:03:12

aka, they need to be in .m2

richiardiandrea22:03:29

if you get exceptions though, it probably means that they are not self-host compatible (yet)

michaelwfogleman22:03:42

@anmonteiro I just mentioned in DM’s with @richiardiandrea that I would be willing to contribute to making a “Lumo Shell Scripting 101” type document, with some assistance here. Is that something you’d be open to?

anmonteiro22:03:56

I’d love that

anmonteiro22:03:16

submit a PR adding a .md file to a docs/ folder

anmonteiro22:03:24

we’ll take care of formatting it later

👍 4
michaelwfogleman10:03:25

@richiardiandrea Is this a blocker for the work I mentioned?

richiardiandrea15:03:15

No I don't think so, we can also write on the lumo wiki

4
dominicm10:03:37

I seem to recall that anmonteiro wants to self host - but that may not be true.