Fork me on GitHub
#hoplon
<
2016-01-13
>
micha16:01:40

@actsasgeek: you need to use the library in your program

actsasgeek16:01:11

ah, like a regular :require in the (page) at the top?

alandipert16:01:22

@actsasgeek: right - when i did the dashboard, cljsjs wasn't a think and i added the bootstrap css manually

actsasgeek16:01:35

ok and if you do need to add stuff manually, say a 3rd party JS library, I’m a bit confused as to what is required and what worked and what has changed.

actsasgeek16:01:57

if I have a file foo.js, how do I use it with Hoplon?

actsasgeek16:01:49

I’ve seen things about adding foo.inc.js to src/<whatever>/foo.inc.js but then also assets/js/foo.js or not also? I guess the question is…how would you add JustGage today?

alandipert16:01:49

yeah back when i wrote that article, we had a system for automatically including JS - super easy

alandipert16:01:46

today i would add (script ...) tags to the hoplon markup and not do advanced compile

actsasgeek16:01:02

ah, okay. Interesting.

alandipert16:01:57

micha has had some ideas about how we can be as easy as old hoplon while still leveraging cljsjs

alandipert16:01:09

the main outstanding problem is the treatment of css which accompanies many libs like bootstrap

actsasgeek16:01:43

I haven’t been doing much on the front end in a while (always fun to get back in the game) what is cljsjs?

alandipert16:01:45

micha has proposed making cljs wrappers for css files, so that they can be included the way js/cljs files are

alandipert16:01:22

it's an initiative to package many js libs for cljs consumption based on some conventions, https://github.com/cljsjs/packages

micha16:01:17

making cljs wrappers means that css is automatically subject to dead code elimination

micha16:01:21

which is nice

micha16:01:37

and kind of important when css is being pulled in via transitive dependencies

micha16:01:45

you could end up with a lot of css you don't need otherwise

alandipert16:01:17

wouldn't the granularity be dead namespace though? like the css load would be a top level expression, so the only way it wouldn't happen is if that entire ns is elided

alandipert16:01:38

or maybe would it never be elided? since it' sa top level form for side effects

micha16:01:39

transitive dependencies

micha16:01:07

well the css import would be dead code then

micha16:01:14

which could be eliminated

micha16:01:47

if you never call the function that installs the css

micha16:01:56

like if that call is in a dead code block

laforge4918:01:59

I keep getting compiler errors in notify when I restart the castra-notify-chat server and still have a client running. Here's the compiler error: Caused by: clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: priority-map-keyfn in this context, compiling:(notify/notification_api.clj:15:26) at clojure.lang.Compiler.analyze (Compiler.java:6543) clojure.lang.Compiler.analyze (Compiler.java:6485) @micha?

laforge4918:01:34

rebuilding notify does the trick.

laforge4918:01:18

I'm wondering if I need to include priority-map as a dependency of chat too.

micha18:01:29

are you using it anywhere?

laforge4918:01:40

but it keeps disapearing

laforge4918:01:51

--when I rebuild chat

micha18:01:21

how are you doing the rebuilding?

laforge4918:01:55

^C followed by a boot dev in the chat directory

laforge4918:01:56

rebuilding notify to fix this is very wrong, especially as I am not modifying notify. 😞

micha18:01:25

yeah something is not right there

micha18:01:39

notify is a jar file, yes?

micha18:01:14

i mean in the chat application

micha18:01:27

it's using notify via notify.jar in local maven?

laforge4918:01:21

I thought perhaps the problem was a defonce on the atom holding the prioity-map, so I had removed that.

laforge4918:01:35

worked for a while and then hit me again.

laforge4918:01:46

--love intermittent stuff!

laforge4918:01:50

anyway, I do not expect any answers. I'll keep at this. maybe I will observe something else.

laforge4918:01:06

--at least I have a workaround for now.

micha18:01:49

is priority-map a dependency of notify?

laforge4918:01:54

And it feels very much like somehow I am modifying notify. Though I am pretty sure I am not. But I'll take further precautions. 😞

laforge4918:01:21

one of puzzler's projects

laforge4918:01:51

[org.clojure/data.priority-map "0.0.7"]

micha18:01:13

perhaps try boot show -p

micha18:01:20

and look for a conflict with priority-map

micha18:01:44

not sure how that would make an intermittent problem

micha18:01:49

but could be related

laforge4918:01:44

