Fork me on GitHub
#boot
<
2016-08-23
>
talexxx00:08:12

Can I ask a question about bootlaces here?

talexxx00:08:05

I wrote my first package-worthy CLJS project, but I’m stumbling at the deploy process: https://github.com/adzerk-oss/bootlaces/issues/15

talexxx00:08:30

Someone suggested I make a ticket in #clojurescript, but if it’s something I can reason through I’d be happy to work it out

micha01:08:35

@talexxx can you please paste your build.boot?

micha01:08:50

it looks like you have overlapping :source-paths and :resource-paths or something

micha01:08:53

like for example:

micha01:08:20

(set-env!
  :source-paths #{"foo"}
  :resource-paths #{"foo/bar"})

micha01:08:56

in this case :resource-paths and :source-paths overlap, that is to say foo/bar directory is trying to be added to both

flyboarder05:08:58

@seancorfield: Trying to get boot-new working but it seems it overwrites my file everytime due to the watch task, starts an infinite loop of appending

seancorfield05:08:08

What exactly are you trying to do @flyboarder ?

flyboarder05:08:17

@seancorfield: generate a namespace with version information

flyboarder05:08:42

so it rebuilds the ns everytime, but this starts an infinite loop

seancorfield05:08:50

Wait... you're using watch to kick off the generator?

seancorfield05:08:25

So every time the files change, you run the generator... which changes the files, so watch runs the generator... which changes the files...

seancorfield05:08:38

Seems like that's exactly the expected behavior...?

flyboarder05:08:08

except that generators are supposed to be “safe” as per the docs

flyboarder05:08:25

so should they not write more than once

seancorfield05:08:43

Not sure what you mean by that?

flyboarder05:08:09

I was under the impression that the generators need force option to rerun if the file already exists

seancorfield05:08:43

For the ns generator... it only creates a file if it doesn't exist.

seancorfield05:08:34

If your generator appends stuff, it's going to append it every time it runs.

seancorfield05:08:54

Unless you make the generator read the file and only add the new definition if it doesn't exist.

seancorfield05:08:36

The generators don't overwrite a file, they just append to it.

seancorfield05:08:54

I can clarify that in the readme 🙂

flyboarder05:08:03

Ok, so I will need to parse the file somehow then and selectively update it

flyboarder05:08:03

Is there a way to delay making the changes to the fileset, I would think running a generator would be like a compile task

seancorfield05:08:08

There, see if the updated readme is clearer?

seancorfield05:08:25

The generator does exactly what you program it to do.

seancorfield06:08:06

The built-in ns creates a new file if and only if it does not exist (unless you force it). The built-in defn always appends a new defn form.

seancorfield06:08:44

If you write a generator that parses an existing file and modifies it if necessary then... it will do exactly that...

flyboarder06:08:05

right makes sense, I poorly assumed watch wouldn’t be called again by tasks that follow it

seancorfield06:08:59

Yeah, the boot pipeline catches me out fairly often 😐

flyboarder06:08:36

I wonder how things like cljs generate files without causing watch to fire again

seancorfield06:08:56

They don't generate source files...

seancorfield06:08:10

(`watch` is looking for source file changes)

flyboarder06:08:02

@seancorfield: thanks so much, answers all my questions!

micha13:08:58

yeah if you write to the project directories you're escaping all the pipeline affordances

micha13:08:15

the pipeline is built around the fileset, which does have the expected behavior

micha13:08:40

the project directories are completely outside the scope of boot pipeline stuff

micha13:08:24

if you modify them in a task boot can't distinguish that from user interaction

micha13:08:47

why does boot-new write to project directories?

lwhorton14:08:02

does :compiler-options {:preloads '[devtools.preload]} not work with boot-cljs?

lwhorton14:08:23

i see no indication it’s inside the out build, and the preload module never seems to be loaded

dominicm14:08:47

@micha I think because it's designed to create projects.

micha15:08:10

@dominicm wouldn't it emit the project into the target directory?

micha15:08:18

via the fileset?

juhoteperi15:08:22

@lwhorton: Are you defining this in build.boot or .cljs.edn?

lwhorton15:08:26

(def devtools-config {:devtools/config {:features-to-install [:formatters :hints :async] }})

...
    (cljs :compiler-options {
                             :preloads '[devtools.preload]
                             :external-config (merge {} devtools-config)
...

so what the heck am I doing wrong here?

lwhorton15:08:33

build.boot^

dominicm15:08:59

@micha: General usage is boot -d seancorfield/boot-new new -t app -n myapp where myapp is the folder to write to. So it possibly subverts the fileset

micha15:08:13

interesting

micha15:08:31

seems like emitting files would be what the target task would do normally

micha15:08:26

(target :no-clean true) allows you to dump files into a directory already populated with things, too, btw

lwhorton15:08:24

@juhoteperi does it belong in build.boot or a cljs.edn file?

juhoteperi15:08:34

@lwhorton: Both should work

juhoteperi15:08:35

Options in .cljs.edn compiler-options will overwrite options from task options

juhoteperi15:08:07

But if you haven't set preloads etc. in both it should woerk

lwhorton15:08:25

do I have to define a boot.cljs.edn {:requires [boot.core] :init-fns [boot.core/enable-logger] }? that seems to be what the preload modules is for:https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/preload.cljs. I assumed just including this as a preload would automatically invoke (core/install!) before my main file was loaded?

juhoteperi15:08:05

you can add -v option to Boot to get Boot-cljs write the final Cljs options out

lwhorton15:08:18

but that devtools.preload module never shows up in the build, I can’t search for it in devtools, and core/install! is never called…hmm

lwhorton15:08:23

so peculiar ..

lwhorton15:08:44

i’ve tried every which combination and nothing wants to work. i wonder if Im missing a somewhere 😕

dominicm15:08:43

@micha if your curiosity is like mine, I found the relevant bit of code suggesting that it does indeed output outside the fileset (makes sense for it's purpose) https://github.com/seancorfield/boot-new/blob/master/src/boot/new/templates.clj#L163

micha15:08:47

@dominicm i don't see it, why not just write to a dir and add to fileset?

micha15:08:00

then use target task to write to final output dir

micha15:08:32

like why would the dir it writes to not be a temp dir?

dominicm15:08:15

@micha: Probably need to defer to @seancorfield for specifics. Might just have been a conception that the fileset is just for temporary files, not things you want to persist.

juhoteperi15:08:24

@lwhorton: I tested and managed to get arbitrary option from task option :compiler-options to show up on debug output enabled by -v

seancorfield15:08:35

@micha because when you run boot-new you don't have a project: you are creating an entire file system structure and populating it with new files.

micha15:08:04

right but wouldn't the target dir be the resulting project dir, basically?

micha15:08:21

it's going to write to some directory, just like the target task does

seancorfield15:08:13

(How come this discussion is only coming up now?)

micha15:08:52

sorry i didn't mean to complicate things 🙂

micha15:08:59

disregard me

micha15:08:03

how do you feel about rolling boot-new into boot for the 2.7.0 release, by the way?

seancorfield15:08:23

Actually I think we did have this discussion.. And the consensus was boot-new correctly operates outside the pipeline because it is meant to be a one-off task used to create a project. No one gave a compelling reason for it to use the boot file system idiom at the time. But I guess we could revisit that ... ?

micha15:08:37

it would make it composable

micha15:08:42

with other tasks

seancorfield15:08:48

For boot-new to use target to write the actual file tree, it would have to have control over the target folder name and whether to overwrite the directory or not

micha15:08:49

and the watch task etc. of course

micha16:08:00

you'd do that with your target task

micha16:08:32

doesn't seem bad to separate those concerns really

seancorfield16:08:55

That would mean you'd need more command line arguments - it's already harder to use than lein new

micha16:08:41

we could make boot-new an option to boot itself

micha16:08:52

then it could do some stuff like add the target task and so on

micha16:08:15

and with the 2.7.0 feature of positional arguments to tasks we can clean up a bit maybe

micha16:08:37

like boot --new ...

micha16:08:57

but possibly allowing you to add more tasks to the pipeline or something

micha16:08:08

with target task schtupped onto the end

juhoteperi16:08:34

I am doubtful on benefit of composing boot-new tasks.

micha16:08:07

yeah it's a hard problem

juhoteperi16:08:14

Project template is already so complex problem that I don't see how several tasks could produce something which works together

juhoteperi16:08:31

And using boot-new tasks with watch task doesn't sound very useful

micha16:08:32

also that's what clojure is doing in our program

micha16:08:44

like we generate code with macros

micha16:08:50

not with templates

micha16:08:24

so yeah disregard please 🙂

micha16:08:09

when templates get too fancy that means we should probably look at the code

micha16:08:25

like the hoplon template is really just to generate a list of dependencies

flyboarder16:08:06

@micha so what about for my use case, where I want a namespace generated on every run?

flyboarder16:08:05

That seems like It should work, if im using generators wouldnt it make sense to have a task which runs a bunch of generators in a safe way, template might be another story as you probably only want that once

micha16:08:20

there must be a better way to do that

micha16:08:53

writing to the project inside the pipeline

micha16:08:05

one option is to write to a file that's not in the watched directories

micha16:08:32

then generate the thing in the fileset, the VERSION file, from that

flyboarder16:08:39

I guess I could have the generator write things to a tmp dir

flyboarder16:08:19

but then i need access to the target output when I call the generator

micha16:08:14

why not just print the version.properties to stdout

micha16:08:28

boot version -x inc > version.properties

micha16:08:48

that preserves the boot way of leaving changes to project files with the user

micha16:08:05

so you don't end up with weird situations to debug

flyboarder16:08:25

@micha the version.properties file isnt the issue, people are wanting a namespace to call in their project code that has the version information in it, im looking to statically generate this namespace

micha16:08:53

you can generate that in the fileset, no?

flyboarder16:08:36

yes but I was under the impression that is what the boot-new generators are for

micha16:08:25

the alternative is to have a edn file in the project instead of version.properties

micha16:08:40

and just edit that

seancorfield17:08:45

(sorry, had to step away in the middle of the boot new chat)

seancorfield17:08:14

The thing with boot-new is that it’s usually generating a project.clj or build.boot file so I’m not sure how you’d really compose it with other tasks — you’d be in the wrong directory to start with (you’d normally start in a folder with no build.boot file — would you expect Boot to change down into the newly created folder and then start over with loading that new folder’s boot.properties and build.boot file?).

alandipert17:08:32

maybe it would be cool if it took an argument that put the generated project on the fileset? for dev-ing templates

alandipert17:08:54

that seems like the uncommon case, but a useful one to support, vs the common case of someone pulling it in and running at the CLI and not composing with any other tasks

alandipert17:08:27

actually that would be extremely usefue for developing templates

flyboarder17:08:08

@seancorfield: I think your example is correct if you are generating a new project from a template, but in the case of a generator I think they should be able to work with existing projects also

flyboarder17:08:23

so that you can compose them

micha17:08:43

are there any examples of composing generators?

micha17:08:55

@juhoteperi made a good point there i think

micha17:08:10

but like when i go to a directory and type boot new whatever --name foop and it creates a directory named foop with stuff in it, that is the same as boot some-task target -d foop

juhoteperi17:08:07

Perhaps there will be at least two kinds of generators? Those setting up new projects with boot-new and some that add files to project fileset?

juhoteperi17:08:35

or even project source-paths, I haven't needed that myself but maybe it would be useful some times

seancorfield17:08:24

Well, the generator can do anything

seancorfield17:08:39

So yes it absolutely could write to the boot fs abstraction etc

seancorfield17:08:50

The examples just happen to create and modify source files

seancorfield17:08:00

Because the lein project it was based on did exactly that

flyboarder17:08:35

@seancorfield: I can just pass the filesystem as an arg to the generator tho correct?

seancorfield17:08:42

If you’re generating a new source file (like the ns generator), how would that sit with a target task?

seancorfield17:08:18

@flyboarder: currently the generate-code helper is not passed the fs argument from the base task… and current generators assume they get passed a prefix and "some args"

seancorfield17:08:37

There would need to be some re-plumbing done in order to be able to pass the fs down into the (user-provided) generator...

flyboarder17:08:09

I tried using the prefix and passing it a tmp-dir! path but the generator throws an error about relative paths

flyboarder17:08:19

so that didnt work 😛

seancorfield17:08:30

I feel like saying "of course"...

seancorfield17:08:56

The task assumes pass-thru and does not let the generator do anything with the file system abstraction.

seancorfield17:08:28

Again tho’, this comes back to the boot new / generate task being specifically for creating / modifying source files tho’...

seancorfield17:08:57

And if you modify source files, and you have a watch task, then it is going to trigger because the source files changed.

flyboarder17:08:05

right it all makes sense when it’s broken down, just not the expected behaviour compared to other boot tasks

seancorfield17:08:19

Boot new is "not like other boot tasks" tho’...

flyboarder17:08:51

right, and I think that would be a bit more clear if it gets pulled into boot 2.7 as an argument?

seancorfield17:08:01

It is operating "outside the system" because it is (primarily) intended to create a project in which to run Boot...

seancorfield17:08:23

Entirely possible. We discussed it before and @micha didn’t want to roll it into 2.6.0

flyboarder17:08:26

boot —new I wouldnt expect that to work like a task

seancorfield17:08:03

I restructured the source code to match Boot’s internal task structure in preparation for it being PR’d in — I even sent a PR 🙂

micha17:08:28

we can do it for 2.7.0 i think

flyboarder17:08:32

yeah this is really just me assuming too much about the task behaviour

micha17:08:41

seems like a good time for it

seancorfield17:08:41

I don’t know what it would have to look like to become a new command line argument (but having positional arguments would make it nicer to use!)

seancorfield17:08:21

just bear in mind that there are quite a few modifying arguments (look for snapshots or not, etc) as well as the ability to pass arguments down to the template itself

seancorfield17:08:48

I’m more than happy for the code to be included in Boot 2.7.0 is whatever form it needs to be.

seancorfield17:08:17

I’m still not quite sure how you’d deal with the issue that it (normally) generates a new folder tree containing new source etc files — would the expectation be that the rest of the Boot pipeline ran in the context of that newly generated project?

seancorfield17:08:47

Doesn’t Boot load boot.properties etc from the current directory before it runs any tasks?

micha17:08:29

i'd think we can have it do what it does now

seancorfield17:08:54

What is the expectation if you’re using, say Clojure 1.8.0 by default and you boot —new a project based on a template that uses Clojure 1.9.0 or Clojure 1.7.0?

seancorfield17:08:37

How would that compose?

micha17:08:42

it could work the same as it works now, no?

micha17:08:05

composition seems not that useful

micha17:08:10

like for the hoplon template, for example, i think the generator should just create a build.boot file, and that's it. dependencies plus some tasks

micha17:08:22

the demo app would be in a jar dependency

micha17:08:44

rather than generating source files

flyboarder17:08:30

^ how I saw this in my head was being able to call the hoplon template as someother app template and build off of it

micha17:08:44

yeah that's really complicated though

micha17:08:48

think chef

flyboarder17:08:57

but thats kinda what the filesystem does anyway

flyboarder17:08:43

well a task modifies the filesystem and the next task builds off that filesystem

micha17:08:50

the fileset yeah

flyboarder18:08:02

sorry fileset*

micha18:08:15

but like modifying source files is not really practical

micha18:08:22

or imho useful

micha18:08:35

we want to make better abstractions, not generate source

micha18:08:58

if we need to generate source files there's something wrong

alandipert18:08:20

still though ti would be possible if the generator output went into the fileset

alandipert18:08:34

the reason i love the idea is for template dev, i could use together with checkouts to live-reload code/update templates

micha18:08:40

like what would be an example of using it?

micha18:08:02

parsing source files and trying to infer stuff about them then modify them

micha18:08:06

that seems unsound

alandipert18:08:07

like as i'm making changes to the hoplon template, a generated project is continuously populating the target dir

micha18:08:29

we should make macros then

micha18:08:39

better ones

micha18:08:57

that seems to be the composable way to generate code

micha18:08:21

composable-ish

alandipert18:08:19

@micha are you responding to me or @flyboarder ?

flyboarder18:08:20

^ now im confused isnt that a task?

micha18:08:13

@alan you lol

alandipert18:08:20

i mean, a template is a program that makes some text files

alandipert18:08:29

all i want to do is see my text files update continuously

alandipert18:08:50

which i could do if new could optionally write to the fileset, then its output becomes like the output of any other compile step

micha18:08:05

ok but they're not just text files

micha18:08:09

they're programs

micha18:08:16

you're going to be generating code

micha18:08:30

i just don't see that being workable at all

flyboarder18:08:31

thats what the generators are for tho, generating code (templates)

alandipert18:08:46

so you think there is no value in having eg a hoplon simple template?

micha18:08:54

yeah kind of

micha18:08:05

i imagine the template generating a build.boot only

micha18:08:13

with dependencies and some tasks

micha18:08:25

the demo app being in a jar in clojars

alandipert18:08:30

that's what it does already

micha18:08:44

well currently it generates namespaces

micha18:08:52

which is where it gets dicey

micha18:08:59

liek how do you compose namespaces?

alandipert18:08:07

it shows people where they go

alandipert18:08:15

it's a starting point for a human, not a computer

alandipert18:08:29

it's a technical document generator basically, these templates

alandipert18:08:02

i agree that they are most valuable and good when they are small and show only the most important things

micha18:08:02

i can see that

micha18:08:14

like the things you compose are really orthogonal

micha18:08:19

they don't touch the same files

alandipert18:08:20

vs. the current trend toward massive ones that should be smaller and mostly library code that lives elsewhere

micha18:08:43

like the files generated by taskA and taskB are disjoint

micha18:08:25

if two generators modify the same source file, that's where i get skeptical

alandipert18:08:45

but i don't object to other people doing it

alandipert18:08:03

for me the fileset just closes the template dev loop

micha18:08:08

if we make new a boot option we could make it pretty good, usability-wise

micha18:08:26

boot --new ...

flyboarder18:08:18

@micha if people want to modify or compose a namespace or code itself that's what zippers are for

micha18:08:44

the program using the zipper can't understand the program though

micha18:08:54

all it sees is sexps

micha18:08:43

so yes it's trivial to generate sexps, i just don't see it being that useful to build programs that way

flyboarder18:08:45

but thats fine since it should be at the task level

micha18:08:05

there will always be tons of edge cases

micha18:08:24

if it sees a namespace that already has stuff in it, it can't know how to correctly modify it

flyboarder18:08:42

like boot —new shouldnt really worry about that

micha18:08:01

sure, it doesn't

flyboarder18:08:26

the templates that boot new generates should only be a onetime thing right?

flyboarder18:08:54

so its like the base starting point for the fs, then the project comes on top of that

flyboarder18:08:33

so maybe we should have a new file type of :template

flyboarder18:08:02

that would allow that layer to be swapped out by checkouts

micha18:08:06

i don't understand what the problem is we're trying to solve anymore

micha18:08:22

i thought you just use it to create some files

micha18:08:25

then you stop using it

flyboarder18:08:47

and alan suggested it be dynamic

micha18:08:04

in that case you don't need composition, you can just run it once for each egnerator

flyboarder18:08:06

so when a template changed the project was also updated

micha18:08:37

like if you're working on the template

flyboarder18:08:54

right and i have a running app based on the template

flyboarder18:08:00

the app would also update

micha18:08:08

i don't understand that

micha18:08:16

i guess you'd use boot-in-boot then

micha18:08:24

to runa new boot isntance or something

micha18:08:16

we should make a wiki page to decide what the functionality should be

micha18:08:04

i myself don't really use templates to generate projects, so i'm not really qualified to say what goes into boot for that

talexxx18:08:20

@micha I didn’t want to clobber the chat buffer. My build.boot is at https://github.com/talexand/hallo-color/blob/master/build.boot

micha18:08:40

bootlaces does a dumb thing, it adds "src" to :resource-paths by default

micha18:08:48

there is an option to disable that behavior

micha18:08:59

we should really make that the default, just haven't gotten around to it

talexxx18:08:20

Searching the boot docs for that option, but coming up empty

micha18:08:40

it's in bootlaces

micha18:08:50

it's the bootlaces function that's the problem

talexxx18:08:40

Am I biffing the function call? (bootlaces! +version+ {:dont-modify-paths? true})

talexxx18:08:49

java.lang.IllegalArgumentException: No value supplied for key: {:dont-modify-paths? true}

micha18:08:57

@talexxx look at the bootlaces function docstring

talexxx18:08:18

Found it in another repo

micha18:08:33

the best way to debug it is to look at the docstring though

talexxx18:08:40

That’s true 😄

micha18:08:40

whenever something like that happens

micha18:08:58

a lot quicker to find the problem 🙂

talexxx19:08:16

Isn’t the docstring supposed to be in quotes after the function signature?

micha19:08:11

if you do (doc adzerk.bootlaces/bootlaces) in the repl you'll see the arglist

micha19:08:49

your issue is the & {:keys ...} part

talexxx19:08:37

Am I in the wrong namespace?

boot.user=> (doc adzerk.bootlaces/bootlaces)
nil

micha19:08:18

sorry, it's adzerk.bootlaces/bootlaces!

micha19:08:32

with a bang on it

micha19:08:28

basically you want (bootlaces! +version+ :dont-modify-paths? true)

talexxx19:08:25

Ah I should have caught that

richiardiandrea19:08:34

I wonder if a port to JavaScript would be that hard

richiardiandrea19:08:59

yeah 😉 tooling should definitely go the JavaScript way

richiardiandrea19:08:08

I mean, it would be super fast to launch

richiardiandrea19:08:47

the only part that we can't convert is the repl I guess, but a java -cp .... can be super quick

micha19:08:01

i dunno if it would be faster in js

micha19:08:10

it's not the jvm that's the problem

micha19:08:17

it's the dynamic nature of clojure

richiardiandrea19:08:32

well if would speed up everything else (except the repl yes)

richiardiandrea19:08:42

boot startup time as well

micha19:08:51

you would have to give up vars

micha19:08:04

boot uses vars for many things

richiardiandrea19:08:32

yes you'd need some clojurescript-in-clojurescript for that, and no multi-threading I guess

micha19:08:51

if you have cljs-in-cljs and it provides the affordances of clojure, i think you'd be back where you started

micha19:08:02

just in nashorn instead of directly on the jvm

richiardiandrea19:08:37

yeah, planck does a very good job with cljs-in-cljs (but of course I haven't profiled anything)

richiardiandrea19:08:07

just wondering actually what could be achieved and if it is worth it

seancorfield19:08:50

(had a meeting… back to boot-new…)

seancorfield19:08:32

So, it sounds like there are three distinct use cases, two of which boot-new currently covers: generate a whole new project as a one-off; generate or modify some source code (as a starter for a developer, e.g., new controller in an MVC app, new source file / namespace, new function stub, new test, etc); then there’s the "generate stuff into the fileset as part of a composable build pipeline".

seancorfield19:08:16

That last case is not currently covered but could possibly be a valid thing for a generator to do — but not in the current form because the fileset is not passed into a generator and is not returned from the new task itself.

micha19:08:03

the generator wouldn't know or care about the fileset necessarily

seancorfield19:08:10

So, if someone wants that to be possible within boot-new then go create a GitHub issue for it. I think it’s an interesting idea but I don’t need it. If someone writes up what they want and provides guidance on how to do it, I’m happen to implement it.

micha19:08:13

it just gets a tempdir

micha19:08:21

and writes to a tempdir

seancorfield19:08:40

Right, but there’s no communication with the fs entity possible right now.

seancorfield19:08:52

Go look at the source to understand what I’m saying.

seancorfield19:08:39

The generator code does not do anything with the fs — it’s not used, not passed in. So a generator can’t write anything to the fileset as the code stands today.

seancorfield19:08:05

I’m not against enabling that — but I wouldn’t want to break any existing template / text-based generators.

seancorfield19:08:17

As for folding boot-new into Boot itself in some form, happy to work with @micha or whoever on what is needed there. In its current form, it’s easy to merge in as a built-in task (per the old PR — I think I could fairly easily create a new PR that followed that outline) but I’m not sure what additional work would be needed to wire it in as a —new option to Boot itself (because of all the additional options that the new task currently expects / requires)?

seancorfield19:08:17

(I’m also not sure what would happen to the existing generator functionality in such a model?)

juhoteperi19:08:43

Re: three use cases: I don't think they need to be solved by single task (boot-new), the third one can be solved by something else

flyboarder20:08:56

^agreed, i think the existing version works well for it’s intended use now that it has been explained, it seems like a good fit as an argument for a future version, i was trying to figure out where in boot the actual behaviour of the arguments is run

myguidingstar21:08:39

can someone help explain why Boot fails to compile this namespace? https://github.com/zcaudate/one.love/blob/master/src/one/love/command/ast.clj

flyboarder21:08:56

@myguidingstar: what is the error you are getting?

myguidingstar21:08:54

my guess is that it has problem with finding path and grepping for .class file manually. That will only work in Lein

myguidingstar21:08:21

@flyboarder Error compiling one/love/command/ast.clj

micha21:08:51

line number?

micha21:08:48

i'd comment things out until you can require the namespace in the repl

micha21:08:02

because there is no useful information about what could be going wrong

micha21:08:08

all you can do is bisect the problem

micha21:08:44

line 54 appears to be an empty line

myguidingstar21:08:12

sorry, it was 64:1. Actually I only use one.love as a library and didn't use Boot to check its source

micha21:08:44

the use of ~'args etc looks odd

micha21:08:51

usually you'd use a gensym there

micha21:08:59

to avoid name clashes

micha21:08:11

like args# instead

myguidingstar21:08:23

looks like the author wants deterministic macro expansion 🙂

myguidingstar22:08:12

he's trynig to find those java classes by looking for .class files in classpath (line #27). Is there a better way for that?

micha22:08:23

yeah line 17 is the problem there

micha22:08:06

a better way would be to get the classpath from a classloader, not from the system property

micha22:08:26

but then you need to choose which classloader, etc

micha22:08:08

you can probably prime the pump if you want

micha22:08:55

just get the classpath from boot and set java.class.path or something

myguidingstar22:08:07

you mean in Boot-powered projects that use the library, or shoud I change upstream source code?

micha22:08:18

oh this is your project?

myguidingstar22:08:48

just using it as a library

micha22:08:03

i don't really understand all the ins and outs of what is going on there

micha22:08:27

but setting java.class.path seems like a good start to get your project to work with it

myguidingstar22:08:09

well I want to use this library. It is reported to work in Lein-powered projects and not Boot ones

micha22:08:30

right because boot manipulates the claspath at runtime

micha22:08:51

lein starts a second jvm with java.class.path set with a value computed by the first jvm

micha22:08:52

ideally you'd be able to provide the locations of things on the classpath to the library maybe

micha22:08:17

like in boot it's very easy to get the jar file for a dependency

micha22:08:26

without regexes 🙂

myguidingstar22:08:56

do you have any suggestion for the approach to fix in upstream (as a library)?

micha22:08:29

would it be possible to have a function that you'd call to initialize it?

micha22:08:11

i guess the issue there is that it needs to find the rethinkdb-driver jar

micha22:08:14

on the classpath

micha22:08:00

it uses the java.class.path plus regex to avoid scanning the classpath

micha22:08:18

if you know the name of a class in the jar you could use reflection

myguidingstar22:08:12

(lemme research a minute, I never get a thing about java class...)

micha22:08:45

you would just need to know the name of one class in the jar

micha22:08:14

oh you have one

micha22:08:25

com.rethinkdb.gen.Datum

micha22:08:29

so you can do like

micha22:08:52

(.getClassloader com.rethinkdb.gen.Datum)

micha22:08:01

to get the classloader that has its jar loaded

micha22:08:09

then to get the path to the jar on the filesystem you can do

micha22:08:01

(.getResource cl "com/rethinkdb/gen/Datum.class")

micha22:08:06

where cl is the classloader

micha22:08:26

that will return a URL, which you can then string munge on the path to get the jar

myguidingstar22:08:32

I see. Thanks a lot

micha22:08:36

you probably will need to convert the path to a java Path object to get platform correct path

micha22:08:50

because URLs don't use backslashes

micha22:08:16

i guess +rethink-snippet+ probably doesn't work on windows anyway, so it can't be worse

myguidingstar22:08:08

hmm, that rethink-ast function is called only once to derive a constant one.love.command.ast/classes whose value is a map of pairs like {:set-insert com.rethinkdb.gen.ast.SetInsert, :to-geojson com.rethinkdb.gen.ast.ToGeojson ...}

myguidingstar22:08:07

I guess we can just hardcode the list [SetInsert ToGeojson ...]

myguidingstar22:08:16

b/c maven version is fixed

myguidingstar22:08:54

the original dynamic function can be kept and use when upstream upgrade

myguidingstar22:08:06

(kept as comment)

micha22:08:16

or as a boot task

micha22:08:36

you can generate an edn file or whatever

micha22:08:52

package it in the upstream library jar

micha22:08:21

then get it with like ( "one/love/thingy.edn")

myguidingstar22:08:51

haha, the boot way 🙂

myguidingstar22:08:20

gotta sleep now

micha22:08:36

good luck 🙂