Ok figured I needed to return different source based on the macros var for my test to work (it does not cover all the cases I have to admit).

@shaun-mahood like Clojure there’s no long term view beyond the stuff I mentioned in my talk and those things have been known for years. The process is primarily iterative and focused on baby steps.

@shaun-mahood people have repurposed the compiler for other targets - though that use case could probably be enhanced significantly (public APIs). Based on my experience with ClojureScript I would say just getting going on a new platform is probably a reasonable amount of work - and then there’s the multi-year long tail of making it work great.

@anmonteiro sorry http://dev.clojure.org/jira/browse/CLJS-1536 needs a rebase because of the tests

🙂

probably time to split up the core tests 🙂

no problem, doing it now

thanks

@dnolen yea maybe we should start addressing that incrementally as new patches would need to add stuff to core-test?

yes

if no one else gets to it, I’ll do this on Friday

@dnolen replaced the patches with a rebased one http://dev.clojure.org/jira/browse/CLJS-1536

thx for the heads up

@dnolen: Makes sense, thanks.

@dnolen @mfikes I wonder if it should be possible for self-host to ignore :require-macros if: 1. we’re consuming code with :macros true in cljs.js and 2. the :require-macros refers to the current NS

I think this would solve the max stack exceeded error that we now have

and it would make possible to consume code which employs the “macro loop” pattern

I suspect that the analyzer would have to be aware that we’re consuming macro declarations in the :cljs branch, if it’s not already

@dnolen @mfikes FWIW, the following is working fine for me. It allows a single .cljc file that requires its own macros to work fine in Bootstrap! https://github.com/anmonteiro/clojurescript/commit/bde28d85a2a0846adbd4bf73e73f48b8dabbbfe8

worth capturing the above in a JIRA ticket?

@anmonteiro but the ticket needs some explication - I haven’t been following this one that closely

@dnolen it’s the problem we have in the om.next namespace that doesn’t allow it to be required in self host

because it requires its own macros, self-host ends up requiring itself over and over

ah right, OK, still a summary about the problem describing the minimal case will be useful

I can obviously add more context to the ticket

won’t be able to keep the context when I actually get around to looking at it

definitely

I’ve got a very minimal case that doesn’t work without the patch

excellent