cljs.core/declare seems to not work in the repl. Is this a known bug or perhaps somethings wrong with my environment?

I found this old jira report http://dev.clojure.org/jira/browse/CLJS-445 but it’s closed as “Completed"

Is there something similiar to clojure.lang.PersistentQueue for cljs? I want to "rotate" a list efficiently, like using pop and conj on a queue

@profil there is PersistentQueue deftype right in the cljs.core

Oh, yeah

I just found #queue [1 2 3]

@wagjo: Thanks 😃

@jonas: FWIW, declare actually does affect the analysis metadata at the REPL. The problem is that the compiler doesn’t emit valid JavaScript (it is really a NOOP from that perspective).

You even get no evaluation warnings in a case like (do (declare g) (def x 5))

declare and def without an init form could probably be made to work at the REPL; we already have at least one thing in master that works differently to cater to the REPL: http://dev.clojure.org/jira/browse/CLJS-934

Where best can I catch up on the status of bootstrapped cljs?

@phil: https://github.com/clojure/clojurescript/wiki/Bootstrapping-the-Compiler

@minimal: Ta.

@phil: hi! 😉

@onetom: sup!

nothing special. just joined here. got the hint on the freenode#hoplon channel

@wildermuthn: This article might interest you http://dev.solita.fi/2014/03/18/pimp-my-repl.html

@wildermuthn: Specifically the “Keeping utilities at hand with Vinyasa” section. It sounds like it’s implemented similarly to your idea of tossing things into .core though

@dnolen: I noticed that numbers and ‘default’ yields sequential hash code values. I’ve got a map w/ dom nodes as keys & i’m wondering if a better distribution of hash values would perform better

Anyone have any experience integrating Google maps into an Om project? I am getting alot of “Uncaught TypeError: Cannot read property 'x' of undefined” errors.

This is what my code looks like: (defcomponent page [_ owner] (render [_] (dom/div {:class "maps_page" :ref "map-canvas" :style {:width "100%" :height "100%"}})) (did-mount [_] (let [map-div (om/get-node owner "map-canvas")] (google.maps.Map. (clj->js map-div)))))

No idea if this is the right way (probably isn’t)

You shouldn't need to call clj->js for that (get-node should return the native DOM node).

I would step back and make sure you're getting the element and can manipulate it before bringing the google maps stuff into it

you’re missing #js

Hmm yeah you are right. It does give me the element though.

which is a syntax-time clj->js

#js {:foo 1} is shorthand for (js-obj “foo” 1)

and om expects raw js objects for it’s prop maps

note that the transform is shallow, nested maps or arrays need their own #js tag

@bbloom: Is the right syntax #js (google.maps.Map. (clj->js map-div)) then?

no

clj->js is a helper function that, at runtime, recursively converts a cljs map to a js object

#js is a reader literal which, at compile time, produces a js object in the output

