what are the safest non-alphanumeric characters to use in keywords?

Newest version of Clojurescript breaks code that uses Plumatic Schema https://groups.google.com/d/msg/clojure/In88wV63QyE/5daVkzxzBgAJ

question: what do y’all use for widget libraries?

I think schema was depending on undocumented/unintended behavior.

also @john empirically i would guess hyphen 😛

yeah, I'm using hyphens and plus signs. Trying to put a base64 string in the name of the keyword. Every once and awhile I get a reader failure. Not a lot of info in the error though.

the common lisp community usually responds to that sort of thing with a stern finger wagging

and tells you to rethink whatever you’re trying to do

why are you programmatically generating keywords? is it in a macro?

namespaced message tags, of sorts

objects that are programmatically generated at runtime. and the keys refer to the objects

@john https://github.com/edn-format/edn#symbols

ahah

hmm

If -, + or . are the first character, the second character (if any) must be non-numeric.

but, testing read-string on some of those in the repl seems to work fine

and I'm just using pr-str and read-string atm

@anmonteiro thanks for your patch on CLJS-2020 the performance numbers look fantastic.

https://dev.clojure.org/jira/browse/CLJS-2020

@olivergeorge sure. Just looks like we forgot to port a patch over from Clojure

Hello. Is it possible to create tests in ClojureScript dynamically? I've found the approach which works in Clojure: https://gist.github.com/joelittlejohn/2ecc1256e5d184d78f30fd6c4641099e#file-test-clj-L7 But it will not work in CLJS because there's no intern.

@metametadata I don’t think it’s really posssible

@dnolen got it, thanks

@metametadata data there is something called test-ns-hook in the sources, maybe you could hook into that and do your dynamic stuff there

https://github.com/clojure/clojurescript/blob/5cc7865a1e2e9aecc24f975454721f621ba8ee60/src/main/cljs/cljs/test.cljc#L354

@darwin thank you, I'll need to think about it!

n00b question: I'm trying to import an NPM module written in ES6 that isn't packaged for clojurescript. If I use (nodejs/require "uws"), it returns an object that I can call the functions on with no problem. If I add it to my build script in :npm_deps and try to require it, I get all sorts of errors about the clojurescript compiler not knowing what to do with ES6 and telling me to use --language_in=ECMASCRIPT6. Where do I put that flag, or is there another easy way to get it to use ES6 modules?

