Do clojurescript projects still require [org.clojure/core.async "<VERSION>"] in project.clj?

hi

how can i formate a timestamp in hiccup?

anyone used fabric.js together with om before?

i can use some simple functions from just fabric.js

but i can’t figure out how to render a fabric canvas in an om component

@krchia sorry for the delay, what do you have sofar?

i got it now, but now im not too sure how om works

are you familiar with react?

no, i’m learning both at the same time

if i’m not wrong, om is a way of making separate components

and they all read/write from app-state.. something like that right?

Om is changing a lot right now, so it is important to distinguish between the upcoming version “Om.next”, which is in alpha right now, and “Om.now” which the examples from Om’s readme are using.

hah solid point

But they both provide ways to help manage your client applications state; Om.next provides a more complete package but is also more opinionated and there are more concepts you will need to understand to get started.

i think i have more low level problems right now

like syntax

i have a dom/canvas in om/IRender

then i have to wrap it with fabric like so (def canv (new js/fabric.Canvas “canv-element”))

and i can’t refer to canv inside the component for fabric method calls..

if i have an (.add canvas img) function, where should i place it in the om component?

ok cool

so this is a nice introduction to reacts life cycle methods

is this a helpful gist or is it confusing to see the example in js? https://gist.github.com/sebmarkbage/6f7da234174ab9f64cce

fabric wants a mounted dom node

and using react life cycle methods you can can hand off the dom node when its 'ready' if that makes sense

im not really sure what’s happening when i call a function like (.add xx), i don’t know where fabric stores the state

so i can only can use fabric method calls on a mounted dom node? how can i update the state inside the om component then?

maybe i should put aside om for now and just work with fabric.js

im not even sure if what im asking makes sense

it makes sense, but i just need a little more info to be helpful

sure there are examples of people using om and canvas lemme see if i can find a good one for you

i have plenty of those examples

i.e. goya, but not one using fabric.js

https://github.com/xtrntr/editor/blob/master/src/cljs/core.cljs

i’m trying to figure where i can put in (.add canv rect) in line 70 inside the om component main-canvas

hmm

so this line https://github.com/xtrntr/editor/blob/master/src/cljs/core.cljs#L26

https://github.com/omcljs/om/wiki/Documentation#ididmount check this out

particularly this line >The DOM node associated with this component can be retrieved by using (om.core/get-node owner)

ah

i get "Warning: ReactMount: Root element has been removed from its original container. New container:"

i think making a fabric wrapper around the original canvas elements does some funny things

Anyone wants to help me out with JavaScript dependencies? http://stackoverflow.com/questions/34352645/how-to-use-foreign-javascript-dependencies-in-clojurescript

@jindrichm: I'll try to answer

@jindrichm: let me know if that helps

Hi guys. I’m trying to get cljs, nodejs and core.async play nicely together but can’t load core.async library for some reason. I would appreciate if anyone can help me figure out what’s wrong with my setup: https://gist.github.com/erasmas/5f212d770ef375b8bf47.

@dmi3y: I think :refer is not supported w/ :require-macros

@martinklepsch: maybe, but I’m getting the same error even if I remove :require-macros

@dmi3y: what are you running to get to that stacktrace?

@martinklepsch: Unfortunately, the issue prevails.

@jindrichm: make sure core.async lib is in your classpath when compiling

@mfikes: It's listed as a dependency in project.clj. Why do you think it's missing? Wasn't it a response to @dmi3y?

Yes, meant @dmi3y reason being the gist indicates it can't find the files in the stacktrace

Sorry, got pulled into a meeting. This issue happends when I start REPL from Cursive and doesn’t happen when I execute as rlwrap lein trampoline run -m clojure.main scripts/node_repl.clj. So I guess I need to figure out how to properly start node REPL from Cursive. Thanks all for your suggestions!

@martinklepsch FWIW :require-macros supports :refer. See https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#namespaces

In the ever-persistent quest to clearly explain the constraints placed upon ClojureScript macros, I’ve updated the wiki, and felt that perhaps a new term needs to be coined to help describe it. (compilation scope for now). Here is a bit about the need for a name to describe the concept: https://gist.github.com/mfikes/1c2e701036e8caced17f And diffs to the Wiki to help clarify, using the term compilation scope for now: https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure/_compare/001b020761f33a75d5e6e82b13100c2c1d616306...083d4010fc7849d795a9f0a623318385d711147c Interested in thoughts on whether this clarifies or makes it hopelessly complicated.

