Search results

Fronobulax, I think what you're seeing is that much of the code in /lib uses the jars. The jars are in the CLASSPATH for /lib, but not in the CLASSPATH for /src. You can see that in the current build.xml. I think that is why you see compile errors when you delete all the jars. When I try to...

Maybe we should make a new directory for jars that should be available at compile time? Feels better to me to make a generic solution.

This makes sense. My patch took approach 1. Approach 2 has been taken for some libraries already in Mafia. On 3, I am not sure why one would not want to add all the jars to the classpath; there may be reasons that I'm not seeing here. I don't think 4 is really feasible.

My build process is running ant clean && ant. Is there something else I should be doing?

Sure. Those tests: On a clean checkout with my patch + rhino jar, the build succeeds. On a clean checkout with my patch + rhino jar, and build.xml changes reverted, the build fails because it can't find any of the rhino classes. On a clean checkout with my patch + the rhino source, the build...

The old build process doesn't work because it just doesn't put anything in lib/jar into the classpath. That's what my build.xml changes accomplish. Happy to revert that and include source or make whatever changes you all want; not something I really have strong views on.

That goal makes sense to me, but the .classpath file was already included in the repo so I updated it. The action consistent with that goal would be to remove the .classpath file entirely.

My understanding, and please correct me if i'm wrong, is that the .classpath file played and plays no role in the build process. It is only there to assist editors' language support. I am a little confused about your question about build.properties, as there aren't any changes to that file in...

Thanks, MCroft. I've fixed that bug as well as a number of others in the attached patch, and I think I've improved the error handling substantially. I cut out the rhino jar this time as the transmission of the patch over the wire does not appear to have worked correctly for you. I think this is...

...and this one has the rhino jar included, at MCroft's suggestion, but is now too large to upload to the forums. Edit: Talked to MCroft offline, who could not successfully apply this, so I guess we're stuck on the previous patch.

Alright, as far as I can tell this patch applies cleanly with svn patch, along as you add the rhino jar to lib/jar manually. I'm going to test a little more, but from my perspective this should be ready to merge. On the build.xml issue, certainly open to other ideas. The modification just adds...

Alright, let's try this patch instead. Let me know if you have trouble with this one (you'll still have to add the rhino jar manually).

Hm, let me figure this out - I am only using git-svn since I want some form of source control outside the repo, and it's not my usual workflow. It seems like the two mechanical issues here that didn't apply cleanly are renaming Interpreter.java to AshRuntime.java and adding rhino-1.7.13.jar to...

Most of the major features are working now. I've updated the github PR linked in my first post, and I've updated the attached patch.

To be clear, support for that is certainly possible! I am just focused on getting the basic stuff working right now.

That is one way you could use it, but I envision this being broader: that you could write all the scripts you currently write using ASH with JS instead. So you could, for example, write your daily meatfarming script in JS. Does that make sense?

Oh, I assumed that meant what Ryo had mentioned: scripts triggered via events in Mafia like the betweenBattleScript etc.

I think maybe we've gotten a little distracted by the discussion on bundlers? I think your overall understanding is correct, fronobulax. This patch is a first attempt at making JavaScript a second option for writing scripts for Mafia. Eventually, I'd like to have all avenues for executing ASH...

Yeah, my intent was to submit a single patch to be merged - the github PR is just so people can use that UI to review changes if they wish. Ryo, thanks for the suggestion on the naming. I'll do that. Gausie is correct that lifecycle scripts are not currently supported but certainly could be...

Apologies for not explaining. JS bundlers (webpack being the most prominent one) package a script with all of its dependencies into a single file that can be run in e.g. a web browser without installing any of those dependencies. The idea is that the user doesn't need to know anything about the...