two versions are showing.

laforge4918:01:39

@micha this is wierdness. Every time I run boot dev it downloads the wrong version of priority-map.

meow18:01:59

@laforge49: so, you're working on a chat app?

laforge4918:01:13

my build boot and project.clj both reference 0.0.7 only

laforge4918:01:03

priority-map 0.0.2 is the oldest version and that is what keeps getting downloaded.

meow18:01:38

I have your aatrees on my todo list to take a look at

laforge4918:01:53

Earlier I had forgotten to add priority-map to build.boot and it was pulling down this old version. but now I am specifying it.

laforge4918:01:06

How can I tell if something else is pulling this?

meow18:01:36

I see, castra-chat, hrm

laforge4918:01:58

yeah, there is no index to the castra projects. look in the demo directory

laforge4918:01:36

@micha I found it. The problem is clojure is using an old version.

laforge4918:01:52

[?] org.clojure/clojure ? 1.7.0 org.clojure/clojure org.clojure/clojurescript ? 1.5.1 compojure ring hoplon/castra ? 1.4.0 org.clojure/data.priority-map ? 1.3.0 hoplon/hoplon ring/ring-defaults

laforge4918:01:30

But I do not understand the above.

laforge4918:01:10

Or is it saying that priority map is using clojure 1.4.0? Hmm

laforge4918:01:50

hoplon is the guilty party!

laforge4919:01:11

[?] org.clojure/data.priority-map ? 0.0.7 org.clojure/data.priority-map ? 0.0.2 hoplon/hoplon

laforge4919:01:41

0.0.2 is VERY OLD

laforge4919:01:25

Interesting. on github, hoplon is using the right version.

laforge4919:01:17

sorry, was looking in the wrong place.

micha19:01:22

you can use :exclusions in your dependencies

laforge4919:01:35

I can exclude a version?

laforge4919:01:55

priority-map-keyfn does not exist in 0.0.2

laforge4919:01:05

also, I do not see priority-map listed in hoplon's dependencies. 😞

alandipert19:01:11

javelin depends on it

meow19:01:54

would love to see a hoplon chat app for #C0CB40N8K to avoid #C0J5T38VB

meow19:01:34

@alandipert: how have you been, my friend?

laforge4919:01:34

the chat I'm working on is strictly a demo. There is no database.

meow19:01:01

@laforge49: does it have a compelling underlying concept

meow19:01:18

fair enough

laforge4919:01:05

I'm just exercising the notify project which is intended to overcome a weakness of castra

laforge4919:01:09

@alandipert Any reason for not updating javelin?

alandipert19:01:44

just haven't tested with it

alandipert19:01:01

it's in there to support the experimental clojure version of javelin, which i never use

laforge4919:01:42

I am close to a release. I can upgrade javelin on my own system as a snapshot for now. Then we can figure if it would be OK to push it as a snapshot when I do my release.

laforge4919:01:34

Of course it cascades. I'd then need to update hoplon too.

laforge4920:01:16

@micha Hmm. If I refer only to profile-map-keyfn in 0.0.7, which does not exist in 0.0.2, do you think that would work? Testing now.

laforge4920:01:04

Seems to work.

laforge4920:01:54

OK @alandipert it looks like I am fine to release without changing javelin. Changing my require seems to do the trick: (ns notify.notification-api (:require [castra.core :refer [defrpc session]] [clojure.data.priority-map :refer [priority-map-keyfn]]) (:import [java.util UUID Comparator]))

laforge4920:01:29

Interesting how boot can handle multiple versions this way.

alandipert20:01:46

@laforge49: great! yeah. it might be a good idea to graduate javelin-clj to be a separate library

laforge4920:01:23

It always seems to be the unused code that causes the most problems. simple_smile

nonrecursive22:01:37

hey yall, has anyone tried parallel builds with boot-cljs? I have this in my build.boot:

(cljs :compiler-options {:output-to "main.js"
                            :parallel-build true}
         :source-map true)

nonrecursive22:01:52

not sure if I did that wrong but there doesn’t seem to be any speedup

nonrecursive22:01:27

i haven’t looked into it too deeply - I’m just wondering if anyone’s experienced something similar

nonrecursive22:01:28

oh god I didn’t update the org.clojure/clojurescript version

micha22:01:00

does it doit faster?

nonrecursive23:01:25

yeah, about twice as fast 😄

micha23:01:21

righteous