gradle, 10 9 bytes
for(;;){}
with the above code placed in a build.gradle
file. Gradle uses groovy as its base language so we are really talking about groovy here, but as the question was about build time I figured gradle would be more appropriate.
Running any gradle build commands with the above code prints the pointy-haired-boss-compatible build status line:
$ gradle tasks
> Configuring > 0/1 projects > root project
if you are aiming for a raise, add the debug -d
flag for:
$ gradle -d tasks
14:56:25.522 [INFO] [org.gradle.internal.nativeintegration.services.NativeServices] Initialized native services in: .gradle/native
14:56:25.757 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Executing build 84908c0d-f28d-4c57-be61-40eaf0025e16.1 in daemon client {pid=27884}
14:56:25.761 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface tun0
14:56:25.762 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a loopback interface? false
14:56:25.762 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a multicast interface? false
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x:x:x:x:x:x:%tun0
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x.x.x.x
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a loopback interface? false
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a multicast interface? true
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x:x:x:x:x:x:%eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x.x.x.x
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote multicast interface eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface lo
<snip>
14:57:07.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
> Configuring > 0/1 projects > root project
which in addition to looking impressively complicated also updates with a new set of:
15:07:57.054 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
15:07:57.054 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:07:57.054 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
status lines every 10 seconds making it look like the build is busy doing important technical...stuff.
1@obarakon I disagree. Code from the other challenge cannot be ported to this challenge with any ease. The challenges while the both involve infinite looping are fundamentally different. – Post Rock Garf Hunter – 2017-02-16T01:22:08.857
1
@obarakon Not a dupe of this question either, as it's not code-golf.
– Esolanging Fruit – 2017-02-16T01:24:33.5702Related – Post Rock Garf Hunter – 2017-02-16T01:25:11.097
Does JIT compilation count as compilation? – Downgoat – 2017-02-16T03:19:33.223
@Downgoat I'd say so. – Esolanging Fruit – 2017-02-16T03:29:14.927
Related – R. Kap – 2017-02-16T05:23:56.447
Are answers valid which terminate eventually because the compiler runs out of memory/recursion depth? – Martin Ender – 2017-02-16T08:43:34.487
@MartinEnder Yes, edited. – Esolanging Fruit – 2017-02-16T08:47:33.270
1
I'm not sure it fits this challenge (and even if it does it would score terribly), but for those interested here's how I would do it in
– Aaron – 2017-02-16T09:59:48.443Java
: define an annotation processor(ideone snippet) which you'll use when invokingjavac
with its-processor
option. It makes the compilation of any class hang forever.@Aaron there's shorter in vanilla Java 5+ without any custom annotation processor ;) – Olivier Grégoire – 2017-02-16T12:19:03.817
6For the answers that result in crashing the compiler: For the purpose of slacking, I would think you still want it to take as long as you can to crash. – GuitarPicker – 2017-02-16T17:43:47.707
1
If you want something minimal to tie up your printer as long as possible, try sending instructions to generate the mandlebrot set to your printer: https://www.mitchr.me/SS/exampleCode/postscript/mandelbrot.ps.html
– rjmunro – 2017-02-20T12:14:57.907Must the implementation exist before this question? – PyRulez – 2017-06-27T00:52:35.970
@PyRulez Yes, as is standard with code-golf. If it did not, you must mark your answer as non-competing. – Esolanging Fruit – 2017-06-27T06:22:57.520