is there a way to pipe console output back to the repl?

the X/Y of this is: certain libraries like schema and, it appears, spell-spec, output TTY codes that assume a terminal environment. this renders the console output virtually unusable

@lee.justin.m spell-spec doesn't assume tty console

@bhauman but presumably it looks a hell of a lot nicer if you have it (?)

it is possible to produce colors in the console but i’d be very impressed if you’d done that

yes expound does

expound doesn't produce colors in console

expound is what does the coloring

hm maybe i just need to give up on the console and rely on a repl

simpler

shadow-cljs turns on console print by default. i just need to figure out how to turn that off.

yeah figwheel.main redirects printed output back to the repl

and you choose console or repl. but I'd assume that shadow allows that as well

part of me wonders if it wouldn’t be easier and better to just redirect the console to another webpage

i don’t think it would be that hard and then you could do devtools-like things

anyway. getting off track. all i want is readable error messages for when i do type checking. lol

@hiskennyness I get that exact warning pretty often when putting some dev tools in my global lein profile

I seem to have some problems with inferred externs using :foreign-libs with my own bundle.js in combination with :global-exports to be able to require the exported stuff. Clojurescript correctly infers type-hinted methods when using a tag like js/foo.Object but not when using ^foo.Object or ^foo/Object when foo is correctly required. Is this expected behavior, and how am I supposed to use foreign-libs with a webpack-built bundle.js?

@the-kenny typehints are currently not resolved at all and its fine to just use ^js as a hint

@thheller thanks! That's good to know. I think I'll just skip the global-exports part for now then to avoid confusion

I am trying to build my application along the om-next-demo repository. When loading application state from remote It is not normalized into om-nexts default database format by the default merge function. Is this expected or am I using it wrong?

Has anybody used the doo test runner with nashorn? I keep getting the error 'Exception in thread "main" java.lang.AssertionError: Assert failed: Nashorn doesn't support :optimizations :none (not= :none optimization),' when I run 'lein doo nashorn test once'

yeah you need to set the optimizations to simple or something

then it works

can someone explain me the logic behind cljs.string/blank?. In jvm if i call that function with non-string value it gives classcastexception and i expect and understand that because I call type-specific function explicitly and assume no coercion to happen. in clojurescript though it uses goog.string/isEmptyOrWhitespaceSafe (which is aliased by goog.string/isEmptySafe) which makes implicit conversion of argument to string in makeSafe() function. so even for empty object I get goog.string.makeSafe({}) => "[object Object]" and the overall result is false. From where i am standing this behaviour makes no sense so it should either return exception (as it does in jvm implementation) or present some adequate result for non-string object

> True if s is nil, empty, or contains only whitespace. Honestly that matches the docstring pretty well

hm, an empty object is false, so I don’t see how it matches the doc string. however, the doc string is just meant to be about strings I’d say.

i'm taking empty to mean empty string there

yes, and to answer @zallin the fact that clj fails with a class cast is more of an impl detail than anything I’d think

if argument is not a string it is meaningless

clj didn’t make any explicit attempt to give you something useful, it just fails at the JVM interop

not really. all this predicate promises is to recognize blank strings. which is does pretty well

if it is a string fn that expects strings, the only contract is its behavior on strings. this is true in clj and cljs. You can’t rely on undocumented arbitrary impl detail behavior to be consistent across platforms

similar things apply to clojure.set

but the particulars of how Google closure ends up handling it (a) I don’t really know why (b) coercion is a very dominate thing in JS, not so much in JVM

@zallin I think we could get some mileage out of spec here to get both runtime failure and compile time checking

I’d like to have a naming convention for spec files such that we can use them as type information for Google Closure Compiler

I don’t know when I’ll have time to work on this - but I have rough idea of how I want it to work - #cljs-dev is the place to talk about that if anyone is interested

Hi all. Does anyone know why the equivalent of clojure.core/extend is not in cljs? And could it be etc? Sorry if this question has come up before... I failed to Google it. Also, I do realize a similar fn extend-type is in cljs.core. Thanks

it could probably be made to work? but it’s just not a priority

ok thanks. Just wondering about a making a patch then... I submitted a patch for something else a while ago and not got any feedback on it https://dev.clojure.org/jira/browse/CLJS-2589. I appreciate reviewers time is short etc... but so is mine 😉 Is there any way to know when/if patches get looked at? should I try to get votes for the issue for example?

@henryw374 right thanks, yeah no one’s got around to look at one - looks ok - feel free to chime in on Fridays in #cljs-dev on stuff you want me to look at / apply

assume if it hasn’t been looked at there was just more pressing stuff in the queue

Ok thanks, will do

created https://dev.clojure.org/jira/browse/CLJS-2786 for cljs.core/extend impl