ZLib -- Zarqon's useful function library

MCroft

Developer
It is idiomatic around here that "latest build" and "up to date" refer to the builds available from https://ci.kolmafia.us/ and not what is available at SourceForge.

There is a mechanism for script writers to indicate that a particular daily build (or newer) is required, the since directive. As noted above zarqon failed to update that when a zlib update was pushed, but that error has since been corrected.

Users who wish to protect themselves from similar oversights by script authors tend to do so by always using the "latest build" as defined above. The days when the daily builds were buggy and unstable are long gone and since 5 months have passed since the SourceForge build was last updated the commitment to keeping SourceForge up to date might be wavering.

Your steps to try and resolve the issue were perfectly reasonable although ultimately incorrect :)
While bugs are possible (and I can point to several, including mine), KoLmafia daily builds are likely to do a better job keeping up with KoL changes. Anything introduced by KoL since KoLmafia 20.7 (July 2020) is not going to be there. Especially at Crimbo time, there are KoL changes that will affect play.

We've done some work to make releases more efficient so we can get on a better cadence, but the process is still a bottleneck.

And sourceforge has a number of things that are out of date on it, especially in the documentation. It still lists Java 1.5 as the required version.
 

scudunculus

New member
Your steps to try and resolve the issue were perfectly reasonable although ultimately incorrect :)
Thanks for confirming I'm not crazy (at least not in that regard!).

It is idiomatic around here that "latest build" and "up to date" refer to the builds available from https://ci.kolmafia.us/ and not what is available at SourceForge.

...

Users who wish to protect themselves from similar oversights by script authors tend to do so by always using the "latest build" as defined above. The days when the daily builds were buggy and unstable are long gone and since 5 months have passed since the SourceForge build was last updated the commitment to keeping SourceForge up to date might be wavering.

I suppose then the real problems then are:
> that the version information that gets displayed is not precise enough (20.7 is not enough, it needs build number to be displayed somewhere)
> and that all indications point to sourceforge as the source of the latest builds. From the "version information" and the "kolmafia thread" link, you get directed to sourceforge. The "kolmafia forums" link does get you here but you might just see that the highest numbered thread title is 20.7 and not click through to see daily builds. From the wiki landing page, you probably would look first at the 'installation' page, where the first link you see is to sourceforge.

In any case, this seems more of a problem with mafia itself, not specifically zlib. Sorry if I'm coming across as accusatory, I just wanted to point out a thing that would avoid confusion for other people down the line. The problem as I saw it was just that I was under the mistaken impression that I already had the latest version... until I looked closer.
 

fronobulax

Developer
Thanks for confirming I'm not crazy (at least not in that regard!).



I suppose then the real problems then are:
> that the version information that gets displayed is not precise enough (20.7 is not enough, it needs build number to be displayed somewhere)
> and that all indications point to sourceforge as the source of the latest builds. From the "version information" and the "kolmafia thread" link, you get directed to sourceforge. The "kolmafia forums" link does get you here but you might just see that the highest numbered thread title is 20.7 and not click through to see daily builds. From the wiki landing page, you probably would look first at the 'installation' page, where the first link you see is to sourceforge.

In any case, this seems more of a problem with mafia itself, not specifically zlib. Sorry if I'm coming across as accusatory, I just wanted to point out a thing that would avoid confusion for other people down the line. The problem as I saw it was just that I was under the mistaken impression that I already had the latest version... until I looked closer.

The daily build clearly shows the revision number on the top of the login page and when displaying Help->Copyright Notice->Version Info. So this is really a documentation and user education problem, exposed by a script author's omission.

So....

You might consider two things. One is that you can edit the wiki https://wiki.kolmafia.us/index.php/Main_Page so that there is new or corrected information. Maybe the next person who doesn't understand the distribution model, as it is actually practiced, will not not get so confused. If you don't have permission to edit I think @fewyn can grant it.

Second, creating a Bug Report that identifies incorrect and confusing information on SourceForge might lead to some changes. There are no guarantees that anyone will take action but it is also true that politely squeaky wheels are sometimes greased.

Finally, remember that Kolmafia and scripts are maintained by volunteers who are doing it for reasons of their own and you are already getting your money's worth :)
 

MCroft

Developer
The daily build clearly shows the revision number on the top of the login page and when displaying Help->Copyright Notice->Version Info. So this is really a documentation and user education problem, exposed by a script author's omission.

So....

You might consider two things. One is that you can edit the wiki https://wiki.kolmafia.us/index.php/Main_Page so that there is new or corrected information. Maybe the next person who doesn't understand the distribution model, as it is actually practiced, will not not get so confused. If you don't have permission to edit I think @fewyn can grant it.
I'd like to include the pretty graphic from Jenkins on the wiki homepage. Probably also with a less-pretty link to sourceforge...
 