Sorry, if that seems like a strange question but is it possible to use >!! and <!! with cljs ?

cljs.user=> (def a-channel (async/chan 1))
#'cljs.user/a-channel
cljs.user=> (async/>!! a-channel "Hello, world!")
WARNING: Use of undeclared Var cljs.core.async/>!! at line 1 <cljs repl>
TypeError: Cannot read property 'call' of undefined

@dmi3y: That would block the only thread right?

@dmi3y: No. Since you don't have threads in JS, you cannot use thread-blocking >!! or <!!.

Right, makes sense, I forgot I’m in JS land … 😊

@mfikes: cljs macros is definitely a blur subject coming from a backend. I think compilation scope describes it well since it has a "time" (compilation) and "place" (scope: clj / #?(:clj). I feel that one thing that you removed "Macros are written in Clojure" was helpful. It might makes sense to mention somewhere that "Macros are written in .clj or .cljc within #?(:clj ... ), and are referenced in .cljs or .cljc within #?(:cljs ... )"

@tolitius: Interestingly, you can write macros in .cljc within #?(:cljs …) if targeting a bootstrapped environment.

@tolitius: In other words, you could argue that in a bootstrapped environment, macros are written in ClojureScript. Thus the need to delicately remove “written in Clojure” while preserving the true constraint.

Thus the attempt to boil it down to a one-liner that might actually be meaningful (and also accurate): "ClojureScript's macros must be written in a different compilation scope than the one from where they are consumed."

@mfikes: I think maybe the CS-y thing to say here is that ClojureScript compilation is staged, and the ClojureScript compiler(s) disallow mixing stages into the same namespace.

@dnolen: Yes. That could answer the question: “Can a bootstrapped macros file itself consume macros?” and the answer is “Yes, if those macros are in a different stage”. (Reminds me mathematically of classes in non ZFC set theories for some reason.)

So, instead of compilation scope, use compilation stage, or even just stage if context is clear.

@mfikes right that’s a interesting point though probably one that’s very subtle if you haven’t really thought through the implications for bootstrapped ClojureScript

In bootstrapped I picture an unbounded hierarchy of stages. But yeah, I bet there are subtle things where something can fall apart

@mfikes: https://www.cs.utah.edu/plt/publications/gpce13-f-color.pdf

worthwhile related reading for this discussion

Yes… they use phase. Will read.

@mfikes: ah.. bootstrapped, you're right. then maybe the answer to the question "so, can I do a defmacro in ClojureScript" would be "yes, but only in bootstrapped. otherwise here are the stages/phases.. where a macro can be defined. and here is.. how it can be then referenced in cljs". this is of course to only simplify the beginning "stage". I feel hiding clarity behind stages/phases could sound too "monadic" for beginners

@tolitius: Yeah. I suspect there is a way to convey the rules that is both simple and accurate.

For some reason, I want one sentence, like "ClojureScript's macros must be defined in a different compilation stage than the one from where they are consumed."

@tolitius: the rules aren’t any different in bootstrapped really

At first blush, I can’t poke any holes in the sentence above.

you still have phases

but as @mfikes has discovered will you will get a “tower” of phases in bootstrapped

Right. I want the one sentence to apply to JVM and bootstrapped. A sentence that conveys the salient concept that a developer needs to know.

@dnolen: can you defmacro within #?(:cljs …) when not targeting bootstrapped, or you would not consider it a rule, just a different phase?

@tolitius: there is not semantic difference between bootstrapped and non-bootstrapped

it’s the same compiler

that means no macros in non-macro namespaces

@dnolen: I am still exploring the cljs universe, but I thought if you were to bring clojurescript dependency with an aot classifier, it would not compile a "defmacro" unless it is under #?(:clj ...). maybe I am just missing something obvious

AOT has nothing to do with this discussion really

the AOT artifact is just about process boot time

@dnolen: ok, I'll experiment further to understand it a little better. I had to wrap all the "defmacro"s in "#?(:clj …)" when switched from [[org.clojure/clojurescript "version"]] to [[org.clojure/clojurescript "version" :classifier "aot"]]. otherwise it would not compile. that's when I thought that AOT had something to do with it. although I understand that the only thing it has to do with is helping the startup/compilation time, since cljs itself is already pre compiled

@tolitius: you’re mixing up understanding of how ClojureScript works with environment issues

inability to get the AOT artifact working with Lein is why I just use Maven directly now

your problems have nothing to do with macros and AOT - they are unrelated

@dnolen: thx, I could not find an explanation why would AOT matter, env makes sense. @mfikes: didn't mean to derail the documentation improvements, we can get back to that

@tolitius: eventually I need to write something actionable about the issue so it can be resolved in Lein or cljsbuild, but I’m too busy with other things.

@dnolen: that'd be great. until then, it gives me a good reason to try boot, and just mvn

For now, I think I’ll revise the page to use the term stage. More semantically on target than scope.

Writeup on my experiences making improvements to ClojureScript's HashMap implementation http://bendyworks.com/leveling-clojures-hash-maps/

@spinningtopsofdoom: cool stuff!

Thanks hopefully this not only leads to perf improvements but wider use of Immutable HashMaps

At least for me the new implementation made coding / debugging a HAMT a lot easier.

If you put the lean-map-0.3.0.jar on your classpath, it is not clear to me how to load code out of the main subdirectory within the JAR. (I’m not an expert, so asking, is this possible?)

which of the older browsers (IE8,9, etc) does ClojureScript officially support?

is there a list of supported browsers somewhere?

@settinghead: Not a direct answer but: https://github.com/clojure/clojurescript/wiki/FAQ-%28for-JavaScript-developers%29#does-clojurescript-work-in-old-browsers

ah, overlooked that one. thanks

that’s good to know.

@settinghead: I've written a production application in it that supports IE9, haven't heard any complaints

The reason I ask about lean-map-0.3.0.jar and the main subdirectory is that the code you want to load is in directories that look like main/cljs/lean_map/core.cljs instead of cljs/lean_map/core.cljs.

load-file partially works for this, but causes an issue of one ns internally requires another

@mfikes: I'm not an expert either, from looking at other repo's I thought this was the standard way to namespace things

@spinningtopsofdoom: Ahh cool. If other repo’s are doing it then there must be an answer

eg om for example

@spinningtopsofdoom: Om was one of the first I looked at. Its code is at the top level from what I can see.

(I’m doing jar tvf on the JAR down in ~/.m2. For Om, one file of interest is om/core.cljs.)

Normal use would lead to this:

$ lein run -m cljs.repl.node
ClojureScript Node.js REPL server listening on 55376
To quit, type: :cljs/quit
cljs.user=> (require 'cljs.lean-map.util)
clojure.lang.ExceptionInfo: No such namespace: cljs.lean-map.util, could not locate cljs/lean_map/util.cljs, cljs/lean_map/util.cljc, or Closure namespace "cljs.lean-map.util" {:tag :cljs/analysis-error}
	at clojure.core$ex_info.invoke(core.clj:4593)
	at cljs.analyzer$error.invoke(analyzer.cljc:568)
…

Hmmm I thought I had it setup correctly, I have to head out now could you file an issue explaining the problem?

@spinningtopsofdoom: Yep. Will do. By the way, things work perfectly in Planck if I crack the JAR apart and skip the main directory.

ooofff thanks for the detailed feedback!

Dirac now displays custom formatters inline in source code when debugging: https://dl.dropboxusercontent.com/u/559047/dirac-inline-custom-formatters.png https://github.com/binaryage/dirac

@mfikes: Found the bug I didn't have a source-paths set up on project.clj. I cut a new release version 0.3.1` with the fix. It worked on my machine 😥.

@spinningtopsofdoom: Yep. Works for me too.

Great let me know of any issues that come up and improvements that could be made.

@jaen: when I wrote the second edition of the series I added this note at the chapter on domina:

@jaen: Domina was one of the first DOM library written in CLJS and it has not been updated to follow the evolution of CLJS compiler. If you use the canonical domina release (i.e., [domina "1.0.3"]), during the compilation you'll get a warning about the fact that it uses a single segment namespace. Even if those warnings do not affect the behavior of the lib in the contest of this tutorial, I really hate warnings. So I prepared a non canonical domina release which fixes those warnings. That said, even if I would never suggest to use domina in a new CLJS project, this tutorial could be still useful to understand the way CLJS works.

I guess it makes sense to use it with such disclaimer, I suppose.