Fork me on GitHub
#clojurescript
<
2016-01-02
>
orther03:01:27

Anyone else getting no packages listed when they visit http://cljsjs.github.io/ ?

nullptr03:01:52

orther: it’s empty for me as well, <ul></ul>

nullptr03:01:06

probably a generation script got borked

mfikes03:01:22

Perhaps related to the Atlanta Linode DC / http://clojars.org outage?

orther03:01:35

Ahh I totally forgot that http://clojars.org was down for me earlier too

orther03:01:40

yeah that makes sense

orther03:01:18

Anyone here familiar with boot-cljs-test and know how I can get it to exclude specific files OR namespaces? I am wrapping up my pull request to add Electron support to lein-doo and the final thing to get working are the boot builds/tests (that are part of the circle-ci build).

orther03:01:03

Hrmm now that I typed it out, it hits me that I may be able to get boot-test-cljs to run the tests in Electron. Either way, I've never really used boot before this so if anyone is experienced with boot-cljs-test and can help, let me know.

crocket04:01:16

Is ES6 amenable to google closure's :advanced optimization?

leolaporte04:01:37

@raymcdermott: no it’s “me”- I’ve been reading Clojure for the Brave and True and thought I should join this list.

crisptrutski08:01:44

@orther: help is on the way simple_smile

orther08:01:42

@crisptrutski: thanks simple_smile I took a little time earlier to actually look at boot-cljs-test and what it does. Read a few issue threads too. It seemed to me I should be able to get it working.

orther08:01:15

Just haven't started my attempt yet

crisptrutski08:01:43

there’s a subtle issue with the fileset paths vs project paths for using karma, boot-cljs-test doesn’t actually support that yet

crisptrutski08:01:03

