Clojurians Log v2

malabarba: yes, I use it like that quite often

malabarba: Sometimes I get troubles on bad wifi because adb tunneling is lost often

Also, if phone is not connected to USB, and when it goes to sleep-mode, REPL ops become terribly slow. But it is solved by using (neko.debug/keep-screen-on) in all activities, which is itself a useful thing to do

Trying it out now

malabarba: (neko.debug/keep-screen-on this) to be precise

Yes, I just have that in all my activities by now

Seems to be working. :)

Were the slow repl commands your problem?

My problem was that I just hadn't tried it :)

I just thought of asking about it last night

I'm gonna try to get everything running now, and then isolate that issue I was having with skummet

Sounds good

alexyakushev: https://www.refheap.com/106689 Just so you know, this is the exception I get while dexing with summet.

It does not happen on the sample project

I'll start dissecting my project now, just figured I'd show you the exception in case it was something obvious.

You are using a support library, right?

yes

via dependencies

This error happens when dx is passed two sources with the same classfile

I don't know why skummet can be to blame here. So you can't build the regular version of this project alright?

The regular version builds fine

But this is a nastily complicated project

Try running with DEBUG=1 and see which jars and directories are dexed

Then try to figure out where the duplicated class might be coming from

It's a Java class, so it can't really come from skummet or its results. Must be some other clash

Going home now, then I'll start on that

Thanks for the tip

No problem

Is the Android build tools version supposed to match the sdk version?

The dexing command being used here is android-sdk/build-tools/22.0.1/dx

Eeh... nobody knows

Usually it's good to use the latest version of build-tools

Until they break something, and people stay with the previous version

Hehe

I'll try downgrading to 21

Yay, found the issue.

It's indeed the support libray

Just adding the dep that uses the support library is all it takes to trigger the issue

It's odd that it only happens with skummet though

Does this look like a plausible dependency vector for the :lean profile? `

`

:dependencies ^:replace [[org.skummet/clojure "1.7.0-RC1-r2" :use-resources true]
                                        [com.jeremyfeinstein.slidingmenu/library "1.3" :extension "aar"]
                                        [neko/neko "4.0.0-alpha1"]]

Looks fine. What's in the second dependency?

It's the dep that's causing the problem

I know what's going on

This dep probably pulls a support library dependency

And then lein-droid adds an explicit support library dependency

This lib pulls the support library from Maven while lein-droid adds support libraries to the classpath from Android SDK dir

That makes sense. Thanks for the help Alex.

Sorry for vanishing like this, something came up here

I still need to figure out if I want this lib anyway. Sadly, it just looks like I don't have much of an option.

Everything stems from the fact that lein-droid magically adds dependencies from Android SDK

This sucks

If one day we get AAR support, things will become much much easier

I could look into that. Those are just jar files with assets, no?

I suppose so

But then you have to somehow unpack the resources out of the archive to be able to pass it to aapt

Just ftr, adding com.android.support/support-v4 to the :exclusions and then using :support-libraries ["v4"] indeed solves the problem

Good to know