Fork me on GitHub
#boot
<
2016-02-24
>
alandipert00:02:04

@mobileink: i'm not aware of anything similar but i'd be curious to know

mobileink00:02:01

did a superficial websearch. impression: classpaths isolation remains an issues for gradle. don't get me wrong, I'm not anti-gradle, just interested in dispassionate comparison.

alandipert00:02:52

what really surprises me about VMs and platforms after the boot experiience is that most things don't even have a classpath really

alandipert00:02:08

which to me now is inconceivable

alandipert00:02:34

then i periodically read about upgrading rails apps and am able to concieve of the idea vicariously

mobileink00:02:45

maybe gradle can learn from boot, just as boot can learn from gradle, e.g. flavors.

alandipert00:02:17

i've never used them but when i looked at them i had a sense that flavors could be a library/task

alandipert00:02:42

kind of like the way people implement "profiles" in boot

mobileink00:02:13

I think classpath skullduggery is a barrier to newcomers. certainly was/is for me.

micha00:02:48

i think the best remedy is to not hide it from you

micha00:02:08

because hiding it only gets the beginner out on a ledge of false analogies

mobileink00:02:09

I hope to find time to look at a boot equiv. of flavors soon.

micha00:02:43

so the classpath is key for doing things in the JVM, the best we can do is provide some good tools to help understand and manage it

mobileink00:02:02

gradle flavors are heavily exploited in android.

mobileink00:02:32

@micha yes. but in my experience we cam do much better at explaining the mysteries to noobs. classpaths, classloaders, still pretty arcane even to me.

kul08:02:53

anyone using npm dependencies with clojurescript nodejs based project?

kul08:02:02

please point me to an example

jethroksy10:02:03

hello everyone! I'm presenting on boot at a local clojure meetup, and would love to gather feedback on my slides. Let me know if there's anything I should add/remove! Thanks! http://blog.jethrokuan.com/talks/boot/

juhoteperi11:02:13

@jethroksy: I would explain Lein problems more thoroughly than just the config file

jethroksy11:02:24

what about the slide after that?

juhoteperi11:02:00

- No pods -> Plugins fork additional JVMs - Declarative configuration -> Plugins don't compose - No filesets -> User needs to manage temp directories themselve (http://www.slideshare.net/juhoteperi/clojutre-build-tooling-with-boot-42005279)

juhoteperi11:02:45

What I mean is, (as I see it) each of Boot design choices is targeted to fix something, so that might be useful to explain when introducing pods and fileset etc.

jethroksy11:02:31

I try to talk about it when I'm introducing the concepts in later slides

jethroksy11:02:39

the problem is lein users don't know what pods are

jethroksy11:02:52

so it's hard to explain at the start before the introduction to boot

jethroksy11:02:24

I'll add in the comparisons in the later slides

juhoteperi11:02:49

Not many Lein users probably know either how Lein works internally

juhoteperi11:02:23

That is, when Lein plugin has some dependencies it forks another JVM and loads separate Clojure env with those dependencies

jethroksy11:02:54

pods is a super cool idea

dm311:02:36

you can do the whole presentation without pods

dm311:02:58

we had this last week in Zurich Clojure meetup

dm311:02:04

people were still impressed simple_smile

juhoteperi11:02:26

Yeah, they are mostly implementation detail and mostly interesting to task developers

jaen11:02:59

I have directory/files outside of the classpath (CSSes in a npm module), want to copy some into the fileset, what's the best way to do it? Shelling out to mv sounds like a hack.

juhoteperi11:02:03

But they also lower Boots memory consumption when compared to Lein because Boot doesn't need multiple JVM processes, so that could be something users are interested in

juhoteperi11:02:39

But maybe people aren't running that many Lein plugins parallel today compared to 1.5 years ago, as Cljx is no longer needed

jethroksy11:02:31

I think dependency hell is a real problem in Lein, and pods is just way too elegant a solution to not show simple_smile

dm311:02:51

pods are definitely worth mentioning

jethroksy11:02:15

I won't go into too much detail

jethroksy11:02:20

because I really can't

jethroksy11:02:39

talk is around 30 minutes

jethroksy11:02:33

@jaen have you seen :asset-path

jethroksy11:02:37

thanks for all the feedback @juhoteperi simple_smile

jaen11:02:29

@jethroksy: I don't think it will help me? I have a directory I serve assets from and it's different from where I have to get those files.

jaen11:02:38

So I can't point :assets-path there.

