Fork me on GitHub
#clojurescript
<
2016-02-10
>
richiardiandrea00:02:31

what do you guys use for serving files in dev (without figwheel) ? I am trying to find an alternative to lein-simpleton

darwin00:02:31

from command-line I usually fire python -m SimpleHTTPServer simple_smile

richiardiandrea00:02:50

@darwin oh thanks! I found a bug in lein-simpleton and proposed a PR but no answer in long time..

richiardiandrea00:02:23

but it's Fogus so I cannot say anything, cause he taught me Clojure through The Joy of Clojure 😄

darwin00:02:51

@richiardiandrea: if you really need some server in clojure, you could use ring and lein-ring

darwin00:02:09

also what I did in my previous projects was to setup nginx to serve some local folders

richiardiandrea00:02:30

thank again, yes ring will be straightforward! but an alias and lein-shell might do

darwin00:02:05

yep, it is not worth it to spin yet another JVM just for a simple static HTTP server

richiardiandrea00:02:06

@darwin the alias is comfy: "browser-repl" ^{:doc "Clean, build and launch the browser demo repl."} ["do" "clean" ["cljsbuild" "once" "browser-repl"] ["shell" "python" "-m" "SimpleHTTPServer"]]

richiardiandrea00:02:57

no actually I need to specify the folder too 😄

superstructor03:02:54

I need to emit a different module system to Google Closure from the ClojureScript compiler ala the :modules compiler option; i.e. splitting namespaces into seperate module files, but not in Closure format. The use case is that we have a JavaScript engine running inside mail servers which supports a Node.js/CommonJS-esque module system, and only loading certain modules at runtime has a massive impact on performance at large scales. Is there any work on supporting emitting other module systems ? Would it be feasible for me to modify the ClojureScript compiler myself ? If so any tips on where to start looking ?

josh.freckleton03:02:06

how can I define css like this in clojurescript?:

.row-eq-height {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display:         flex;
}
I've tried creating a style tag, and I get an error because it complains that I've already defined display, which I have... but how else can I do this?

meow04:02:10

@superstructor: You could also ask on #C07UQ678E since this is a more advanced question.

meow04:02:06

@josh.freckleton: You could also ask on #C06DTLT5X

iwankaramazow09:02:12

Could someone confirm if figwheel supports the :module option in :compiler, i.e. in the context of code splitting?

rajeshponnala10:02:55

did any body used React Select in clojure script ?

thheller11:02:08

@superstructor: the :module compiler option are not about javascript modules. they solve different issues. the :modules option is only about splitting the final compiled output into multiple files, but that is AFTER the whole program was optimized.

thheller11:02:02

only loading certain modules at runtime is exactly what the whole program optimization is about

thheller11:02:19

but you need to feed the whole program into the compiler

thheller11:02:36

something node.js/commonjs isn't built for or particularly good at

thheller11:02:38

there are solutions if you only want a commonjs module so you can load it into your server

thheller11:02:33

so you can do var app = require('./my-cljs-thing')

dnolen14:02:58

@superstructor: such a change is out of scope for ClojureScript, we’re unlikely to ever support generating other JS module systems.

martinklepsch14:02:15

when incrementally compiling, what determines what files are compiled again? I have some projects where only the file I edited is recompiled but others where almost all files seem to be recompiled

martinklepsch14:02:22

Is that related to macro usage perhaps?

thheller14:02:23

@martinklepsch: don't know the exact semantics for cljs but :recompile-dependents defaults to true I believe, so whenever you edit a file all files that depend on it are recompiled as well.

thheller14:02:05

so if you have files that are used all over the place you'll see a lot of recompiles

martinklepsch14:02:57

@thheller: "all files that depend on it" as in the full tree or one level?

thheller14:02:42

not sure on that one ... in shadow-build it is one level

thheller14:02:56

but it is a different implementation so it might be full tree in cljs

martinklepsch14:02:41

I have a file that requires nothing but still some 30 files are recompiled

martinklepsch14:02:54

ignore that simple_smile of course it's about files that depend on the changed file

thheller14:02:19

exactly 😉

dnolen14:02:22

@martinklepsch: @thheller: at the moment it’s full tree

kauko17:02:51

Let's say I have a namespace foobar.colors where I define some basic colors I want to use. I can then refer to those colors by just using colors/red. Then I want to create a namespace for colors with an alpha channel, or maybe colors that look more "dirty" or "broken". I'd like to make sure that these two namespaces have the same names defined as the namespace with the basic colors. This way I can be sure that alphacolors/red always works, or I can even change which namespace I refer to as colors. Is there any sane way to make sure the namespaces stay in sync, or should I just hope that I'm disciplined enough?