(dom/div {:class should be (dom/div #js {:class

which is shorthand for (dom/div (js-obj “class”

…. i hate slack’s insistence on smart quotes

I am pretty sure that isn’t needed. I am using that syntax, without the #js in other components without any problems

if it does work, 1) i’d be surprised that dnolen changed that and 2) it’s definitely slower

look at all the examples: https://github.com/omcljs/om/wiki/Intermediate-Tutorial

and since #js is shallow, you also need it on the style map: #js {:style #js {:color “red”}}

Ok, fair enough, and thanks for the pointer.

Doesn’t make any difference though in terms of google maps though I am afraid.

do you only get errors in advanced compilation mode?

No it’s in dev mode with figwheel

I haven’t gotten the map to show up at all

Can you try adding a logging statement to did-mount to verify it’s running correctly?

(.log js/console “message”), etc.

Yeah, just did and it is running fine.

I am having some trouble with figwheel dropping the Google Maps dependency though

Getting alot of “Required namespace not provided for my.maps.namespace"

What does google.maps.Map eval to in the browser’s console?

It evals to 'function Zk(a, b)'

…. are you sure you aren’t doing advanced compilation?

b/c the error you’re getting and the Zk(a, b) etc suggests to me name mangling issues

i don’t think you can’t mix advanced & not advanced, if the google maps stuff is already advanced compiled

well I am in figwheel. I don’t think that even works with :advanced and my profile is set up for :none, but it is looking wierd

I am using an externs file though: :externs ["google_maps_api_v3_20.js"]

@casperc: the google.maps script is probably minified

from the Google Closure compile github

are you sure that externs file correctly? what if you give it an invalid path, do you get an error?

s/file correctly/file is used correctly/

are you sure the versions match?

yeah I was getting compile errors until i put it in the src directory

@casperc: are you using schema/om-tools?

@bbloom: that might explain why clj->js and #js are not needed

Yeah I have prismatic/om-tools

s/schema/prismatic yes

Could be, I always had it in there

bbloom: is right, om.dom takes js objects while om-tools.dom takes whatever you give it.

@bensu: i didn’t even know that existed 😛

also, are you importing goog.maps with cljsjs or by your own?

Yup it is om-tools indeed i am using

on my own, but I might try it from cljsjs

@bbloom: it's nice sugar but probably not your thing.

I only just found it by googling

@casperc: consider using cljsjs it solves all this problems for you

and adds no overhead

s/this/these

I’ll give it a try.

oh yeah, prismatic stuff. shrug

@bbloom: haha I knew it wouldn't be for you, I like their libraries though.

they’re loaded with macros 😛

I was just slightly put off by the fact that it was not completely up to date. It is at v3.18 for google maps, and the official current version is 3.20. And since it doesn’t actually include the js library, just the externs, it might cause trouble

I’ll give it a look though

yeah, but some of them won me over: schema.core

@casperc: it does include the library, just not in the source, read the build.boot file.

@casperc: if you want the latest one, packaging it is trivial, usually changing the version number somewhere in build.boot

@bensu: compare to https://github.com/miner/herbert

Yeah, guess that is the way forward next

Thanks for the input all. Bedtime for me.

@bbloom: how come I've never seen this before? Is there a way of using it with defn or one just writes {:pre (conforms ...)}

@bensu: you haven’t seen it before b/c there’s no venture back startup attempting to advertise themselves via it

but yeah, just use :pre

@bbloom: don't be snappy! it's not like they run invasive advertisements

language interpretation beats functional combinators every time

https://www.youtube.com/watch?v=4JGu33WF0Us

I'll give it a go over the week.

herbert clojure talk

i haven’t used it myself, but herbert’s approach is much preferable to me

@kamn: thanks!

@bbloom: I'll have to port it to cljs.

shouldn’t be hard

i bet you mostly just have to add c to the file names

yeah, looking at it there are only a couple of namespaces that use java interop.

but the dependencies might not be cljs.

give it a shot

anyway, this approach is seriously preferable b/c it doesn’t rely on an evaluator to build a schema object. instead it relies on an evaluator to interpret data… which means you can parse and manipulate schemas directly w/o special library support

let's see if I follow: on other words, the schemas are closer to the language.

are you familiar with the idea of a functional combinator library?

I hope core.typed integration becomes more of a thing, particularly for CLJS

(it used to work, but CLJS changed and c.typed hasn’t kept up)

@bbloom: not at all. but give me a week whenever I talk to you 5 minutes I spend a week googling stuff.

haha

Herbert seems to like in band signaling though, which is a mixed bag

let’s imagine a library of “schema combinators” which have the function signature x => valid?

@lvh: hi! never tried core.typed

you can take normal predicates like string? and use them as validators, or you can build up more complex ones

the fundamental difference in implementation is that core.typed operates only as a compile-time linter

(defn both [f g] (fn [x] (and (f x) (g x)))

so, I mostly just want them to share data so they add together

@bensu: that both function is now a predicate factory, and many of those things will form a “combinator library"

but you could also have done this: (defn both [a b] (list ‘both a b))

@bbloom: I see where your are going, that is why the error messages are so bad, fn closures are opaque.

yup

The latter is also amenable to optimization

if you do the list ‘both thing, you can now do (defmulti validate? (fn [schema subject] (first schema)))

now the validate? multimethod is an interpreter for the schema language

and you can also do: (defmulti compile first)

or, like @lvh, optimize

simplify

convert to english

whtaever

don’t glue your records to your record player.

@lvh so core.typed does not work with cljs currently?

kamn: unless you use a very old version of both, no

That's really too bad

schema internally has to have custom types for every “ast node"

and methods for all the different types of ways to use a schema

it’s very un-clojure

@bbloom @bensu: I’ve not used the schema library much (or any combinator library really). Can you give an example of a bad error message?

schema goes out of it’s way to recover the input syntax to provide sensible error messages

if it didn’t do that work, it would just fail w/ like a memory address of the function

@bbloom: Also, was that an arbitrary design decision, or were they limited by how they wanted the library to behave?

there’s nothing you can do w/ functional combinators that you can’t do better another way

functional combinators just save you some typing - it’s nice for prototyping

until you need a second interpretation, then you have to do that typing anyway

Right, so they don’t know who gave them the function, just that it failed. The call stack should have some relevant info though, right?

potetm: either way the call stack will be the interpreter’s call stack

@potetm: if you use (s/either SomeType AlmostThatType TheValidatedType) and it fails on AnotherThing the message explodes with descriptions of all the types, and nothing pointing to which of types in the either caused the failure.

but if you have the original syntax, you can use it as part of the error message

given: (defmulti validate (fn [schema subject] (first schema)))

(defmethod validate ‘both [[_ a b :as schema] subject] (when-not (and (validate a subject) (validate b subject)) (throw (ex-data “Validation failed” {:schema schema :subject subject}))))

if schema was a function or other opaque custom object, i’d have to do extra work to recover the syntax to report it in the error

my code is obviously wrong mixing validate and valid?

but whatever, you get the idea

Right. So, point being, transmit the data, parse the data. Don’t build some arbitrary, opaque verification.

yup

and then later when it’s too slow for a particular need, write a compiler 😉

Thanks for the clarification Much appreciated.

@bensu about the either operator: https://github.com/Prismatic/schema/pull/134

@bbloom: cool, useful rant. I just watched @ztellman talk on macros (very good btw) so I'm ready to write some macros. I have ~3kLOC using prismatic/schema it would cool to redefine the s/defn macro to use herbert schemas and make a smooth transition.

@bbloom: that PR explains a lot.

personally, i prefer handwritten validators

unless you really do have a need for generic validation

for all the same reasons why people still write parsers by hand

Is there a way to have :pre and :post on functions enabled on a dev build and disabled on a production build?

some compiler option?

yes, :elide-asserts true

it’s documented on the wiki

Ah. perfect

Thanks!

@bbloom: one other thing I forgot to ask you last time: after reading that cljs-vdom was not interested in providing cross browser compatibility I went and read React's synthetic event layer. It is not the greatest thing, but it doesn't change much. Do you think it would be a lot of work to extract it and apply it over cljs-vdom?

@bbloom: ditto for goog.events

@bensu events need a tad more hammock time

i just pushed a change to cljs-vdom to enable reverse lookup (node -> vdom id), which is necessary for event routing. still trying to figure out how to use it

react.js also does some voodoo to make events faster in ways that only really seems to matter for mobile (eg fewer allocations) - i’m not interested in mobile

@bbloom: agreed, I've been in that hammock for months now without good ideas. What I do know is that any event system (or whatever replaces it) could use the browser compatibility layer that those huge projects provide.

so i expect to achieve browser compatibility via a component library, not via low-level normalization & polyfill

eg a button component, rather than making onclick behave uniformly for everything

I can see that, but what happens when you need to offer an escape latch for that person that needs the onclick, do they get the browsers onclick?

yup

which, IMO, is preferable to what react.js does now

which is if you want to hook events that they don’t normalize, you need to manually addEventListener and removeEventListener

instead i want to provide dom virtualization separately from component event handling

delegation and such will be built in to the component system

@bbloom: decomplecting for the win

ok, last question, do you have any opinions on FRP a la Elm?

elm is pretty neat, but i remain skeptical of FRP for UI

ok, thanks! I'll leave you alone now.