jethroksy11:02:27

the fileset manages two things: 1. files in classpath 2. files in asset path

jethroksy11:02:56

I don't think the fileset api has access to anything beyond that

jaen12:02:25

Yeah, but I want to put external files into the fileset in my task.

jaen12:02:43

Shelling out to cp with the target relative to tmp-dir!-created directory works

jaen12:02:16

But shelling out to do that feels… off. This seems like something that would be a common task so I thought there's maybe a helper function I'm missing.

dm312:02:51

you can use java.nio.file.Files/copy

jaen12:02:58

@dm3: does that work on directories too?

dm312:02:47

try looking in boot sources - I think they have some utils

jaen12:02:16

@dm3: hah that looks fairly involved, that's why I figured maybe someone had already created some helper for that; I'll stick with shelling out for now, but look through sources for alternative later then.

dm312:02:27

what was the snippet for modifying boot env when creating a task?

micha12:02:16

@jaen: there is a nice trick in clojure for recursively copying directories:

micha12:02:47

(defn copyrec [src-dir dest-dir]
  (doseq [f (->> src-dir io/file file-seq (filter #(.isFile %)))]
    (io/copy f (io/file dest-dir (relative-to src-dir f)))))

micha12:02:26

i think there are some functions in boot.file that might be useful

micha12:02:43

that namespace isn't part of the public api but it's available from any pod

jaen12:02:28

@micha: and if I want to filter files out I just modift the predicate in that filter?

jaen12:02:33

Looks neat, thanks!

jaen12:02:47

I'll also take a look at that ns

micha12:02:54

i think there is a boot.file/sync! function

micha12:02:04

actually that might be in boot.core too

micha12:02:12

it might do what you need

jaen12:02:57

Would be good, but it says it deletes missing files, I want to keep what was already there though.

jaen12:02:02

But now I know where I should be looking

dm312:02:28

@micha - is the with-env thing now in boot proper?

micha12:02:56

@jaen: if you are going to add to the fileset you don't need to keep existing files

micha12:02:09

you can just make a tmp-dir for that sync proecss

micha12:02:22

and use add-resource etc later

micha12:02:53

like with add-resource you don't need to have all the files in the same directory

micha12:02:03

you can call it multiple times with different directories

micha12:02:09

and they're all overlayed

jaen12:02:40

add-resource unions with what's already there.

micha12:02:13

it's satisfying when options are not needed

micha12:02:52

@dm3 2.6.0 will have it hopefully

jaen12:02:27

And if I need to filter, I've got your snippet (though it would make sense to probably include something like that in the core).

micha12:02:06

if you want to filter you can do that when you do add-resource

micha12:02:27

it accepts :include and / or :exclude kwarg options

jaen12:02:48

Nice, didn't know about that

jaen12:02:56

Also ugh, missclicked on fork D :

micha13:02:26

also :mergers option if you want to merge files from your tmpdir with files of the same path that are already in the fileset, instead of clobbering them

micha13:02:54

you can specify a map of path regex to merger function

jaen13:02:01

The html doc doesn't say what the :include option expects; is that a set of paths, set of files, predicate to filter things that gets path, that gets File object?

jaen13:02:07

Or I'm blind and don't see that?

micha13:02:34

@richiardiandrea fixed the documentation black hole there, hope to merge things this week

micha13:02:49

but if you do boot uber -h you can see the docs

micha13:02:01

it's the same for the uber task as for add-resource etc

micha13:02:18

except there are no default filters or mergers when you call add-resource

micha13:02:27

the uber task sets some defaults

micha13:02:41

but it just passes options through to add-resource

jaen13:02:46

Yep, I've just run boot uber -h locally; it seems it expects a set of regexes that match file paths.

jaen13:02:58

Nice, thanks a lot for the help!

micha13:02:14

sure, np!

mobileink13:02:13

this: boot sift -m "(.*clj$):WEB-INF/classes/\$1" does what I want; it moves .clj files from src to WEB-INF/classes, according to show -f. But this: boot sift -m "(.*clj$):WEB-INF/classes/\$1" target discards the WEB-INF stuff. I guess the result of sift is not getting committed. Is there a way to do this on the command line?

micha13:02:33

@mobileink: are the .clj files in :source-paths or :resource-paths?

micha13:02:38

i think that might be the issue

mobileink13:02:33

I have :source-paths #{"src"} :resource-paths #{"resources/public"}. E.g. src/hello/echo.clj gets moved to WEB-INF/classes/hello/echo.clj.

micha13:02:01

you can add "src" to :resource-paths instead of :source-paths

micha13:02:11

sift :move doesn

micha13:02:18

t change the roles of the files

mobileink13:02:24

ok, that works. why? i don't see the connection.

micha13:02:45

that's the difference between :sourec-paths and :resource-paths, the roles

micha13:02:02

files in :source-paths don't end up in packaging

mobileink13:02:02

oh right, input/output roles

micha13:02:28

personally i think the whole roles thing is maybe overcomplicating things, but people tell me they like it

mobileink13:02:44

is there a way to display roles in the fileset? e.g. show -r

micha13:02:03

but show -f could color them or something

alandipert13:02:05

@jethroksy: good luck on your presentation, I like your slides

mobileink13:02:07

i would favor something like [io] favicon.ico, [i ] echo.clj

mobileink13:02:32

in any case, is it correct that each item in the fileset is marked with its roles? stuff in :resource-paths is marked [io], stuff in :source-paths is marked [i ]?

micha13:02:58

yeah that's true

micha13:02:06

most jvm build tools have some separation of source and resource

micha13:02:20

boot just makes it a general attribute

mobileink13:02:34

ok, so the rule seems to be that fileset items carry their roles with them as they move thru the pipeline. target will write anything marked [o]. correct? so if echo.clj is in :resource-paths, it gets marked [io] in the initial fileset; if it gets moved around, it will still be [io] when it gets to target, so it gets written.

micha13:02:37

not tied to any specific model for how to build a project

micha13:02:07

the idea is the output files are files that will be included in packaging

micha13:02:17

the target task is a packaging task

mobileink13:02:24

pretty cool. but personally i think the idea of items carrying their roles around is much easier to understand, since i don't think of stuff output to the target dir as involving packaging until I'm ready to package and deploy.

mobileink13:02:56

during development, the target dir is just a workspace

micha13:02:07

it's important to have consistent, simple concepts though

micha13:02:45

rather than concepts that are specific to building java libraries and concepts that are specific to building clojurescript apps and ...

micha13:02:26

i guess that's the core principle

micha13:02:33

boot itself doesn't know how to build anything

micha13:02:49

i mean anything specific

mobileink13:02:08

right, that's why i like the concept of attaching roles to items persistently. i found the build/packaging distinction a little puzzling, since i don't normally think like that, it's all just build and run for me most of the time

micha13:02:22

during development the target directory is undefined state

micha13:02:41

it's only in a defined state after boot exits

mobileink13:02:40

well, "development" to me means the whole process of building, running, testing, etc. i guess by "during development" you mean "while boot is running"?

micha13:02:20

i guess that's how i do "development"

micha13:02:28

boot's just running in incremental mode

jethroksy13:02:24

@alandipert: thanks! I'm using some of your libs for my demos

micha13:02:32

i think you're right though, in hindsight maybe it owuld have been better to use sift explicitly to select only output files etc in the pipeline before the packaging tasks

mobileink13:02:34

ok, right, i guess i think of boot tasks like serve or run as different beasts than build tasks that produce target output. in any case, now i think i finally understand what :resource-paths does and how roles function in the build process. very cool.

micha13:02:32

as time goes on it seems like any build-related concepts in boot have been kind of a mistake and are better left to the user explicitly

micha13:02:49

like the target task, and possibly this

mobileink13:02:43

what counts as a packaging task, for you? i would call jar and war packaging tasks, for example.

micha13:02:46

packaging is construction of artifacts that will be used in other environments

micha13:02:07

basically packaging represents building a classpath for another JVM process

micha13:02:16

so that might be building a jar or war file

micha13:02:32

or it may be building a "classpath" for a cljs single page app that is deployed to s3

micha13:02:50

my cljs applications have a "classpath" oriented architecture, too

micha13:02:02

basically that's how i approach all applications now

micha13:02:37

jars in maven provide one thing only: a classpath snapshot

micha13:02:20

while you're building the jar and stuff you have a merging of the classpath that will be part of thejar and the classpath your build program needs to run

micha13:02:36

that's why the fileset roles are there

micha13:02:51

input files are part of the classpath the build program uses

micha13:02:11

output files are part of the classpath you want to create in your final artifacts

micha13:02:25

of course files in the fileset can be both at the same time

micha13:02:10

but i think of my build programs as a transformation of classpaths

mobileink13:02:44

no time at the moment to edit the wiki but wanted to register this somewhere

mobileink13:02:12

build pgms as classpath transformers, interesting, never thought of it like that before

micha13:02:09

it's interesting because you might think, why do you need to have a separate environment as the destination for the classpath you build?

micha13:02:23

like when i deploy to docker, for example, boot is the entry point

micha13:02:34

it builds the classpath for the application, then runs it

mobileink13:02:52

this actually solves the questions i was asking when i first joined this channel - i couldn't for the life of me see how to move stuff from src to WEB-INF/classes. now it's easy peasy

mobileink13:02:43

maybe you need a slogan for boot. Howsabout: Boot. ... it will change your life 😉

mobileink13:02:05

really, it has completely changed the way i think about the practical side of software construction.

micha13:02:30

that will be added to the testimonials section 😉

mobileink13:02:54

fine by me, i got more of 'em 😉

mobileink13:02:38

i find myself thinking about build/config stuff in terms of functionals (tasks) in the same way i think about structuring my programs in terms of functions. makes for a much more integrated view of the whole process than you have with "classic" build tools, where you have to think of configuring foreign stuff.

micha14:02:57

yeah for me the "build" and "application" concepts have merged somewhat

micha14:02:06

the line dividing them is definitely blurred

dm314:02:25

@micha - could you please point me to where the with-env is implemented. Was looking in repo but couldn't find

micha14:02:41

i believe @dominicm made a PR that includes it

dm314:02:21

doesn't seem to be there

micha15:02:46

if you look on my github there are some gists about it

micha15:02:05

and i think the juxt/edge project is where @dominicm was developing this stuff, so it's there too https://github.com/juxt/edge

micha15:02:02

i've been heads-down with work stuff lately, but hopefully all the awesome new stuff will be integrated into the 2.6.0-SNAPSHOT branch soon

micha15:02:13

so we can test it and use it

dm315:02:42

@micha reading on the yesterday's conversation between you and :richardiandrea regarding the propagation of :source-paths changes to new pods. It seems from the user-facing API it would be nice to propagate all parts of the environment, not only the :directories. E.g. with-env would only work for :dependencies and :directories, not :source-paths which is very confusing. Am I missing something?

dm316:02:32

does the fact that I want to change :source-paths dynamically indicate that I need to run a new boot core?

micha16:02:31

well pods don't have any notion of source vs resource

micha16:02:51

so mocking it in the API i think would make things more complex and confusing

micha16:02:13

pods just have a classpath, which is expressed in :directories

micha16:02:11

you can change :source-paths dynamically, no problem

micha16:02:21

the set-env! machinery correctly adjusts the classpath etc

kul16:02:22

pods are like the docker of jvms !

kul16:02:51

i wish we can make it more easier to use as a library

kul16:02:12

something like osgi but without the ugly parts

micha16:02:02

yeah the issue is that if you load clojure outside a pod then all pods are compromised

micha16:02:21

so the entry point to the application needs to be the pod java factory

micha16:02:41

alan's uberboot project is how you can use pods without boot i think

micha16:02:00

it builds you an uberjar with the correct entrypoint and all clojure code run in pods

kul16:02:28

i wonder why the clojure dependency outside pods is all about?

micha16:02:23

boot.sh sets up the jvm for pods before loading clojure

micha16:02:28

and it loads clojure into a pod

micha16:02:37

without that you couldn't get isolation

micha16:02:46

because of the way clojure manipulates the classpath

micha16:02:34

at least i couldn't make it work simple_smile

micha16:02:09

i tried many things before taking the nuclear option of writing a java application as the entrypoint 😄

kul16:02:38

interesting work!

kul16:02:32

so everything in boot is being run in a pod?

kul16:02:35

even when we run a custom task which does not run a pod

kul16:02:22

how is it that once you are inside a pod clojure being on classpath is not a problem for spawning further pods?

richiardiandrea16:02:05

@micha a proposal to make the env for pods less confusing would be to remove the unused keys, I found a bit weird that get-env in the pod was returning source-paths if it is actually just using directories. Given that pod are low level (and they should stay like that) it makes sense to me to restrict their env map. This will also help with discovery at the repl, dunno whether this is possible, just an idea ;)

dm316:02:36

in my case I'm trying to use with-env and add a source path which is otherwise not present. Task which is modified by with-env creates a pod when instantiated, so the pod captures the proper :source-paths which at that time contain the correct files (boot auto synchronizes the sources when set-env! is called). However, once the with-env has ended boot resynchronizes the :directories with the old :source-paths and the files are gone.

richiardiandrea16:02:03

Yes yesterday I was doing the same but creating the pod manually and using add-classpath

micha16:02:20

@kul: all pods are siblings, whose parent is the java class boot.App

micha16:02:43

so they can communicate via boot.App

micha16:02:03

for example your build.boot program runs in clojure in a pod that is automatically created by boot

micha16:02:33

you can call boot.pod/make-pod from that pod, which calls a static method of the boot.App class which is on the classpath of every pod

micha16:02:03

that static method creates a new pod via the same mechanism that created the main pod, and returns a reference to it

micha16:02:26

with that reference in hand you can call methods on the pod instance to evaluate clojure forms in the pod or call functions etc

micha16:02:28

@dm3: isn't that the expected behavior of with-env?

micha16:02:59

it's supposed to restore the original state when its body has been evaluated

micha16:02:24

@richiardiandrea: i think you may be right about removing extra keys

micha16:02:33

have to think about it though

pandeiro16:02:48

@juhoteperi: is there anything holding back a 0.4.6 release for boot-reload?

richiardiandrea17:02:35

@micha np I have just thrown it there ;)

juhoteperi17:02:06

@pandeiro I don't think ao. I'll check when I get home.

dm318:02:03

@micha - that's the expected behaviour, yes. But the problem is it's not very useful. Are there more scenarios that could make use of with-env? Currently I can only see that if you have a task that creates the pod in the constructor and if you limit your with-env call to :directories and :dependencies then you can influence the task.

micha18:02:52

@dm3: yep that's the use case

micha18:02:11

a niche thing, whch is why it's never been added to boot yet

dm318:02:30

ok, so it's more like with-pod-env

dm318:02:20

and it seems worthwhile to differentiate between the Core env and Pod env as @richiardiandrea suggested

mobileink18:02:48

for the new file-roles branch of boot-fails i have a question about roles. it's easy do demonstrate at the command line that a .clj file in :asset-path can be moved but will not be compiled by a subsequent aot -a task. from that I infer that the aot task inspects the fileset and selects only files marked +input. and you can transform roles as well, e.g. boot show -f sift -S assets aot -a target will add +input to the assets and so aot compile them. so i infer that we can treat "role" as a kind of metadata attribute, rather than a rule that boot enforces. question: can i violate this discipline? can i write my own task in order to transform a [+output, -input] file? of course conceptually any such task could be viewed as one that first adds +input, but i'm wondering if there is anything in boot that would prevent me from reading an asset, transforming it and writing the result.

micha18:02:51

other than maintaining sanity simple_smile

mobileink18:02:32

ok, good, so boot provides the mechanisms you need but does not play sheriff - other than keeping filesets immutable. just like clojure, in a word.

micha18:02:50

yeah boot doesn't know or care

micha18:02:58

it just provides the abstractions

micha18:02:18

it's up to you to build things with it

mobileink18:02:13

have you considered that we can think of boot as a kind of os filesystem-based implementation of Clojure's map api? it doesn't look like the map api, but the concepts are all there. just think of files as key-val pairs, where key is name and val is content. seems to me that the fileset implements this even if it does not directly present a key/value interface.

mobileink18:02:09

that makes it easy to explain the fileset pipeline - its a transform pipeline, exactly the same as you would have with ordinary maps

micha18:02:15

the fileset has the :tree key, whose value is a map of path to TmpFile record type

micha18:02:23

but it's not that simple

micha18:02:27

because it's like git

micha18:02:36

it's not truly pure

micha18:02:51

it's managing a content-addressed storage area

micha18:02:11

the fileset object contains immutable data that is useful

mobileink18:02:15

sure but that's an implementation detail, imo - you could use a database instead of the os filesystem, for example. main thing is immutability layer over mutable stuff

micha18:02:17

but it's not sufficient

micha18:02:36

yeah but that's what makes it incompatible with the immutable collections absrtaction

micha18:02:59

like you can present it as a mostly immutable thing

micha18:02:07

and in most ways it works

micha18:02:14

but that's not sufficient

mobileink18:02:48

where's the incompatibilty? clojure's implementations are also built on mutable host stuff, no?

micha18:02:50

well for example, if you serialize the fileset you don't have enough information to deserialize it

mobileink18:02:52

i ask because i'm working on a blog post explaining filesets using standard {:foo "bytestream here..."} notation

micha18:02:31

they're not really values in the true sense

micha18:02:49

because they're pointing to things that are mutable and whatnot

mobileink18:02:17

ah, but what does serialize the fileset mean? to me, you could serialize a fileset to e.g. a database, and you could in principle deserialize it

micha18:02:18

i guess i need to think about it more

mobileink18:02:05

ok, what i need to add to make the comparison work is the observation that the host java constructs behind IPersistentMap etc. are effectively immutable because no other process can touch them and clojure is designed not to change them - but as host objects they could be mutated. where the host env is the os filesystem, of course you have the possibility of mutation. but boot arranges to hide that at least for the duration of the boot run, using the mechanism of hidden temp files to ensure "boot-time" immutability. any other mechanism that ensures boot-time immutability could work as well. so to the user, the file system rooted at the project root is just as immutable as any clojure map, for the duration of the build process. does that sound correct? i hope so, it's very cool

micha18:02:50

that sounds legit to me

mobileink18:02:37

if so, i think what you really have here extends well past build/config tasks. i imagine it could form the basis of a lib that would make immutable fs operations easily available to any clojure pgm. this is related to the idea i mooted the other day about supporting a standard map api for boot.

micha18:02:57

yes, we've keep it separate to make it easy to lift out into a library

mobileink18:02:23

yeah, i can see the wisdom of that now

micha18:02:23

there are a few places where it's boot specific for performance reasons

micha18:02:59

but that could be generalized i imagine

micha18:02:50

also lifting it out into a library would mean maintaining it in two places, because boot can't have dependencies

micha18:02:00

which i am hesitant to do simple_smile

mobileink18:02:18

i've got some backing at work for introducing clojure, and i expect some resistance from both pgmers and mgrs - i think boot will be a huge argument in favor of clojure. i don't know of any other system that does this sort of stuff at all

mobileink18:02:43

and everybody hates their current build tools

micha18:02:08

yeah i always have

micha18:02:38

although i still perversely enjoy gnu make

mobileink18:02:36

i'll give up make (and emacs) when they pry my cold dead fingers off it (to paraphrase charlton heston) 😉

pleasetrythisathome20:02:23

hey all. i'm getting an error using advanced compilation with externs in deps.cljs

pleasetrythisathome20:02:29

ERROR: JSC_DUPLICATE_EXTERN_INPUT. Duplicate extern input

pleasetrythisathome20:02:38

ERROR: JSC_DUPLICATE_EXTERN_INPUT. Duplicate extern input: /Users/pleasetrythisathome/.boot/cache/tmp/Users/pleasetrythisathome/Code/work/populace/populace/1r0q/fwjp2k/js/booking/booking.ext.js at (unknown source) line (unknown line) : (unknown column) ERROR: JSC_DUPLICATE_EXTERN_INPUT. Duplicate extern input: /Users/pleasetrythisathome/.boot/cache/tmp/Users/pleasetrythisathome/Code/work/populace/populace/1r0q/fwjp2k/js/timekit/timekit.ext.js at (unknown source) line (unknown line) : (unknown column) ERROR: JSC_DUPLICATE_EXTERN_INPUT. Duplicate extern input: /Users/pleasetrythisathome/.boot/cache/tmp/Users/pleasetrythisathome/Code/work/populace/populace/1r0q/ywpinm/js/booking/booking.ext.js at (unknown source) line (unknown line) : (unknown column) ERROR: JSC_DUPLICATE_EXTERN_INPUT. Duplicate extern input: /Users/pleasetrythisathome/.boot/cache/tmp/Users/pleasetrythisathome/Code/work/populace/populace/1r0q/ywpinm/js/timekit/timekit.ext.js at (unknown source) line (unknown line) : (unknown column)

pleasetrythisathome20:02:16

looks like the files are in the classpath twice perhaps? any idea why that'd happen?

micha20:02:31

you can use show -f to see if they're in local files

pleasetrythisathome20:02:16

only see them once

micha20:02:39

i mean if you see them at all in the fileset you probably have issues

micha20:02:48

because they're in jhars too presumably

pleasetrythisathome20:02:46

not in jars currently...i was just including them in src/

pleasetrythisathome20:02:58

i have a ticket to put them into cljsjs packages...

pleasetrythisathome20:02:19

i suppose that might solve my problem as well

micha20:02:53

it's seeing them twice the fileset

micha20:02:57

you can see in the paths

micha20:02:20

1r0q/ywpinm and 1r0q/fwjp2k