Fork me on GitHub
#boot
<
2015-11-21
>
sekao02:11:04

updating boot fixed the error 😃 i was on 2.2.0 via homebrew. didn’t realize it was outdated.

onetom07:11:23

any opinion, experience?

onetom14:11:28

@sekao: though im still a subime user at the moment, i like your vision with nightcode! my colleagues enjoyed your narration of Quest Quest too 😉 https://youtu.be/0GzzFeS5cMc?t=2083

onetom14:11:43

on that note, as a continuation of my parinfer quest, i've just realized that Visual Studio Code has just been open sourced aaand got an official plugin system too https://code.visualstudio.com/updates that makes it a serious alternative to sublime actually... despite being a full blown ide, it's quite frugal still. might be a light weight alternative to cursive...

sekao15:11:18

@onetom thanks very much! And yeah I've seen parinfer, it looks great. I made something kinda similar in pure clojurescript here: https://github.com/oakes/paren-soup

donmullen20:11:51

@onetom: Looks like there is a parinfer for atom : https://github.com/oakmac/atom-parinfer

micha20:11:22

parinfer looks cool, basically haml with parens added automatically

micha20:11:05

also it's interesting to see why it's needed

micha20:11:15

i think it's because of the complicated syntax of clojure

micha20:11:23

with all the different kinds of parens

donmullen20:11:39

No - I think it’s a great way to get noobies using clojure w/o having to learn emacs/paredit

micha20:11:42

most of the things it's doing is helping you with the clojure non-sexp things

donmullen20:11:11

Likely many would ‘graduate’ up to full paredit

micha20:11:21

yeah paredit is crippled with clojure because you have {}, [] #{}, #() etc

micha20:11:35

and you can't easily move around them

micha20:11:44

becuase closing tags need to be correctly nested

micha20:11:03

compare to sexps, which can be more easily arranged

micha20:11:19

some early lisps even had ], which means "close all"

micha20:11:38

which is basically most of what parinfer is doing, i think

donmullen20:11:50

Yeah - smartparens works pretty well for me. Off topic for the #C053K90BR channel - how are you liking spacemacs?

micha20:11:52

