Feature Support for scripting in JavaScript

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?
 
ikzann said:
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?
Click to expand...

Yes, it makes sense.

Maybe I should have pushed harder for BeanShell years ago :-)
 
ikzann said:
It does not support any module system right now, and I don't think that is a high priority given that folks could bundle scripts using an off-the-shelf bundler (maybe even Babel!) and distribute the bundle. As a comparison, that is how Guide is distributed in the ASH world.
Click to expand...

Me sad. Though it's understandable, since importing/exporting modules in JavaScript have been a tricky problem for decades.

Still excited to see this happen. Many features we wanted but ASH didn't have could be complemented from numerous JavaScript tools and libraries out there. We could use HTML parsers and logging frameworks written in JavaScript.

It would help script writers, too. Unit-testing our scripts? Linting and formatting? Proper IDE support? YES.
 
To be clear, support for that is certainly possible! I am just focused on getting the basic stuff working right now.
 
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.
 
I took javascript-v1.txt from the first post, used svn to apply it as a patch and the patching seemed to work mechanically.

Getting lots of errors most of which seem to be

class AshRuntime is public, should be declared in a file named AshRuntime.java
package org.mozilla.javascript does not exist

Poking around I think the issue is the patch mechanics.

Perhaps you could try a different way to make the diff or give me some idiot proof and detailed instructions to get what I need from GIT using SVN and doing so in an easily revertible manner?
 
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 lib/jar.
 
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).
 

Attachments

Thank you. My patch utility doesn't know what to do with AshRuntime. I guess we just wait until I can figure things out. Keep working. My ability to install you patch is not a problem as long as some one else can/does.
 
I also tried applying the patch, via copying -v2.txt to the clipboard and using IntelliJ's "Apply Patch from Clipboard." command. No reported errors, but it deleted interpreter.java instead of renaming it AshRuntime.java. This was in my "clean copy" directory, updated to R20500

I will see if I can recover from that state.
 
It's missing a bunch of files. It's like the patch has modifications, but not added files. For instance (and causing build failure after repairing AshRuntime), it didn't create the textui/javascript directory at all.

Can you try again, and apply your patch to a clean svn directory to assure it works? If so, can you document how you applied it?

Also, I noticed that build.xml and build.properties are in the changeset. I am not proprietarily attached to those files, but it's usually not necessary to change them and it takes some coordination to make sure that nothing is broken for Mac, Unix, Windows and Automation builders.
 
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 the jars in lib/jar to the classpath for building.
 

Attachments

...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.
 
Last edited:
Applying the v4 and manually downloading rhino from the apache project allows me to do the following successfully:

Code: 
mkdir KM-clean
cd KM-clean
svn co --username=madcarew svn+ssh://madcarew@svn.code.sf.net/p/kolmafia/code/ .
svn diff
svn patch ~/Downloads/javascript-v4.patch
cp ~/Downloads/rhino*.jar lib/jar
ant daily
java -jar dist/KoLmafia*.jar

My only test case is js Monster.get("zombie").name, which unfortunately comes back with Unexpected error, debug log printed, but the log shows it's definitely trying the JS engine. The more correct js Monster.get("zobmie").name is successful.

It's promising, and needs polish. Error handling/robustness, documentation, license info, more js ref info in the gCLI (maybe a way to print the DOM), and probably some examples of how to use it. It might, for instance, give a workaround for the error in another thread with XPath (or create 2 problems, but at least it's an option).
 
Last edited:
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 at the point I'd like to get this merged; the patch is starting to get out of control in terms of size. If that makes sense to folks, further improvements can be handled in separate patches. I also expect that people who start developing against this will find bugs fairly quickly! I will write further documentation on it later this week, and I'm happy to take any further suggestions.

The brief summary of the API is this:
  • The ASH runtime library can be accessed via the global Lib, with each runtime library function attached to Lib as the camelCase version of its ASH self. For example, you can get your moods via Lib.getMoods.
  • Enumerated types can be accessed via <Type>.get and <Type>.all. get takes a single number/string or a list of numbers/strings, and all takes no arguments. So, for example, Monster.get(33) returns zobmie, and Item.all() returns a list of all items.
Putting these together, you can do things like adventure in NEP with Lib.adv1(Location.get("The Neverending Party"), -1, "").

Consult scripts and combat filter functions are not currently supported, although you can of course still write a consult script in ASH. I don't expect this to be terribly hard to add so that will probably come soon. The patch also does not currently support relay or relay override scripts.

I've attached a test script, "pizzable.js"; you can call it with "pizzable <letter>" to get the list of pizzable items for that letter.
 

Attachments

I can't look at this now but it is on my list.

Suggest we defer committing anything until @Veracity has no concerns about when it gets added compared to the next release.

Someone using a svn client should be able to put the rhino jar in lib/jar, do a svn add and then it will be committed.

Might be worth checking the size of the KoLmafia jar file after.
 
build size, + 439K, which is really interesting, since Rhino.jar is 1315934 by itself:
Code: 
Michaels-MBP:KM-clean mcroft$ ls -l dist
-rw-r--r--  1 mcroft  staff  18108383 Nov 15 12:19 KoLmafia-20500M.jar
Michaels-MBP:KM-clean mcroft$ ls -l ../kolmafia/dist/*.jar
-rw-r--r--  1 mcroft  staff  17669143 Nov 11 22:36 ../kolmafia/dist/KoLmafia-20.7.jar

I can commit it; I have the -v4 (and can have -v5), when we're ready.

Would this be a good place to create a feature branch? That way we could get it into SVN/get other devs the ability to play with it/get it buildable for people without landing it
 
OK. I got the patch to apply and modified the build to something that I understood and worked for me. I ran the pizza example so something is different :-)

I am very concerned abut the formatting of the patch file. In SVN a well formed commit can be reverted and will delete new files and directories when reverted. That did not work for me and the next compile after revert was broken because of files that lingered. SVN has an add command and IIRC using it to add files and directories and then making the patch is the preferred process.

Tangentially I am not a fan of a feature branch but that may be because I have never worked in environment where they solved more problems than they created. Separate discussion if needed.

My recommendation for the way ahead with this:
  • Resolve the build conventions and apply those to the next patch.
  • Produce a patch that will compile, the result can run the pizza script, and the patch can be reverted.
  • Have one or more current devs review code for adherence to style standards, to the extent they exist, and run "lint" equivalent and resolve issues.
As penance for my misunderstandings I can have a set of files sent to me and build a revertible patch file.

I don't want to do the code review alone - too many files - but I am willing to check a few. I am OK with committing things un-reviewed and having people coordinate the checking efforts.
 
Thanks, frono, and thanks for all the review you've done so far. Here's a patch that has rhino in a src/jar/ directory (placing the jar still needs to be done manually). Can split this up into a sequence of patches if you'd like, but i suspect it would be easier for someone with commit access to do so when we are actually ready to commit.
 

Attachments

You must log in or register to reply here.
Back
Top