Search results

A few appetizers while we wait for the rest: - The classes CompositeType, CompositeValue and AggregateValue should be made abstract. - The method CompositeType.getDataType( Object ) can be made abstract. Additionally, its parameter can be turned into a Value (which cascades into doing the same...

I think we should put this aside for now, like parsePostCall. Mainly, because IIRC, boolean Type.equals(Type) is used to find *that exact* type (because we'll end up having to find types/variables/functions in Scopes' TypeList/VariableList/FunctionList, to fetch their references/definition...

@heeheehee this patch only changes/adds generics.

I tried to find a somewhat rare modifier filter that would give more than one result, since I wanted to include multiple columns in the test (since "sporadic" gave both "sporadic meat" and "sporadic item")

The thing is... there isn't any nondeterministic I/O to separate. What the code was previously doing was transitioning from an array to a List (making a List the length of the array, and iterating over the array to populate the List) Now, since the method expects a List, the part is just...

I can apply this patch to a fresh repo successfully. Do you have local changes? Could you tell which file it hangs up on?

@heeheehee N.B. the test will fail until https://kolmafia.us/threads/syntax-error-in-modifiers-txt.26400/ is committed (...or unless you apply it locally).

Expression syntax errors for 'Ensorcel:slime': Expected end, found )

@heeheehee the only non-generic change here is a transition from final Offering[] buffs; for ( int i = 0; i < buffs.length, ++i ) { [...] buffs[ i ] [...] } to final List<Offering> buffs for ( Offering buff : buffs ) { [...] } Does that really mandate a test? 🥺 Really...

@heeheehee Same problem, opposite cause. This time, the method to test is too close to the end user. The method to test is void move( final List<AdventureResult> moving, final int sourceShelf, final int destinationShelf ), whose only action is to do RequestThread.postRequest( new...

@heeheehee not only is it just generics, there's already a test for that one :p

@heeheehee Adds the test skill add <id> and test skill remove <id> commands. The tests add skills, checks the output of the skills command, then with a filter, than removes the added skills (and makes sure the skill list is empty). That last part is important. KoLConstants.availableSkills being...

@heeheehee I can't... really... add tests... to that one... All of the parts that were changed base themselves off of KoLConstants.availableSkills, which is an empty list during tests, and can't be modified manually... Other than that, the file's still up to date ( ._.)

For the patches that come with logic changes, sure, but is it also necessary for those that only add generics? Type erasure and all that.

Tried to help https://kolmafia.us/search/103991/

that, or "1" shouldn't be using basedir="${build}"

source: <target name="jar" depends="compile"> <jar destfile="${build}/bundled-libs.jar" basedir="${build}" update="true" index="true" compress="true"> <zipgroupfileset dir="${lib}/jar"> <include name="*.jar"/>...

For the error message, maybe it could be more like "Existing type expected for function parameter"?

That *does* seem interesting... If we were to look into the future, at a point were it was possible to coerce records, one may want to make a method where they have something like record foo { string a; int b; float c; } record bar { string a; item d location e...

Well, a record "is" a type, so it would just be "Record definition"