(I'm targeting node, not the browser)

@adamtrilling I don't know if it is the problem, but make sure it is :npm-deps (dash)

Yeah it is. Should have copied and pasted from my code 🙂

@adamtrilling did you set :language-in :es6 in your compiler options?

should be here then: https://github.com/clojure/clojurescript/wiki/Compiler-Options#language-in-and-language-out

That worked! Now it's having trouble with the module saying const http = require('http');

But that may have to do with the module itself

So I halfway figured out my problem with keywords. I'm pr-string and read-stringing all over the place. And, in certain namespaces, some nameed things are getting ear-muffed with whitespace. It's as if in a particular context, the object printer is using println semantics, where spaces are interposed.

And I have a logging macro that adds namespace data using ~(name cljs.analyzer/*cljs-ns*) and puts it in a ... " <" nspace ":" line-number ">" ... string. Sometimes it prints <my.nspace:56> and sometimes it prints < my.nspace :56>.

and this expansion is apparently happening throughout other places as well, causing breakage randomly

I was interposing whitespace in one of my functions, but I removed it and I'm not interposing anywhere else in the project.

So, keywords like :kname are are getting whitespace earmuffed into : kname

and then the reader fails. Has anyone else seen this behavior and tracked it down?

@thheller: picking up from Google Groups - shouldn't it be possible to run Google Closure on the output of browserify without any issues?

@rohit no, closure expects ONE global scope. but webpack&node create a scope per file

so everything is wrapped in (function (exports, require, module, __filename, __dirname) { CODE });

or similar for webpack/browserify

closure doesn't handle that well

ah ok. I see what you mean. I was able to use it for npm-module-example. GCC generated the minified file but it did complain.

yeah I tried when you wrote the message

but I have tried for ages using the JVM closure compiler so I didn't expect much

the scope thing really is the problem

passing everything into closure is the other solution (where :npm-deps is headed)

currently I do not see this working properly in many cases so I dismissed it for now

code splitting for closure also needs ONE shared scope but no JS tool supports that

Doesn't Rollbar do that?

Sorry, I meant Rollup

https://rollupjs.org/

I think even webpack supports code splitting.

@thheller: I'm gonna investigate this.

As an example: https://rollupjs.org/repl?version=0.41.6&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMHN0dWZmJTIwZnJvbSUyMCcuJTJGc3R1ZmYnJTNCJTVDbmltcG9ydCUyMHRoaW5ncyUyMGZyb20lMjAnLiUyRnRoaW5ncyclM0IlNUNuJTVDbmNvbnN0JTIwdGhpc19leGlzdHNfaW5fbWFpbiUyMCUzRCUyMDQyJTNCJTVDbmNvbnNvbGUubG9nKHRoaXNfZXhpc3RzX2luX21haW4pJTNCJTIyJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMnN0dWZmLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmNvbnN0JTIwdGhpc19leGlzdHNfaW5fc3R1ZmYlMjAlM0QlMjAlNUMlMjJoZWxsbyUyMHdvcmxkJTVDJTIyJTNCJTVDbmNvbnNvbGUubG9nKHRoaXNfZXhpc3RzX2luX3N0dWZmKSUzQiUyMiU3RCUyQyU3QiUyMm5hbWUlMjIlM0ElMjJ0aGluZ3MuanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyY29uc3QlMjB0aGlzX2V4aXN0c19pbl90aGluZ3MlMjAlM0QlMjAlNUIlNUQlM0IlNUNuY29uc29sZS5sb2codGhpc19leGlzdHNfaW5fdGhpbmdzKSUzQiUyMiU3RCU1RCUyQyUyMm9wdGlvbnMlMjIlM0ElN0IlMjJmb3JtYXQlMjIlM0ElMjJjanMlMjIlMkMlMjJtb2R1bGVOYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJnbG9iYWxzJTIyJTNBJTdCJTdEJTJDJTIybW9kdWxlSWQlMjIlM0ElMjIlMjIlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==

The variables from other scopes get renamed so they don't conflict with each other, but they all end up in the same scope in the final build.

@ksmithbaylor interesting, didn't look at rollup yet

(I had to console.log each one since Rollup does some dead-code-elimination)

@rohit I didn't investigate many JS options yet. I know the closure compiler inside-out but nothing else really

could definitely use help from the JS front, like rollup which looks promising

Sure. I don't think we are far from where we currently are.

@ksmithbaylor: https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c

> Use webpack for apps, and Rollup for libraries

Yep! That's the general advice. Although for specific use-cases, it may make sense to use Rollup for apps. The main reason Webpack is a better option for apps is because of its rich plugin/loader system, which makes it really easy to load styles, images, and other assets directly in your source code. If you don't use those features (like if you only have a small portion of your app written in JS, and the rest in CLJS), then Rollup would be a perfect solution.

If there is src/foo/bar.cljs and dev/foo/bar.cljs, and you set your project.clj to :source-paths ["dev" "src"], which of the two files will take precedence with figwheel?

I wonder if devs ever decide to f- wit people on these issues by having it pick a random one, based on the day of the month, i.e. "odd numbered day? take dev" "even numbered day? take src" -- this way, it's not obvious it's random (since it's constant for any given day), but causes a new eadache every day 🙂

funny you should mention that

I think it's actually random in my experience - sometimes figwheel picks dev, sometimes src

or pick the one with the latest modification time, that'd be evil too and hard to debug 🙂

well I actually thought I was being clever by lettings developers in our team override a namespace by adding an overriding "dev" ns

correct me if I'm wrong but this kind of hack is pretty common in Clojure, where the classpath works reliably

this is insane, people in clj dev purposely have overlapping names and predict which one the jvm picks to load ?

@pesterhazy I used to do it by having dev and rel folders and same namespaces in them, but putting only one of them into :source-paths

that always worked predictably, these days I prefer :preloads compiler option if possible

@darwin, that would require devs to change source-paths accordingly hm...

@pesterhazy should be fairly simple, the jvm classpath decides. so in your example src wins

but given that figwheel watches files, it may load the dev one after the fact

@thheller that's what I thought, but that's now how it works, at least with figwheel

not sure which folders figwheel watches by default

in shadow-devtools you actually get a warning for these things 😉

the whole point of this was to add a feature.cljs, which developers can keep outside revision control

so they can keep their personal copy of feature flags

if I ask developers to update project.clj to add a classpath, that sort of defeats the purpose of the exercise 🙂

there is also :source-paths for clojure macros on project.clj root level, which might interfere with :source-paths on cljsbuild level (assuming lein), I guess

yes, using lein here

@pesterhazy feature flags could easily be a file, you can load it as part of macro code and then decide which cljs code to emit based on it

hm right

so the problem is that you can't require a file but also ignore it if it doesn't exist

but a macro could do that

or you could put it into env: https://github.com/binaryage/env-config

indeed

I'll try the macro route

@darwin, that worked, thanks!

Just found one of those bugs where my view wouldn't update when a local state atom changed.

Problem was my deref was inside a (for...) loop and so the lazy seq wasn't evaluated yet (so no deref happened).

Good...

(into [:tbody]
  (for [id ids]
    (let [has-focus? (= id @focus-id)]
      [:tr "xxx"])))

Bad...

[:tbody
  (for [id ids]
    (let [has-focus? (= id @focus-id)]
      [:tr "xxx"]))]

I wonder if re-frame could report a warning where lazy-seqs are returned from views.

Or if I could pick it up with a spec.

Too tired to make a proper announcement but I just pushed the first preview version of the shadow-cljs npm package.

https://www.npmjs.com/package/shadow-cljs

npm install -g shadow-cljs
shadow-cljs --once
node
var x = require("shadow-cljs/cljs.core");
x.enable_console_print_BANG_(); // oops
x.prn(x.assoc(null, "foo", "bar"));

More tomorrow ... I need sleep. 😉