ZLib -- Zarqon's useful function library
- Thread starter zarqon
- Start date
zarqon
Well-known member
r16 Update
Added one more list function:
boolean list_contains( string list, string needle [, string glue] )
List is the string list to check. Needle is the entry you're checking for. Glue is optional and defaults to ", ".
Why would you need this function, when a simple contains_text() will find the presence of a string in another string? Well, consider the list "merecat, dog, weredog". Does that contain the entry "cat"? Nope. However, according to contains_text(), it does. This function uses a matcher and checks for glue or sol/eol on either end of the search string.
Also included the WOSSMAN in the ZLib repository. Thanks to ASH's somewhat obscure to_json() function, I managed to finally get it working with all data types. For now, I'm still considering this an undocumented feature of ZLib rather than the officially supported method of editing settings.
One nice side effect: as I've been spending more and more time making relay scripts, it will be helpful to have the jQuery library included in ZLib's repository, rather than duplicating it in each repository that uses it, which can lead to problems when uninstalling a single script.
Added one more list function:
boolean list_contains( string list, string needle [, string glue] )
List is the string list to check. Needle is the entry you're checking for. Glue is optional and defaults to ", ".
Why would you need this function, when a simple contains_text() will find the presence of a string in another string? Well, consider the list "merecat, dog, weredog". Does that contain the entry "cat"? Nope. However, according to contains_text(), it does. This function uses a matcher and checks for glue or sol/eol on either end of the search string.
Also included the WOSSMAN in the ZLib repository. Thanks to ASH's somewhat obscure to_json() function, I managed to finally get it working with all data types. For now, I'm still considering this an undocumented feature of ZLib rather than the officially supported method of editing settings.
One nice side effect: as I've been spending more and more time making relay scripts, it will be helpful to have the jQuery library included in ZLib's repository, rather than duplicating it in each repository that uses it, which can lead to problems when uninstalling a single script.
Chugsworth
New member
As a DB, I can no longer make us of any combat scripts that consult BatBrain as I am confronted with this error:
Using WHAM and verbosity 10, this is the relevant equation that kicks up the error:
The same equation and error results regardless of the combat script being used which, in combination with the very similar 'perfect' error that is detailed on the previous page, leads me to believe that BatBrain is the culprit, regardless of Zlib being referenced in the error message (but posted here nonetheless). Whereas the 'perfect' error could be bypassed by avoiding the PPB (and miniature feast), this one seems endemic to simply being a DB.
Build 13151, Zlib r16, BatBrain r25
Using WHAM and verbosity 10, this is the relevant equation that kicks up the error:
The same equation and error results regardless of the combat script being used which, in combination with the very similar 'perfect' error that is detailed on the previous page, leads me to believe that BatBrain is the culprit, regardless of Zlib being referenced in the error message (but posted here nonetheless). Whereas the 'perfect' error could be bypassed by avoiding the PPB (and miniature feast), this one seems endemic to simply being a DB.
Build 13151, Zlib r16, BatBrain r25
Chugsworth
New member
I've manually checked the SVN and the live version is r25. I've downloaded that version and overwritten the current version in the relevant local svn folder and called an svn update, which insists that my local version is r25. The error persists.
... or at least it did, until, for surety's sake, I overwrote what I assumed to be the redundant pre-SVN version in my scripts folder. Everything appears to be chugging along smoothly once more. Huh.
Thanks Bale.
... or at least it did, until, for surety's sake, I overwrote what I assumed to be the redundant pre-SVN version in my scripts folder. Everything appears to be chugging along smoothly once more. Huh.
Thanks Bale.
Last edited:
Bale
Minion
For the audience's sake I'll translate "Thanks Bale."
I had posted a comment about fvars["momentum"] being defined in the latest BatBrain, so it should work if he updates BatBrain. Then I noted that he specifically mentioned he was using r25 so I decided that must not have been the problem and deleted my post. Apparently I did not delete it until after it was read by Chugsworth and it turns out that was a good thing. It's a shame I deleted my post.
You're very welcome Chugsworth. I'm glad you were so thorough. Is it possible that you have a copy of BatBrain somewhere else in your /kolmafia directory?
I had posted a comment about fvars["momentum"] being defined in the latest BatBrain, so it should work if he updates BatBrain. Then I noted that he specifically mentioned he was using r25 so I decided that must not have been the problem and deleted my post. Apparently I did not delete it until after it was read by Chugsworth and it turns out that was a good thing. It's a shame I deleted my post.
You're very welcome Chugsworth. I'm glad you were so thorough. Is it possible that you have a copy of BatBrain somewhere else in your /kolmafia directory?
Last edited:
Chugsworth
New member
Beyond the two that I alluded to in the previous post (/svn and /scripts), no.
Bale
Minion
Winterbay: Nope, not related. Problem already (mysteriously) fixed.
Please search every other folder in the /kolmafia directory. Search the base directory, then search all the subdirectories.
Please search every other folder in the /kolmafia directory. Search the base directory, then search all the subdirectories.
Bale
Minion
Yes. However something wasn't working so I'm wondering if the broken element was that. Perhaps one of the directories or the root directory isn't properly being scanned. It was too weird for me to not ask him to check the improbable. Alternately SVN update just didn't copy working to local.
Chugsworth
New member
There are only two files located in /kolmafia and its subdirectories name batbrain.ash - the two the I have previously mentioned. There are a handful of others with additional extensions, however; batbrain.ash.tmp in /svn/batbrain/.svn/tmp and batbrain.ash.mine, batbrain.ash.r22 and batbrain.ash.r23 in /svn/batbrain/scripts, all of which indicate that they were created on the 5th October.
Those files indicate that there's some conflict, and SVN has stopped updating the file. The most likely cause would be if you made a change and SVN couldn't figure out how to merge it in. If you didn't manually make any changes, then you can delete and re-checkout the project as a quick fix, but it would be weird that there are issues in that case.
Bale
Minion
- batbrain.ash.mine : This was your personalized version of batbrain r22
- batbrain.r22 : This is zarqon's version of r22
- batbrain.r23 : This is zarqon's version of r23
- batbrain.ash : This will have some inline markup at the location of the conflict ( look for <<<<<< and >>>>> markup) showing you both what your text was and what the repo's text was.
You need to resolve the conflict. I recommend you go through batbrain.ash and look for the inline markup which will make it really easy to resolve the conflict. (If you've installed tortoise svn, the SVN Diff option will point it out extra clearly and save you the trouble of searching.) Then delete the extra files so that everything updates smoothly in the future. Finally do an svn sync to push your changes to the local directory.
Last edited:
Chugsworth
New member
Well that's interesting; I don't recall making any changes to my local version of BatBrain. Does the existence of batbrain.ash.mine (or any .ash.mine for that matter) simply supersede the default .ash file? If that is the case, why would the version checking consult the unused default file? Furthermore, how does the /scripts version come into play; is the duplication of the file in /svn really necessary?
Last edited:
Bale
Minion
You can simply rename batbrain.r23 as batbrain.ash and delete the others if you want to throw away your changes.
Yes. Only the version in /scripts will be used by mafia as a script. That's why batbrain did not update properly.
Yes. Only the version in /scripts will be used by mafia as a script. That's why batbrain did not update properly.
Winterbay
Active member
The quickest way without removing and reinstalling the script is to remove .ash, .mine and .r22 from the folder and rename .r23 to .ash and then run the update command again. That is if you don't actually care about whatever local change it was that you had done that didn't make it through unhindered.
My guess is that there is some flaw in SVNKit that is only triggered occasionally. I recently had my entire charpane.ash from CHIT show up as conflicted (all 4500 lines, when I've changed maybe 20 lines), so I gave up on resolving the conflicts and just reapplied my changes from a fresh copy.
Chugsworth, yes, there does need to be two separate copies. Mafia is only trying to run the copy in /scripts, but there is an entire SVN setup to keep the script updating, and all of that is tracked in /svn. Using "svn delete batbrain" and then "svn checkout " to get a fresh copy is going to be the easiest way to fix whatever happened.
Chugsworth, yes, there does need to be two separate copies. Mafia is only trying to run the copy in /scripts, but there is an entire SVN setup to keep the script updating, and all of that is tracked in /svn. Using "svn delete batbrain" and then "svn checkout " to get a fresh copy is going to be the easiest way to fix whatever happened.
Chugsworth
New member
Thanks for all of the clarifications about this.
So, to review, my current understanding of events is that something caused (or the SVN perceived) an alteration to batbrain.ash that led to the creation of the divergent .ash.mine copy, which was then copied to /scripts as the actively referenced version. The SVN continued to update the .ash version and also maintained copies of the updates between the divergence point and the live version as .ash.rxx, however due to the conflict the /scripts version was never updated. svn update returned r25 as that was, in fact, the version present in /svn, regardless of the /scripts version.
It strikes me as somewhat odd that I've only encountered an error now seeing as, from what I can tell, the presence of .ash.r22 and .ash.r23 means that the .ash.mine copy has been in use since September, which is also at odds with the file creation dates. Nevertheless, the issue is resolved and I am indebted to you all for your assistance. Thank you kindly.
Also, apologies to zarqon for throwing a discussion about BatBrain and the SVN into the ZLib thread.
So, to review, my current understanding of events is that something caused (or the SVN perceived) an alteration to batbrain.ash that led to the creation of the divergent .ash.mine copy, which was then copied to /scripts as the actively referenced version. The SVN continued to update the .ash version and also maintained copies of the updates between the divergence point and the live version as .ash.rxx, however due to the conflict the /scripts version was never updated. svn update returned r25 as that was, in fact, the version present in /svn, regardless of the /scripts version.
It strikes me as somewhat odd that I've only encountered an error now seeing as, from what I can tell, the presence of .ash.r22 and .ash.r23 means that the .ash.mine copy has been in use since September, which is also at odds with the file creation dates. Nevertheless, the issue is resolved and I am indebted to you all for your assistance. Thank you kindly.
Also, apologies to zarqon for throwing a discussion about BatBrain and the SVN into the ZLib thread.
Last edited:
It's a shame that it annoys you. Perhaps you could, you know, not use freely granted software, if it annoys you so much.
Easy fix. I'm sure zarqon will be right on it, if and when he comes back from his hiatus.
Edit: Hmm. I thought you were on my "ignore" list, because of this kind of behavior, previously directed at MY work. It appears to be a general defect in your affect. I should probably just put you right back there. Done.
Last edited: