Conversation

Notices

1. Embed this notice
   mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:22 JST mcc

   This code tutorial tells you which lines to add to your build script to import the library, and tells you what classes to use, but does not tell you what imports to use to get the classes into scope *starts throwing things*

   • Embed this notice
     Jonas Wisser (jwisser@wandering.shop)'s status on Saturday, 18-Feb-2023 15:25:17 JST Jonas Wisser

     in reply to

     • halcy​:icosahedron:

     @halcy Inspired by @mcc's earlier post, I decided to try to compile Tusky with https://www.heap.io installed, 'cause hey, that's my day job.

     What I like about Android Studio's compile-time errors is that they're concise and actionable.

     clacke likes this.
   • Embed this notice
     halcy​:icosahedron: (halcy@icosahedron.website)'s status on Saturday, 18-Feb-2023 15:25:18 JST halcy​:icosahedron:

     in reply to

     • Jonas Wisser

     @jwisser @mcc from my experience trying to get to work and debug and profile tflite models recently, it at least is also poorly if at all documented, so that’s neat

   • Embed this notice
     Jonas Wisser (jwisser@wandering.shop)'s status on Saturday, 18-Feb-2023 15:25:19 JST Jonas Wisser

     in reply to

     • halcy​:icosahedron:

     @halcy @mcc iOS development can be a pain in the ass but it really is an orders-of-magnitude difference when it comes to Android. It feels like at every possible fork in the road, Google selected the option labeled "MOST CONFUSING FOR NO GOOD REASON".

     Even Android Studio itself feels like the platform is actively flinging feces at your face while you try to build for it. It's just… _inexplicably_ bad.

   • Embed this notice
     halcy​:icosahedron: (halcy@icosahedron.website)'s status on Saturday, 18-Feb-2023 15:25:20 JST halcy​:icosahedron:

     in reply to

     @mcc i did android development in university once and that is what convinced me to buy an iphone (i don’t know if iOS development is any good but at least I don’t know for sure that it‘s terrible)

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:21 JST mcc

     in reply to

     Every day I do Android development is a bad day

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:22 JST mcc

     in reply to

     Update: Android Studio is now informing me it cannot find "the file".

     What file?

     Meh

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:29 JST mcc

     in reply to

     • XaiaX

     @XaiaX Generally, yes. And if you choose not to use Java (use ndk or kotlin), you still have to deal with the java toolchain/ecosystem, which is generally the "bad part" of Java anyway.

     clacke likes this.
   • Embed this notice
     xaiax@mastodon.social's status on Saturday, 18-Feb-2023 15:25:31 JST XaiaX

     in reply to

     @mcc I’ve never done android dev. Does it involve Java?

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:33 JST mcc

     in reply to

     What I think was happening here

     - There is a tab in current Android Studio, "Build Analyzer", and they moved the full gradle logs (such as would allow you to debug an error in your build.gradle) there

     - However if the failure in build.gradle occurs "too early", for example if there is a toplevel variable def which throws an exception, then Build Analyzer does not appear

     - Shrug emoji the size of the moon

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:33 JST mcc

     in reply to

     Looks like this is still not fixed.

     A "cool" thing about building for Android is that if there is an error in your gradle script, the backtrace doesn't show where in *your gradle code* the error occurred, instead it shows where in the Java code of the gradle executable you can find the place where the error is printed out.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:34 JST mcc

     in reply to

     My hatred for Android Studio only grows every day. The only program I hate more, I think, is git, which makes today's problem, *which is about the interaction between Android Studio and git*, all the more infuriating

     (Android Studio is failing because it is invoking git, which is not installed, and I cannot fix the problem because Android Studio cannot tell me why it is invoking git. Humiliatingly, I have lost an entire workday to this.)

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:34 JST mcc

     in reply to

     Incidentally, re: the problem here https://mastodon.social/@mcc/109842751686859648 where it appears(?) to be cutting off the stacktrace before actually telling me where in my code the error is occurring, it turns out there's a --full-stacktrace option if you use the Gradle command line. --full-stacktrace causes it to print out *slightly more* of the stacktrace, but not the full stacktrace or even enough to identify where the problem is occurring

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:37 JST mcc

     in reply to

     • Dieu

     @hllizi However in this case, the Java part of the problem was actually very easy to fix. The problem was that I lost literal hours trying to figure out how to get the Android tool chain to tell me on what line the Java error was occurring.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:38 JST mcc

     in reply to

     • Dieu

     @hllizi I neither like nor hate Java. It's just there.

   • Embed this notice
     Dieu (hllizi@hespere.de)'s status on Saturday, 18-Feb-2023 15:25:39 JST Dieu

     in reply to

     @mcc one of the things you like, I suppose?

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:40 JST mcc

     in reply to

     Okay. The problem is solved. The problem is org.gradle.process.internal.ExecException is not an Exception, it is an Error, and it was escaping my try { } catch (Exception e) { }. This is a rookie mistake I should not have made, but in my defense, somehow the same basic code was throwing a different exception during `gradle sync` than it was during `gradle build` (?!), so since the try { } worked in sync I assumed the problem had to be some other git invocation somewhere else I had not yet found

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:40 JST mcc

     in reply to

     Java !!!

   • Embed this notice
     Dieu (hllizi@hespere.de)'s status on Saturday, 18-Feb-2023 15:25:42 JST Dieu

     in reply to

     @mcc But Kotlin is there, too, and it has type inference. ? Upside for me: don't have to use either. Downside for me: have to use PHP.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:43 JST mcc

     in reply to

     • Dieu

     @hllizi I should clarify at this point I am not using Java. I am using Kotlin, or more specifically, I am writing a "Groovy" build script for a Kotlin app. But the Exception/Error distinction comes from the JVM, not either of these things.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:44 JST mcc

     in reply to

     Final update: The note about ExecException above is wrong. The problem was that, somehow, during some stages of build, gradle/Android Studio were executing the wrong version of the code. I thought that changing "Exception" to "Throwable" had fixed it, but in fact what fixed it was making a change (any change) to build.gradle in Android Studio. Renaming "git" to "lit" also fixes the problem, in testing. This somehow does something a gradle sync & clean build didn't.

     Android Studio is TERRIFYING.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:45 JST mcc

     in reply to

     …no…no, no it's not over. It's even stranger and more unfathomable than I thought.

     On the first build after checkout, clean, git clean, or any change to build.gradle, it works.

     On the *second* build, it fails, with an exception that's clearly, unambiguously, inside a try-catch that should catch it. Catching "Throwable" instead of "Exception" doesn't help. This is the Terminator Exception, it can't be caught, it can't be stopped, and it only flags on every *other* build.

     In the *build script*.

     clacke likes this.
   • Embed this notice
     dfug (difegue@kolektiva.social)'s status on Saturday, 18-Feb-2023 15:25:50 JST dfug

     in reply to

     @mcc I picked up android development for the first time in nearly a decade and I am absolutely hating it

     What a nice thread to accidentally stumble upon as I open my socials ha ha ha ??

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:51 JST mcc

     in reply to

     What an infuriating, miserable loss of a day this was.

     I have a reproducible build failure that I can *only* explain if there is a bug in gradle.

     Trying to make a minimal test case, I make a new Android Studio project and copy all apparently relevant bits from the gradle file. The bug doesn't reproduce in the new project.

     I think I need to file a bug and move on, but I can't make a minimal test case, so they'll probably disregard my complex test case— and maybe they should! I dunno!

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:57 JST mcc

     in reply to

     It's fixed! And it wasn't a Gradle bug! It's just *even more cursed than I could have possibly imagined*!

     Another Tusky contributor found the solution:

     https://github.com/mcclure/Tusky/pull/1/files

     When you call providers.exec {} to call a command line file, this *looks* like a function, *but it isn't*. It's a "task", which is some Gradle thing, and it's *expected* to fail the whole build instantly instead of throwing an exception.

     You have to *request* an exception, with flag
     executionResult.rethrowFailure()

   • Embed this notice
     Avi Drissman :vm: (avidrissman@mas.to)'s status on Saturday, 18-Feb-2023 15:25:57 JST Avi Drissman :vm:

     in reply to

     @mcc If you stare into the void long enough it will sometimes throw an exception back.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:25:58 JST mcc

     in reply to

     I'm now considering unbelievably cursed, haunted possibilities like maybe Android Studio is caching state in %APPDATA% and the bug will maybe refuse to express in another directory. I haven't specifically tested this yet (one of the most frustrating things about this bug is that every test is incredibly slow, since part of the repro is… to do a non-incremental build).

     EDIT: That wasn't it

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:00 JST mcc

     in reply to

     • Paul Lalonde

     @Flux I would also really, *really* like to not wind up expending a second day on this, especially since this was supposed to be a "break" day— I decided instead of working on my "real" project today I was gonna do some work on Tusky's video player. Which never got started because instead I've been fighting with Gradle…

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:01 JST mcc

     in reply to

     • Paul Lalonde

     @Flux I guess, but I actually don't believe it's my bug at this point.

   • Embed this notice
     Paul Lalonde (flux@wandering.shop)'s status on Saturday, 18-Feb-2023 15:26:06 JST Paul Lalonde

     in reply to

     @mcc sleep on it. That's my answer for most of these.

   • Embed this notice
     4am ❧ (a2_4am@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:12 JST 4am ❧

     in reply to

     @mcc "ExecException is not an Exception" makes me long for the simplicity of assembly language.

     clacke likes this.
   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:13 JST mcc

     in reply to

     • Roy Adams

     @roytoo it sincerely feels sometimes like my time spent on Android dev lifetime has been about 50% writing software and 50% just trying to make the damn thing build

     clacke likes this.
   • Embed this notice
     Roy Adams (roytoo@mstdn.social)'s status on Saturday, 18-Feb-2023 15:26:15 JST Roy Adams

     in reply to

     @mcc
     Ugh I sympathize. Tooling issues like this are such a pain

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:16 JST mcc

     in reply to

     • signal eleven

     @widr Mercurial

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:16 JST mcc

     in reply to

     • signal eleven

     @widr I have a plugin that lets me push to and from git repositories despite not using git. But then Android Studio tried to query the git repo. And there *was* no git repo.

     clacke likes this.
   • Embed this notice
     signal eleven (widr@hachyderm.io)'s status on Saturday, 18-Feb-2023 15:26:23 JST signal eleven

     in reply to

     @mcc what do you favor for source control if not git?

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Saturday, 18-Feb-2023 15:26:24 JST mcc

     in reply to

     • a pale slim ghost

     @apaleslimghost **narrowing eyes** the file specified

     clacke likes this.
   • Embed this notice
     a pale slim ghost (apaleslimghost@cathode.church)'s status on Saturday, 18-Feb-2023 15:26:29 JST a pale slim ghost

     in reply to

     @mcc oh riiiiight, the file, the file for tusky, the file specifically meant for building tusky, tusky's file. that file?