val_waeselynck17:02:44

@kauko I think namespaces are some of the least programmable parts of Clojure(Script)

val_waeselynck17:02:28

so I would say no 😕

kauko18:02:17

Thank you for the link! It's a step in the right direction, but not quite

kauko18:02:52

Contrasting to the post you linked, what I'd like to do is force myself (or a team member) to define and overwrite vars defined in the "core"

kauko18:02:55

Not just import them

dnolen18:02:47

this is not what namespaces are for - and I can’t personally say anything good about the topics covered in that blogpost

dnolen18:02:19

as more time passes the more I believe the inability to do var and namespace hijinks in ClojureScript is actually a killer feature

bensu18:02:48

@kauko: what I would recommend is to take a more data oriented approach: put the legal color names in a set, define in foobar.colors values for them in a map, and then validate all the other namespaces with the same set

kauko18:02:42

@bensu Yeah, I was thinking something like that actually. But how would I do the validation?

kauko18:02:59

Unit tests? 😄

bensu18:02:31

where you define your map you check that the keys used are in your canonical set

bensu18:02:43

or use something like schema.

kauko18:02:03

Yeah, actually I think I now know how I'd do it. Thank you guys!

jaredly19:02:56

speaking of namespaces, I’ve thought it odd that namespaces are not values (whereas modules in python & javascript are values). I can’t pass a namespace as an argument to a function, and then inside of that function get a var from that namespace. In clojure I can do (find-var (symbol ns-name var-name)), but that feels super hacky, and in clojurescript I can’t do it at all. Has there been any discussion of this?

thheller19:02:48

@jaredly: the reason is quite simple ... :advanced optimisations

jaredly19:02:22

so implementation details dictate language design decisions?

dnolen19:02:33

@jaredly: it’s not an implementation detail

dnolen19:02:01

it’s like one of the very first things that Rich Hickey decided upon when creating ClojureScript

thheller19:02:03

to me it is the absolute killer feature of cljs

jaredly19:02:56

😄 ok, sorry for the snark. but I don’t think that what I propose is necessarily in opposition to advanced optomisations

thheller19:02:58

I cringe every time I look at a moderately large js lib

jaredly19:02:59

use of namespaces as first-class values could be statically analyzable

trptcolin19:02:04

@jaredly: it sounds like a protocol (instead of a namespace) is what you want. faster dispatch than find-var thing in clj too.

jaredly19:02:24

protocols don’t have all of the properties I’m looking for, but do allow some amount of dispatch

trptcolin19:02:29