So! In r47 I've adjusted URL-based version checking to use the new forum URL.

This is not working. I keep getting warnings like this:
Code:
Checking for updates (running auto_mushroom ver. 2.2)...
Server returned response code 404 (Not Found) for https://kolmafia.us/threads/t=9854
Unable to load current version info.

The current version (r48) checks https://kolmafia.us/threads/t=<Thread ID>. However, the correct URL is https://kolmafia.us/threads/<Thread ID>.

I'm submitting a patch for this that also fixes the "latest post" URL (line 226).

P.S. It seems that https://kolmafia.us/showthread.php?t=<Thread ID> also works.
 

Attachments

  • philmasterplus-zlib-check-update-url-fix.patch
    3.1 KB · Views: 1

fronobulax

Developer
This is not working. I keep getting warnings like this:
Code:
Checking for updates (running auto_mushroom ver. 2.2)...
Server returned response code 404 (Not Found) for https://kolmafia.us/threads/t=9854
Unable to load current version info.

The current version (r48) checks https://kolmafia.us/threads/t=<Thread ID>. However, the correct URL is https://kolmafia.us/threads/<Thread ID>.

I'm submitting a patch for this that also fixes the "latest post" URL (line 226).

P.S. It seems that https://kolmafia.us/showthread.php?t=<Thread ID> also works.

I'm going to push back on this and suggest you check your environment.

From today

AUTO_MUSHROOM already run today!
Next event in 8 days: eight gloomy black mushrooms picked
Checking for updates (running auto_mushroom ver. 2.2)...
Running auto_mushroom version: 2.2 (current)

and none of the other scripts that had been giving update errors has done so for me today.

You might also consider deleting or editing data/zversions.txt or confirming that you really did update zlib.
 

3BH

New member
We have had multiple users reporting errors to the effect of: "Stack overflow during ASH script: (zlib.ash, line 375)". on discord. It seems to be tied to there being no vars_defaults.txt or vars_<user>.txt

Did anything change related to that recently?

Editing to add actual useful context because my above explanation sucked:
The issue is when zlib tries to vprint but are unable to because getvar("verbosity") sends them into a loop with vprint, since they cant find any variables because vars_defaults doesnt exist. The actual line number will vary depending on when mafia actually gets fed up with the getvar()->vprint() loop its found itself in.
 
Last edited:

zarqon

Active member
Not with ZLib, no. I believe there have been some changes to KoLmafia regarding opening data files though. If you can find a way to replicate the issue it's probably worth posting a bug report.
 

MCroft

Developer
The smallest use-case I saw in the online discussion was
Code:
>zlib vars

Stack Overflow during ASH script: (zlib.ash, line 379)

I thought it might be a problem creating vars_defaults.txt, but when I removed mine, it created a new one.
 

zarqon

Active member
Editing to add actual useful context because my above explanation sucked:
The issue is when zlib tries to vprint but are unable to because getvar("verbosity") sends them into a loop with vprint, since they cant find any variables because vars_defaults doesnt exist. The actual line number will vary depending on when mafia actually gets fed up with the getvar()->vprint() loop its found itself in.
Just saw your edit. From my viewing of the code I'm still at the "that can't possibly happen" stage of debugging -- ZLib calls setvar("verbosity") as its first top-level command of any relevance, which updates the relevant maps before calling vprint(). And I'm not seeing how vprint() could be called before that. I guess changing line 379 to a regular print() statement would fix that, but I'm confused as to why it would be necessary.
 

3BH

New member
Just saw your edit. From my viewing of the code I'm still at the "that can't possibly happen" stage of debugging -- ZLib calls setvar("verbosity") as its first top-level command of any relevance, which updates the relevant maps before calling vprint(). And I'm not seeing how vprint() could be called before that. I guess changing line 379 to a regular print() statement would fix that, but I'm confused as to why it would be necessary.
I agree with your assessment, I was super confused on this when two different people posted about it in discord, took a while to narrow down what I thought was happening, and I could still be wrong. You can reproduce the error (even though I understand that this isnt really a real use case) by removing verbosity from vars_defaults.txt and trying to run zlib vars (provided you dont have an entry in vars_<user>.txt) . I do not think your script is the ultimate culprit here because like croft, when I deleted vars_default and going through these same steps it created a vars_default.txt file for me and worked as intended.
 

fronobulax

Developer
I cannot reproduce the error using zlib vars and various combinations of vars_<user> and vars_<default> being present or absent. Could the people who have it provide line counts of the various files and and view the files in a text editor and confirm there is nothing but plain text?
 
Top