Bug - Fixed 10033 broken??

Winterbay

Winterbay

Active member
Yep, it appears that anything above 10032 is not fully there due to, most likely, a compiling error somewhere along the line.
 
S

slyz

Developer
The problem seems to be the import added in net.java.dev.spellcast.utilities.ActionPanel:
Code: 
[javac] D:\dloads\KoLMafiaUpdates\kolmafia\lib\net\java\dev\spellcast\utilities\ActionPanel.java:44: package net.sourceforge.kolmafia.swingui.listener does not exist
[javac] import net.sourceforge.kolmafia.swingui.listener.ThreadedListener;
 
S

shoptroll

Member
Would it be possible to do a fork build for all the back-end changes schwei has been making? No offense, but checking in code that doesn't compile is incredibly sloppy (I know I would get yelled at for something like this at my day job) and I've noticed that the stability of the application's daily builds has decreased a bit since a lot of the changes for Java 6 compatibility and multi-threading (based on the commit changes) have started. I know this is part of the risk with daily builds, but I expect a number of people use dailies for support with new content as opposed to back-end features.

tl;dr: Has there been any consideration of an "experimental" branch for sandboxing new features or architectural changes?
 
Veracity

Veracity

Developer
Staff member
wrldwzrd89 said:
As I suspected... there's LOTS of compile errors that somehow weren't noticed when building.
Click to expand...

I imagine they "somehow" weren't noticed because they didn't happen on hola's machine, since his view had the new file that he forgot to add to svn. I've sent him e-mail. I expect he'll check in the file, by and by.

mad dudy said:
i would like to note that r10038 also don't work
Click to expand...

Why would you like to note that? Considering that the file missing from 10033 hasn't been checked in yet, that is completely expected.

shoptroll said:
No offense, but checking in code that doesn't compile is incredibly sloppy.
Click to expand...

I'm sure that you've never created a new file and forgot to check it in to version control. Especially when there are 80 other existing files with changes in them, as part of the change set.

Yeah. Incredibly sloppy.

Sheesh.
 
Last edited:
G

GValko

Member
So that people realize that the problem is ongoing with the more recent compilations, and that downloading them won't fix it?
 
S

shoptroll

Member
Veracity said:
I'm sure that you've never created a new file and forgot to check it in to version control. Especially when there are 80 other existing files with changes in them, as part of the change set.

Yeah. Incredibly sloppy.
Click to expand...

I'm not trying to pick an argument or anything, I'm just saying that in my opinion the amount of architectural change going on seems like something that should be done in a separate branch of the project instead of in the main trunk. I completely understand that mistakes happen, and this is your show not mine.

Just trying to make a helpful suggestion here.
 
S

slyz

Developer
Veracity said:
Considering that the file missing from 10033 hasn't been checked in yet, that is completely expected.
Click to expand...
I'm not sure there is a file missing: src\net\sourceforge\kolmafia\swingui\listener\ThreadedListener.java already exists.

It looks like importing "net.sourceforge.kolmafia.swingui.listener.ThreadedListener" from lib\net\java\dev\spellcast\utilities\ActionPanel.java isn't working for some other reason.

I'm completely lost as to why (this is when it becomes obvious that I am not a programmer). I tried importing "src.net.sourceforge.kolmafia.swingui.listener.ThreadedListener" instead, but that doesn't work either. Should something be updated in .classpath or some other build file?
 
G

Grotfang

Developer
Just had a quick look, but I think the problem is that we compile lib before src. The package doesn't exist as far as the compiler is concerned at the point of compiling the lib classes (hence the 13 errors there). When we then compile the src classes the 100 errors generated are a result of not having compiled lib.

build.xml lines 154-160:

Code: 
		<antcall target="compile-folder">
			<param name="folder" value="${lib}" />
		</antcall>

		<antcall target="compile-folder">
			<param name="folder" value="${src}" />
		</antcall>

I don't really understand the reasons why lib and src are separate, so I don't want to be the one to merge them. However, I believe that might resolve the issue. Would that mess anything up? The alternative would be to replicate the ThreadedListener file within lib.
 
fronobulax

fronobulax

Developer
Staff member
Ask hola. Until he answers, my understanding was that they were separated because lib contains code that was borrowed by or imported into KoLmafia whereas src contains code written by the dev team for KoLmafia. Since src references lib and lib references src I don't think compile order is going to change anything. Given the separation criteria I think the core problem is that something in lib requires src to compile. Not knowing why things were done, I would refactor things so that lib could compile when src was not present. IMHO. YMMV
 
Captain Kirk

Captain Kirk

Member
Problems compiling on macosx -- this is version 10039

I haven't compiled for a while, but I got these errors during compilation on MacOSX java 1.6.0_29, apologies if already posted somewhere else.
Seems to have started with 10033 (13 errors) and got worse from there.
View attachment compile_errors.txt
 
Last edited:
holatuwol

holatuwol

Developer
Erk, forgot that the packages were separated and was doing start compile instead of clean compile so I never saw the compile errors. Will work on a fix.

fronobulax said:
Since src references lib and lib references src I don't think compile order is going to change anything. Given the separation criteria I think the core problem is that something in lib requires src to compile. Not knowing why things were done, I would refactor things so that lib could compile when src was not present. IMHO. YMMV
Click to expand...
Update: This is what happened. Should be fixed in 10040.

Grotfang said:
I don't really understand the reasons why lib and src are separate, so I don't want to be the one to merge them. However, I believe that might resolve the issue. Would that mess anything up? The alternative would be to replicate the ThreadedListener file within lib.
Click to expand...
To answer this particular question, the reason they were separated is because people were having trouble compiling (there's a lot of files to compile and by default, Ant runs out of memory) and they didn't want to have to change their ANT_OPTS. So, I thought separating KoLmafia code from third party library code would help reduce the number of files since nothing native to a third-party library will depend on anything in KoLmafia.

What caused this fiasco was that I started customizing third-party library code to depend on KoLmafia code, forgetting that I'd separated the two in the build process and that the separation matters if you do 'ant clean' instead of 'ant start'. My bad, don't hurt me, I'm just trying to help! ;)

Update 2: To prevent people from downloading bad builds, 10042 prevents the jar-building process from running if compilation at any stage fails.
 
Last edited:
You must log in or register to reply here.
Top