[i've also wanted fancier namespaces at times, but we use the tools we have 😉 ]

dnolen19:02:50

@jaredly: theoretically possible - but it’s seems like a non-trivial amount of work - you would need to prove that the cost of such analysis and it’s affect on code size is worth it.

dnolen19:02:06

the current data points are of course against such work

dnolen19:02:27

bootstrapped cannot use advanced optimization so you get a 10X increase in code size

jaredly19:02:40

against such work b/c inertia? also — if we do the work for auto-js-externs, it seems this wouldn’t bee too far out of the way

dnolen19:02:56

such experiments would be interesting but first you need ClojureScript only analysis global passes

dnolen19:02:09

@jaredly: these things are not really the same category of problem at all

dnolen19:02:39

the auto-js-externs things needs local analysis only to work in the current proposal

dnolen19:02:57

wrt. CLJS tailored global passes higher priority in the queue than supporting something like what you suggesting would be early DCE

dnolen19:02:14

since that has a much more important real benefit for more users

dnolen19:02:18

faster advanced compilation

dnolen19:02:15

so lack of interest atm is more about missing pieces and higher priority things if we had the missing pieces

dnolen19:02:58

none of which to say if it was easy to implement such a thing today it shouldn’t be tried - but it’s not easy to do yet.

jaredly19:02:12

cool, thanks for the explanation!

iwankaramazow19:02:21

I've got a question regarding namespaces, i.e. defmethod & defmulti . Currently trying to follow https://rasterize.io/blog/cljs-dynamic-module-loading.html to incorporate code splitting. At some point in the blogpost the author writes: This is a win, because defmethods can appear in any file I don't fully understand this, can you write a defmulti in namespace a and without requiring namespace a, implementing a defmethod in namespace b?

dnolen19:02:26

but you can prevent every implementor from being loaded together

iwankaramazow19:02:18

Ok, thanks. I'll trail & error into a solution.

iwankaramazow20:02:44

Woohoo it works, farewell webpack, hello google closure modules 😄

anmonteiro21:02:32

I'm compiling my CLJS tests to run on node.js, but whenever I run them in node (`node target/test/test.js`) I'm getting cannot find module 'react'

anmonteiro21:02:53

I know this is not a very detailed description, but I'm not quite sure where to start looking

anmonteiro21:02:38

the react.inc.js file is there, everything seems fine

superstructor21:02:04

@thheller @dnolen thanks for your responses earlier re other JS module systems / :modules compiler option. Yes, at the moment I already do require(‘compiled-cljs-file.js’); which works fine. The issue for me is that once I want more than one CLJS thing (e.g. cljs-thing-A.js and cljs-thing-B.js) with the currently available compiler options I have two possibilities: (1) compile cljs-thing-A.js and cljs-thing-B.js into entirely seperate builds, which will duplicate all common code and libraries between the two; e.g. :cljs-base will be duplicated across both files. (2) compile both cljs-thing-A.js and cljs-thing-B.js into one monolithic file cljs-thing.js that is the entire software that must be loaded in its entirety. Neither of these options is very acceptable for mail servers handling hundreds of millions of messages with many JavaScript virtual machines in threads. Simply just the parse time and memory use with loading the code into the JavaScript engine is enough of a concern. Although inferior in every other way to ClojureScript, with vanilla JavaScript we currently have control over exactly which parts of the code are loaded into memory in a given JavaScript virtual machine instance. So I am trying to work out a way to move to ClojureScript without losing that control. Any suggestions ?

dnolen21:02:17

@superstructor: given your constraints ClojureScript may just not be a good fit for your problem

dnolen21:02:38

I don’t see how you can really get around having to load the large standard library

superstructor21:02:49

@dnolen: I’m happy to load the standard library once, but twice or ten times (depending on number of modules), is not ideal. Ultimately we plan to move this to an external JVM service running Clojure, but ClojureScript is a great bridge solution as it runs on the virtual machine that is already in production, and is inter-operable with the existing JavaScript implementation while we port it.

dnolen21:02:53

@superstructor: yes I understand why it might be desirable but it just isn’t possible and it’s not a priority

superstructor21:02:50

@dnolen: ok thanks, appreciate that. One last question, you don't think it is possible for me to modify the CLJS/closure compiler or compile with :modules then modify the compiled source or hack the closure module system to load the cljs-base (and other “modules” / files) via require() just for my own impl ?

dnolen21:02:21

@superstructor: so a couple of pointers

dnolen21:02:49

first under :none for Node.js we already use a modified shim provided by Google Closure so that goog.require invokes Node.js require

dnolen21:02:32

I don’t know enough about your problem (and I don’t have time at the moment to consider it further) but you may be able to work something out here if you just give up Google Closure passes altogether

superstructor21:02:19

so, by giving up Google Closure you mean not using the Google Closure stage of compilation ?

dnolen21:02:34

doing some with :modules may be possible but the feature was written almost entirely around the Web use case so I don’t know anything about it’s relevance for Node.js

dnolen21:02:31

@superstructor: yes Google Closure is only applied at :optimizations higher than :none

superstructor21:02:56

@dnolen: ok great, those are some really helpful pointers. Thanks so much 😄

dnolen21:02:14

in theory you could just supply your own loader thingy instead of relying on the machinery in goog.base

dnolen21:02:39

a lot of the REPLs (standard ones and Figwheel) demonstrate detailed hijacking of the code loading machinery

dnolen21:02:58

since they cannot use the standard mechanism (script tags added before document body close)

superstructor21:02:48

@dnolen: awesome, thanks. I’ll explore all those options and post my solution here / GitHub once I have one.

superstructor21:02:00

technically, in my case it is a bunch of SpiderMonkey engine threads running inside a C++ mail server, but I think if I come up with anything it will also be useful for Node.js use cases.

dnolen22:02:12

@superstructor: definitely deep end of the pool if you aren’t familiar with how the REPLs interact with JS environments, but you might be be able to glean something from these

anmonteiro22:02:23

I can run my CLJS tests in node.js if I npm install react but this seems unnecessary to me

superstructor22:02:38

@dnolen: thanks, deep end of the pool sounds like fun 😉

thheller22:02:17

@superstructor: I don't quite understand your use-case that would lead to loading the standard library twice?

thheller22:02:43

just do 3 different builds A, B, A+B?

superstructor22:02:18

@thheller: well, you currently have two possibilities - either compile your entire program into one file, or duplicate the standard library across N files ?

thheller22:02:23

:modules and node aren't great friends as soon as you use any optimization other than :none

thheller22:02:38

no I mean for your server problem

thheller22:02:58

as far as I understand it you either want to run it with A or B or both

thheller22:02:13

but in completely seperate VMs

thheller22:02:15

so lets say you have A.js, B.js and A-and-B.js

thheller22:02:54

instead of loading A.js and B.js you load the combined one

thheller22:02:02

which takes care of loading the stdlib twice

thheller22:02:42

or just run in :none which would be totally fine as well

superstructor22:02:20

@thheller: sorry I possibly explained that poorly by simplifying the example. We actually have something like 35 modules (so A, B, C, D, E…) implementing different parts, and some N number of modules get loaded depending on different things like the message, or the logic being applied to the message. The multiple VMs are just for parallelization of handling multiple messages through the mail server at the same time. So although your right, it wouldn’t be feasible to make combined builds for all the possibilities.

dnolen22:02:25

@anmonteiro: you might want to poke around at the Om Next Node.js testing scripts for ideas where you may be going wrong?

anmonteiro22:02:52

@dnolen: I have copied from there and it doesn't work

anmonteiro22:02:56

I can't find anything different

dnolen22:02:13

@anmonteiro: :target :nodejs?

anmonteiro22:02:15

i.e. I can run the Om tests, but not mine

thheller22:02:35

@superstructor: ah hmm ... :none might be for you then

anmonteiro22:02:39

also tried :optimizations :simple and still get the error

dnolen22:02:42

@anmonteiro: output structure matters too

anmonteiro22:02:56

my :main is not inside the out dir

thheller22:02:01

although honestly loading everything together but optimized will probably consume less memory than loading only parts on demand

thheller22:02:20

especially if the servers are running for a while they will eventually have loaded everything anyways?

dnolen22:02:31

@anmonteiro: and you see all the expected React stuff in the output dir?

superstructor22:02:42

@thheller: hmm maybe your right, I should just try loading everything and see if that is feasible. A monolithic file would be the most simple option.

anmonteiro22:02:47

there's react.dom.inc.js and react.inc.js...

anmonteiro22:02:52

I suppose that's all

anmonteiro22:02:13

this is a project which requires Om

anmonteiro22:02:39

and I think that React in this project is just used by Om

anmonteiro22:02:44

I don't have it anywhere else

dnolen22:02:09

@anmonteiro: and out/cljs_deps.js shows a goog.addDependency(…) entry for the React stuff?

superstructor22:02:18

@thheller: loading our entire ClojureScript codebase into SpiderMonkey takes about 700ms, caching reduces that to about 100ms, maybe I can look into getting that number small enough so its not a problem.

thheller22:02:37

why is load time to important?

thheller22:02:44

if the server runs for 24h a day

thheller22:02:50

700ms should not matter?

anmonteiro22:02:57

goog.addDependency("../react.inc.js", ['cljsjs.react'], []);
goog.addDependency("../react-dom.inc.js", ['cljsjs.react.dom'], ['cljsjs.react']);
@dnolen: ^^

dnolen22:02:22

@anmonteiro: ok that’s the problem

dnolen22:02:33

loading React DOM will blow up in Node.js

dnolen22:02:43

and lead to your cryptic error

anmonteiro22:02:02

it shows up in Om's cljs_deps.js too..

dnolen22:02:16

@anmonteiro: I’m looking at it right now it doesn't

dnolen22:02:46

I ran into this bug and made sure to drop any dom nses in my test ns requires

anmonteiro22:02:14

cleaning and compiling again

superstructor22:02:51

@thheller: maybe your right I could be taking the wrong approach, loading everything at once and caching might be OK. I’ll look into this as well. Thanks.

thheller22:02:21

@superstructor: while not via a npm module, the process described here would work just as well for cljs

anmonteiro22:02:27

@dnolen: OK that was it, thanks! What I was saying was that I see what I've pasted above in the Om's deps.cljs, but none of the other dependencies use it. In my case these were getting used in other dependencies which created the problem

anmonteiro22:02:29

thanks once again

dnolen22:02:37

@anmonteiro: glad to hear it's fixed, when Node.js requires go wrong it can be a real head scratcher

dnolen22:02:03

at some point I looked at how to detect stuff like this - but I didn’t get very far

anmonteiro22:02:26

@dnolen: the strangest thing was that npm install react solved the problem

anmonteiro22:02:36

even when React.DOM was required

dnolen22:02:23

hrm … yeah dunno

dnolen22:02:03

maybe something to do with the npm React being more up-to-date or different somehow?

anmonteiro22:02:14

hrm let me check the version

anmonteiro22:02:33

it is indeed 0.14.7, not sure if it matters

anmonteiro22:02:52

higher than 0.14.3 that Om is requiring