Any suggestions on boilerplate for Reframe with html and css i.e website header, footer with good styles ? I want to prototype quickly ?

@lilactown IMO there isn't a need for a doc - all core fns that mirror Clojure's are intended to be used in the same way

If you can think of other cases where you feel inclined to do this, I would be surprised. Using aget / aset in this semantically poor way is a JavaScript-ism, not a Clojure-ism

I have a custom deftype -- if I eval a form that contains a value of that deftype (not via a def), though, the compiler doesn't like it. Is that something that just isn't supported, or am I likely to be doing something wrong?

I'm trying to write a custom graphical repl that lets me paste an image, and this is effectively me doing something like (def x image-value) (where image-value is an instance of my deftype)

To be clear, this eval is in an embedded cljs repl ...

In case that makes a difference.

If I just def it, before passing it to eval, it works, so the data is valid, and the concept is fine within normal cljs.

It's just a little difficult in this circumstance to figure out what the difference is with the self-hosted version ...

failed compiling constant: [object Object]; foo.image/Image is not a valid ClojureScript constant.

you need to make sure the reader is aware of that - it's a bit too involved to explain and I would say advanced topic

because in regular ClojureScript reading has to be fixed in two places more or less for real consistency

and I don't think we did anything different for bootstrapped - it could probably be made a little simpler there

but zero priority - if you want to look into that and fix it up (if something is missing or could be improved) - go for it.

Sure, I understand that none of this is likely to get changed without my effort - I'm just trying to understand it better and not resort to hacks like creating temporary defs to solve the problem. As far as making the reader aware, I'm just surprised that it can't deal with instances of a deftype it should know about. I'm not 100% where to begin looking - as far as making the reader aware, do you think this is something that I can likely fix by introducing a custom reader tag ? I don't really want any kind of data transformation to occur - the data is correct.

oh actually it maybe that the reader is actually already working ...

almost I mean - the error is saying that compiler doesn't know about that constant type - we have cases for one

I think we don't automatically embed these values - this would be an enhancement to the compiler for bootstrapped

look at the constant cases in compiler.cljc

Yeah, I was reading compiler.cljc to take a look to see if anything jumped out at me.

you need a case for each kind of constant - in generally we don't allow embeddings because it doesn't make sense in normal ClojureScript

but in bootstrapped this is not a problem

anyways - this is advanced territory and I can't walk you through it

you could also examine Clojure to see how it's done there

@dnolen Hopefully having been a clojure programmer since 2008 I will eventually be able to tackle advanced topics. 🙂 Anyway, thanks for the help and insight. I will see what I can do.

@pmooser great! then dig in 🙂

🙂

I am optimistic! This doesn't seem insurmountable.

sorry a lot of times we get questions about bootstrapped and people want to do things without realizing there's still work to be done

and it's just not a priority because boostrapped isn't a primary use case and never will be

I understand completely, David. I'm grateful that you guys do all the hard work on this stuff so I can write absolutely crazy stuff and it usually works! I know I'm way off in the weeds, so to speak.

I think you need some kind of default case when you know you have an embeddable value

normally we just throw an exception in ClojureScript because it's game over

but in bootstrapped you could say - this is a runtime type we already know about we can embed it

the embedding bit is kind of a head twister - but probably a fun one to sort out

Yes, I will read a bit more of the compiler and see if I can glean some insight about how that might work - but it's interesting and digging into this kind of code will surely help me down the line, sine it's not like the software I write is going to get any less crazy over time ... 🙂

Thanks again!

np

I will say it might be slightly trickier than it seems but pretty cool

I think the compiler and analyzer will both need to be changed, we don't normally put runtime values into the AST

so I think that's what would need to be done, storying runtime objects as values directly

again I think seeing how this is already done in Clojure would be better starting point

I'll take a step back and take a gander at how it's done in clojure then!

if you feel like you've made some progress feel free to open an minor enhancement ticket for self-hosted in JIRA

What’s the recommended library for data visualization?

I looked at metasoarous/oz but could not get it working with shadow-cljs

@dnolen So ... the most straightforward route I managed to find is to mimick what is done for emitting fn references (`emit-fn`) - and it works. I'll have to think a little bit about what a general mechanism like this would be - for my test, it relies upon a defmethod for my custom deftype. But I thought you might find it interesting!

just a sanity check... I can use spec to test frontend, right? works in the browser and there is tooling to run it? Because I am unsure how much of the clojure guides and tutorials actually translate to cljs.

the spec guide should work as is in either clj or cljs

@pmooser ah interesting was needed for testing specs in self-host, @mfikes worked on that bit I think

@pmooser @dnolen The origin of emit-fn is described a bit here https://blog.fikesfarm.com/posts/2016-01-22-clojurescript-eval.html (it is indeed related to self-hosted)

like I said above, I think if we could embed arbitrary values in the AST we could handle this in a more general way and avoid the case by case stuff

but emit-fn is a good jumping off point for thinking about the more general problem

Yup ... thanks for the additional info, I will reflect on it a bit more!