not sure whether to solve that via changes to the boot test (latest boot can sync the target directory mid pipeline easily) or with doo changes (remove hardcoding of (System/getProperty "user.dir”))

crisptrutski08:01:37

will experiment with both and submit PRs later this weekend simple_smile

orther08:01:40

K gonna read those to get a better understanding of what is going on

orther08:01:46

btw I think clojars is back up

orther08:01:23

and http://cljsjs.github.io/ is listing packages again

crisptrutski08:01:50

not going to be around much today, but recommend #C053K90BR for getting any help

orther08:01:01

thanks @crisptrutski I really appreciate it

crisptrutski08:01:22

J’étais heureux de le faire 🙃

magomimmo08:01:06

@orther: clojars is up and down, up and down...

orther08:01:04

I should probably donate to clojars

orther08:01:29

money fixes everything

magomimmo08:01:50

@orther: yes we should donate, but at the same time this is a problem of a DoS attack in atlanta

crocket08:01:03

Can we fix DoS vulnerability for good?

solicode08:01:33

Never 100%, no. Having mirrors could be helpful though.

orther08:01:49

linode should just signup for cloudflare

orther08:01:46

on a serious note, that sounds like a nightmare working at linode right now

crocket08:01:27

Why is clojars attacked?

orther08:01:32

was just reading their status page

orther08:01:42

it's linode that's being attacked

orther08:01:53

clojars is run on linode

crocket08:01:02

Why is linode attacked?

solicode08:01:26

I don’t think they’ve said why yet.

solicode08:01:45

Could be extortion. Who knows at this point though.

crocket09:01:05

It could be cloudfare that pays for DoS attacks against linode.

orther09:01:07

Yeah in one of Linode's updates, "It has become evident in the past two days that a bad actor is purchasing large amounts of botnet capacity in an attempt to significantly damage Linode’s business."

crocket09:01:40

Hacked windows botnets? Or, dedicated private botnets? I guess AWS can be used as a botnet!!

crocket09:01:54

Is it possible to prevent individual functions and npm modules from being smashed by advanced optimization programmatically? Purescript imports each javascript function with FFI. I think this approach might be better than using :externs.

crocket09:01:42

Something like (def fs (dont-rename (nodejs/require "fs"))) could be convenient.

crocket09:01:27

(def fs (dont-rename (nodejs/require "fs")))
(fs.readFileSync "1.txt")

thheller09:01:22

@crocket :advanced for node is probably not worth the effort, :simple should be sufficient

thheller09:01:50

and no there is no simple way around externs

thheller09:01:59

except :simple 😉

crocket09:01:12

dont-rename is simple to use.

thheller09:01:27

but technically not possible 😉

thheller09:01:45

well maybe but not without hacking on the closure compiler

crocket09:01:05

It is for closure compiler.

thheller09:01:29

just use :simple with :static-fns and :optimize-constants

crocket09:01:44

What are static-fns and optimize-constants?

thheller09:01:44

that is pretty close to :advanced and should be comparable performance-wise

thheller09:01:49

compiler options

thheller09:01:02

code-size isn't relevant

crocket09:01:02

Can you give me links to the references?

cjmurphy10:01:50

Does anyone know of an example project I can look at that uses 'garden stylesheets'? All the examples I've seen are of in-line code. But I would like to see file/s that are stylesheet only, kind of like a .less file I imagine, but in hiccup, because that's how garden css looks...

crocket10:01:59

lein clean can't be executed when clojars is down. This is too bad.

crocket10:01:33

lein should be able to operate offline.

thheller10:01:23

it operates offline last time I checked

thheller10:01:31

that is when all dependencies are available

thheller10:01:39

if you have snapshot dependencies it might not be

solicode10:01:11

There is also the lein -o option for offline mode, but it doesn’t seem to be 100% all the time

crocket11:01:20

lein -o still requires connection to clojars.

crocket11:01:46

So, DoS attackers can neutralize leiningen users.

darwin11:01:33

@cjmurphy: I was using garden in one of my projects last year, not sure if this is a representative example, but I was pretty happy with it, you get full power of clojure when writing css, I for example implemented a few macro helpers on top of garden: https://github.com/darwin/faceboard/tree/master/frontend/styles/faceboard

crocket11:01:30

@thheller: :static-fns and :optimize-constants do not shave startup time noticeably.

glenjamin11:01:08

crocket: you can use goog.object.get to avoid being clobbered by advanced

crocket11:01:23

What is that?

glenjamin11:01:46

(goog.object.get obj ‘key)

glenjamin11:01:53

instead of obj.key

crocket11:01:43

What is assigned to this?

jaen11:01:17

It's basically equivalent to obj[key] and GClosure optimises only property access.

cjmurphy11:01:56

Thanks @darwin. Well organised css with that >> macro and all. I was beginning to think hiccup was only ever used inline.

crocket11:01:47

Does GClosure smash fs.readFileSync or (.readFileSync fs)?

crocket11:01:37

Is it object/get or object.get?

jaen11:01:27

(.readFileSync fs) is fs.readFileSync.

jaen11:01:34

So yeah, this will get renamed without externs.

crocket11:01:34

How do I import goog.object on REPL? Do I have to call ns?

jaen11:01:42

Well, you can use import as a function or as the option to ns. Both are valid.

jaen11:01:55

(import 'goog.object) should work.

jaen11:01:16

Though, hm.

glenjamin11:01:25

oh right, it’s goog.object/get

jaen11:01:52

I think the usual advice is to require GClosure namespaces and import only types (so things like constructors or enums).

jaen11:01:12

@glenjamin: the funny thing is both will work.

crocket11:01:14

clojurescript REPL doesn't have import.

jaen11:01:16

(require 'goog.object)
=> nil
(goog.object.get #js {"a" 1} "a")
=> 1
(goog.object/get #js {"a" 1} "a")
=> 1

jaen11:01:53

It doesn't?

jaen11:01:13

It works in the browser REPL at least:

(import 'goog.events.EventType)
=> nil
goog.events.EventType.BLUR
=> "blur"

jaen11:01:22

Maybe it's something specific to node then?

crocket11:01:31

If fs.writeFileSync requires fs to be bound to this, ((goog.object/get fs "writeFileSync) arguments...) will lead to an error.

jaen12:01:39

But ((goog.object/get fs "writeFileSync) fs arguments...) shouldn't

jaen12:01:23

Though let me check

crocket12:01:03

(require '[goog.string :as gstr])
(gstr/format "ok")
TypeError: goog.string.format is not a function
    at repl:1:39
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:54:17)
    at Domain.<anonymous> ([stdin]:41:34)
    at Domain.run (domain.js:228:14)
    at Socket.<anonymous> ([stdin]:40:25)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)

jaen12:01:46

@crocket this was already discussed before, with you even I think - format for some reason is in it's own namespace, not in goog.string.

jaen12:01:33

Probably Google docs misleading you

jaen12:01:35

Look at the source

jaen12:01:45

It is in it's own namespace for some reason.

crocket12:01:14

@jaen You need to call Function.prototype.apply to bind this.

crocket12:01:48

I'm not sure on how to call Function.prototype.apply in clojurescript.

crocket12:01:06

.apply or .call

jaen12:01:32

Yeah, remembering that is what prompted "let me check".

jaen12:01:43

readFileSync doesn't require bound this though:

cljs.user=> (require '[cljs.nodejs :as node])
nil
cljs.user=> (def fs (node/require "fs"))
#'cljs.user/fs
cljs.user=> (require '[goog.object :as go])
nil
cljs.user=> (def read-file-sync (go/get fs "readFileSync"))
#'cljs.user/read-file-sync
cljs.user=> (read-file-sync "project.clj")
#object[Buffer project.clj content here]

jaen12:01:13

But in general you should be able to do (.call read-file-sync nil "project.clj")

jaen12:01:25

(where nil is of course this value)

jaen12:01:56

(same for apply and bind)

crocket12:01:57

(.call fs.writeFileSync fs "/path/to/text.txt" "ok2") would be smashed by advanced optimization. I'm trying to use advanced optimization without :externs.

crocket12:01:39

Usually, this is not required, though.

jaen12:01:02

fs.writeFileSync would be, but then you can do what I did, use goog.object.get. I don't think .call would be smashed, though would have to actually check.

crocket12:01:51

Ok, it seems npm modules do not use this.

crocket12:01:42

Using (object/get fs "writeFileSync") instead of fs.writeFileSync or (.writeFileSync fs ...) is an acceptable tradeoff for shaving off startup time.

jaen12:01:56

Out of curiosity - what's the reason you do not want to write externs? Just because it's annoying to or other reasons?

crocket12:01:10

At a glance, it feels that writing externs is a lot of work if all I want to do is use fs.writeFileSync or the like once.

crocket12:01:35

If I'm going to use a function or two from various npm modules, writing externs can involve a lot more work than just using object/get.

jaen12:01:40

But you only need to write the externs for what you use.

jaen12:01:57

You don't need to write externs for everything the library you use has.

jaen12:01:34

The thing is GClosure when optimising doesn't touch your :foreign-libs (or things node will provide for you when you require)

jaen12:01:44

It only renames references in your code

jaen12:01:12

And externs are the way to let GCLosure know that you don't want certain things renamed to refer to the external objects.

jaen12:01:22

If you only use writeFileSync you only need to write extern for it

crocket12:01:23

object/get is another way.

jaen12:01:24

And nothing else.

jaen12:01:54

Of course, but you pay the cost in verbosity and each time you need to refer to something.

jaen12:01:03

With externs you only need to let compiler know once.

crocket12:01:17

As I said, if I just wanted to use module.function only once, object/get is faster. It is ok for small npm modules where references are made only once or twice at most.

crocket12:01:59

Purescript imports javascript functions individually via FFI. I wanted to do something like that in clojurescript for one-off references.

crocket12:01:43

For larger modules or large programs, externs make sense. But, since there are just too many npm modules out there, I don't want to maintain externs for those modules on cljsjs.

jaen12:01:32

Sure; just wanted to underline that writing externs for one or two functions isn't as much work as you think it is. But I can understand not wanting to do that if you feel just def ing things you need is enough.

jaen12:01:01

Well, you don't have to put externs in cljsjs if you don't want. It's not a requirement to use them - you can just keep them in a folder in your project.

glenjamin12:01:28

there’s a project which has all the nodejs externs anyway

crocket12:01:46

I know. fs.writeFileSync was just an example. I use various npm modules.

crocket12:01:40

I prefer to see FFI in clojurescript rather than in javascript.

thheller12:01:59

@crocket what do you mean by startup time? :advanced should not be very different from :simple in that regard

crocket12:01:23

@thheller: For a very simple program, a javascript file compiled on :simple optimization starts up in 0.2 second, and a js file compiled on :advanced optimization starts up in 0.1 second.

jaen12:01:35

I guess it's parsing and whatnot

crocket12:01:39

I think the gap is going to widen in bigger programs.

jaen12:01:42

With less code it takes less.

thheller12:01:14

so are we talking 148ms vs 201ms?

thheller12:01:23

0.1 vs 0.2 doesn't seem all that accurate

crocket12:01:28

100ms vs 200ms

dnolen12:01:29

@crocket without rigorous measuring - making assumptions about timing makes little sense

thheller12:01:54

given that the whole javascript world basically only does :simple

dnolen12:01:58

as to the gap widening in bigger programs - even bootstrapped ClojureScript loads in under half a second

dnolen12:01:11

bootstrapped ClojureScript is like 7-8mbs of JavaScript

thheller12:01:55

even :none loads pretty fast

crocket12:01:07

:none loads in 0.4s on my machine.

dnolen12:01:09

@crocket: in anycase, this isn’t something we care about and we’re not going to spend anytime on it simple_smile the advice I’ve given about this holds - just use :none

crocket12:01:45

On nodejs land, :none causes tooling issues even if you don't care about loading time.

crocket12:01:02

:simple provides the most hassle-free tooling experience for production build.

dnolen12:01:52

what tooling issues? I only use :none with Node.js

crocket12:01:10

I know that it is my issue, and I don't expect anyone else to take care of my issues unless I'm paying.

crocket12:01:11

Probably, it was an issue with :main.

crocket12:01:46

I'm probably not going to become a clojurescript pioneer on nodejs, so I may wait for months or years.

dnolen12:01:29

yep - deeper support for Node.js is just not a very high priority.

crocket13:01:07

My crude calculation is that if a nodejs program requires 10 simple cljs npm modules, each of which consumes about 700kb-1mb on HDD, the loading time could go beyond a second on older machines. A second of loading time could make a difference on sysadmin's patience. Time could solve this problem by increasing SSD and CPU speed, though.

thheller13:01:32

@crocket cljs as npm modules is problematic since each basically will ship their own version of cljs

thheller13:01:16

that is not an ideal situation but also nothing we can address really

thheller13:01:49

since closure assumes to optimize the whole program

crocket13:01:13

What do you mean? cljs npm modules will be safe to be used by javascript programs.

thheller13:01:38

yes they are safe to use

jaen13:01:44

@thheller: it optimises only provided sources - node modules wouldn't be those.

thheller13:01:47

but as you say .. they are basically huge

thheller13:01:08

@jaen I mean the FINAL output

thheller13:01:18

closure assumes to optimize the whole program, not a part of it

jaen13:01:20

Ah, I think I understand what I missed - you were talking about node modules written in CLJS and that there's no way to optimise out CLJS runtime between those, yes?

thheller13:01:37

they cannot share the cljs runtime

crocket13:01:27

Meanwhile, I have object/get and :externs for cutting off dead code. object/get for when it involves more work to define :externs.

crocket13:01:04

@dnolen : What do you mean by we? Cognitect?

dnolen13:01:50

myself and anyone else actively submitting patches to ClojureScript

crocket13:01:15

Sorry for sounding like a nagging baby, here. I understand that open source economy is run by the motto, Contribute, pay, or wait.

dnolen13:01:23

so Node.js support could appear if someone in the community has a plan and the time to execute said plan

dnolen13:01:06

the problem however is that Node.js and NPM works in a way that’s somewhat at odds with Closure

dnolen13:01:26

dependencies can appear multiple times - non-standard CommonJS interpretation

dnolen13:01:29

all these things make a sensible plan more sophisticated than what we already provide less interesting to pursue

crocket13:01:32

It seems google closure needs to support node.js better.

dnolen13:01:04

it’s pretty clear Google does not care nor do should they given their use of JavaScript. That said what Node.js support we have comes from the small tweaks that Nick Santos (ex- Google) made.

dnolen13:01:21

so far we’ve made few changes at all for Node.js - we treat it like pretty much any other JS environment - Rhino, Nashorn etc.

dnolen13:01:53

IMO this has worked pretty well - lack of Node.js concessions, tweaks means ClojureScript is more portable.

crocket13:01:34

Summary : On web browsers, and as npm executables, clojurescript is ok. As npm libraries, clojurescript would lead to loading cljs runtime several times. Splitting cljs runtime requires support from google closure, so clojurescript devs are not touching it.

cjmurphy13:01:24

Is there such a thing as a hiccup (or garden) reader, that could be used for example to extract style information?

dnolen13:01:13

@crocket: not a bad summary. there is a bootstrapped ClojureScript NPM module now which may be better suited for what you want to do - but it will probably be a non-trivial amount of work to make it useable for actual projects.

dnolen13:01:26

@cjmurphy: like extracting style information from the hiccup syntax?

cjmurphy13:01:27

@dnolen exactly that use case.

dnolen13:01:54

@cjmurphy: hrm not aware of anything but given the simplicity of hiccup it might be pretty easy to write a simple recursive function that does what you want

cjmurphy13:01:12

Okay thanks, yes will do.

krchia16:01:52

does om/update! not apply the change to app-state?

krchia16:01:12

it seems to reset back to the default value without refreshing the webpage

akiva16:01:26

@krchia, there’s an #C06DT2YSY channel.

krchia16:01:11

thanks. i’ll ask there

grav20:01:11

Hi! I’m trying to solve the halting problem.

grav20:01:53

When working with infinite lazy sequences, can I somehow avoid infinite loops when I accidentally realize them?

grav20:01:19

Eg. by getting an exception after realizing 10000 items?

grav20:01:50

I’d like to avoid having to add take 10000 in my code

grav20:01:38

So there’s no way to do an implicit take?

dnolen20:01:35

it seems about as useful as for loops with magic termination conditions simple_smile

grav20:01:28

well I’m probably attacking this the wrong way, but when developing cljs, I often crash the tab, because I think I’m only realizing a finite sequence.

grav20:01:06

I guess I should not use the browser as a repl, but just do it directly in the figwheel repl with an added take

darwin20:01:46

@grav: so your problem is when debug-printing infinite sequences in repl? there should be some option to limit that

grav20:01:44

@darwin: yes, it’s a kind of debug printing, but in this case it’s the iterative process that figwheel allows for, so the side effects are rendered in the browser instead of the repl.

darwin20:01:19

then it is fault of the iterative code which consumes that (potentially) infinite data, you should yield back to main event loop once in a while to allow for browser responsiveness (for page refresh)

grav20:01:27

The iterative development process was what I meant. I’m changing code and watching the browser, and if I accidentally introduce an infinite loop, the browser tab will freeze. If I could introduce an exception that would just kill the stack frame, it would allow me to continue

gdulus22:01:09

hey. beginner question. due the down time of clojars i can't run my project anymore. i added some mirrors and seems that it has helped with lein clean but I can't start my re-frame project (lein figwheel dev). any idea how to fix it

akiva22:01:43

@gdulus, there’s a discussion on this very issue going on in #C0H28NMAS right now. Head over and dive in.

akiva22:01:51

#C03S1KBA2

gdulus22:01:27

@akiva: thx. digging into

gdulus22:01:02

i have random compilation issues. after lein clean file change but error always look the same: `{:file #object[java.net.URL 0x65ad7f3f "file:/home/gdulus/Workspace/projects/vanity-portal/vanity-portal/social/src/cljs/social/i18n.cljs"], :line 1, :column 1, :tag :cljs/analysis-error} ANALYSIS ERROR: at line 1 file:/home/gdulus/Workspace/projects/vanity-portal/vanity-portal/social/src/cljs/social/i18n.cljs on file file:/home/gdulus/Workspace/projects/vanity-portal/vanity-portal/social/src/cljs/social/i18n.cljs, line 1, column 1 `

gdulus22:01:19

i thought its somehow related to clojars problem, but repo is back and this issue still hits me

gdulus22:01:31

i checked all source files and no i can't find any obvious issue

gdulus23:01:17

seems that for some reason i have StackOverflowError during the compilation. any hint why it can happen?

christopherbui23:01:51

What's the thing to use for a Cljs Browser repl today?

jaen23:01:18

Boot-cljs-repl if you're using boot, figwheel if you're using lein.

christopherbui23:01:55

Can I turn off the auto reloading stuff

christopherbui23:01:22

That was why I was wondering if there was something smaller

jaen23:01:45

For figwheel - I dunno. Boot-cljs-repl is just the REPL part though.

jaen23:01:15

I suppose you can use weasel/piggyback/austin on your own without figwheel, but that it's probably less easier to set up.

christopherbui23:01:43

It turns out figwheel does let you disable auto reloading, great, thanks

jaen23:01:27

Oh, that's nice.