(foo (bar (bax baf]

micha20:11:05

oh i'm back on vim simple_smile

micha20:11:20

emacs is too complicated and slow

micha20:11:47

and my workflow is more buffer based, and i couldn't get a good way to swap buffers without a lot of keystrokes

donmullen20:11:20

lol - got it.

micha20:11:01

i'm getting started with neovim now

micha20:11:24

feeling good about it

micha20:11:54

there is a parinfer thing for nvim, i think

micha20:11:29

the only problem with vim is that the package mangers have no concept of transitive dependencies

donmullen20:11:18

Yes - I remember seeing a parinfer for newvim.

micha20:11:33

have you tried nvim?

donmullen20:11:35

Seems to me that boot should be included in the clojurescript Quick Start and Dependencies sections.

micha20:11:56

ah, yeah there is an issue for that

donmullen20:11:31

Boot issue or clojurescript issue?

micha20:11:38

boot issue

donmullen20:11:43

Seeing increasing “Yeah I switched to boot and clojurescript builds are so much more approachable.” in #C03S1L9DN channel.

donmullen20:11:04

Has figwheel lib been pulled into boot - or is hot reload still separate?

micha20:11:05

oh wow, that's cool

micha20:11:22

it's still separate, but it does the same thing

micha20:11:30

it's just composable with other things too

micha20:11:43

a lot of code is shared internally

donmullen20:11:50

Yeah but there is a big pull to figwheel/devcards in the community — need a solid story there for boot

micha20:11:55

or at least code that does the same thing

donmullen20:11:22

Any idea if hoplon + devcards play together?

micha20:11:50

i haven't been doing any frontend stuff lately

micha20:11:09

i'm a little behind the curve with it

micha20:11:09

been mostly working on the 2.5.0 release of boot when i have a minute for recreational programming

micha20:11:29

and i've been working on other things at work lately

juhoteperi22:11:14

@donmullen: Devcards works with React.js components only

donmullen22:11:15

@juhoteperi: Thanks for confirming.

donmullen22:11:12

Did you do any more work with bhauman on integrating figwheel lib w/ boot reload?

juhoteperi22:11:22

Or well, I could be wrong. Readme mentions it should work with any Cljs code.

donmullen22:11:05

I think there is an impression that if people leave lein or homemade scripts for boot - they loose figwheel.

juhoteperi22:11:17

Not yet. I haven't had time or incentive to work on Boot-reload as it's working well enough for me.

donmullen22:11:24

Perhaps boot-reload -> boot-figwheel? simple_smile

donmullen22:11:00

If figwheel isn’t really getting additional features - then makes sense to just leave well enough alone.

donmullen22:11:38

boot-reload work you did is great

juhoteperi22:11:14

Probably boot-reload and boot-cljs-repl will be integrated into boot-cljs and then renaming that wouldn't make sense

micha22:11:51

why would reload need to be rolled into boot-cljs?

micha22:11:05

it doesn't need to use the cljs compiler at all

micha22:11:26

it's just looking for changes in the fileset, no?

donmullen22:11:37

gotta run - later guys

micha22:11:45

later don!

juhoteperi22:11:48

There was some reason... maybe

micha22:11:08

i think it does some things that should really be moved to metadata on the fileset

juhoteperi22:11:20

Boot-reload might require additional dependencies

micha22:11:21

and populated by the cljs task

juhoteperi22:11:40

But there could be a way to add deps to cljs compiler pod through cljs.edn perhaps

micha22:11:44

really we want to un-cljs the reload client thing probably

micha22:11:49

and just inject js

juhoteperi22:11:57

It will need to use Closure so I doubt writing Closure JS would make it any faster

micha22:11:17

it wouldn't be for performance, but for generality

juhoteperi22:11:31

Also, we need more complex client, not simpler

micha22:11:36

it doesn't really need closure or cljs to do its thing

juhoteperi22:11:49

There bunch of problems with current implementation that break reloading in some cases

juhoteperi22:11:06

It needs Closure dependency graph

micha22:11:25

yes that's definitely just metadata

micha22:11:29

on the fileset

micha22:11:41

reload shouldn't be computing that itself, for sure

micha22:11:13

basically it has a bunch of files, some of which are reloadable in a web client

micha22:11:22

i.e. js, css, assets

micha22:11:33

it doesn't need to know about cljs to do the right thing

micha22:11:51

just whatever produces the js files should annotate the fileset with the info reload needs

micha22:11:24

the only reason it needs cljs now is becaause the client code is cljs

micha22:11:35

but it's pretty simple code, we could make it just vanilla js

micha22:11:54

and inject it into the page

juhoteperi22:11:33

Hmh, using metadata on fileset could be useful, might help with some of the problems, like only reloading JS files belonging to the open application

juhoteperi22:11:32

Still, I have little interest in fixing things that have been already solved in Figwheel client code

juhoteperi22:11:15

Also, "inject it into the page" would be surprisingly hard

micha22:11:38

just insert a <script> tag with the program as its body

micha22:11:44

into the html file

juhoteperi22:11:52

But how to edit the served html?

micha22:11:02

tagsoup is a good option there

micha22:11:11

or enlive, whatever

micha22:11:22

the html file is in the fileset too

micha22:11:26

presumably

juhoteperi22:11:11

No, I generate index html with Hiccup

micha22:11:36

you could generate it and put the file in the fileset, no?

juhoteperi22:11:15

I could but I don't want to. Generating it in the code makes it trivial to add cache-busters and to enable development tools with environment variables.

micha22:11:10

you don't need cache busters in dev

micha22:11:20

reload isn't for production

micha22:11:05

lol that would be interesting though

micha22:11:13

live coding in production could be awesome

micha22:11:38

i suppose it could prepend the client js to the index.js file or whatever

micha22:11:52

or it could have a defonce type guard and prepend it to every js file

juhoteperi22:11:19

I think it makes more sense to just have separate reload tasks for Cljs and non-Cljs development

micha22:11:55

i think it helps to clarify the actual problem by thinking in terms of decoupling

micha22:11:35

you end up with unanticipated benefits

micha22:11:57

especially ith the metadta thing

micha22:11:19

there are probably all kinds of unexpected useful tools that can use that to do things for you

micha22:11:36

without needing to add them into the internals of the cljs compiler

micha23:11:00

but you're right, there should bedifferent specialized tasks for different purposes too

micha23:11:02

@juhoteperi: i haven been thinking about the gpg change in 2.5.0

micha23:11:23

i was thinking we might make an env var to turn on the new gpg behavior

micha23:11:33

and only deprecate the older way

micha23:11:43

with a message about how to enable the new way

juhoteperi23:11:56

Is there any reason to use the old way?

juhoteperi23:11:13

The new implementation should be compatible

micha23:11:14

only if someone is already using it and doesn't want to change their things to the new way

micha23:11:28

like maybe they can't install gpg for some reason

micha23:11:33

i did that with the target change

juhoteperi23:11:50

I feel strongly that the new implementation is correct and old uses bad practices and is unusable in some cases (CI)

micha23:11:51

BOOT_EMIT_TARGET=no turns on the new behavior

micha23:11:02

right, i agree

micha23:11:19

which is why we could have a message urging people to use the env var

micha23:11:32

or put it in their boot.properties

juhoteperi23:11:57

Hmh I guess it's okay

juhoteperi23:11:37

Is it possible to set in on the global ~/.boot/cache/boot.properties?

micha23:11:49

all the settings are now

micha23:11:57

or even per project

juhoteperi23:11:24

Does boot -u leave other properties besides version in that file alone?

juhoteperi23:11:47

I think the GPG option is more about user than about project

micha23:11:55

yeah i agree

micha23:11:48

but i spent an hour today with a gem issue that resulted in a shitshow in production that came out of nowhere

micha23:11:08

chef all of a sudden started failing to deploy nodes

micha23:11:29

so i'm thinking we should always be extra conservative

micha23:11:39

when it comes to anything that could be a breaking change

micha23:11:36

i'm going to start adding end to end tests

micha23:11:05

i was thinking maybe to make a github organization

micha23:11:12

and fork projects to it

micha23:11:18

and the tests would build those