garglk development activity

[Andrew Plotkin]

It is getting to be time to talk about this. I notice another pull request at https://github.com/garglk/garglk . There's also a recent post ( http://www.intfiction.org/forum/viewtopic.php?f=38&t=19748#p118551 ) which mentions some contributions ( https://github.com/RedHatter/granite ) which have been sitting around for a while.

The last I know on the subject of releases is Chris Spiegel saying (in October 2016):

> At this point I don't think there are *any* builder roles, for any 

> platform; I think Ben Cressey did all the prior builds, but he is not 
> currently participating in development. 
> 
> The current build system is Jam, which basically nobody uses.  I've been 
> working on a tentative move to CMake [...]

And then I put up a new MacOS build, but I labelled it "unofficial" because it's based on unmerged pull requests.

Clearly nobody is currently wearing the hat of "decide what's going on with garglk" much less "merge branches and declare a release". And I am not volunteering to wear those hats! (I have enough hats already, holy leapin' otters.)

However, I *am* willing to start the nudging to find someone to step up. I could start passing the word on twitter. And on the forums, the IFTF blog, and so on.

Questions: 

What am I spreading the word about? Are "project decider" and "repo maintainer" separate roles? Does someone on this list see themself as wearing one of them if the other one gets taken up? Is anyone on this list irate at my presumption? (This is a real question.)

If nobody steps up, how about https://github.com/adoptableiftech/README ? This is a github collection which exists to say "Hi, I am an IF project with no maintainer, please adopt me." (My suggestion to call it the Daisy Hill Interpreter Farm was roundly denied.)

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

*

[Andrew Plotkin]

Nudging this question (and top-posting -- sorry -- because it's been a
couple of weeks).

I see that Chris Spiegel merged a couple of PRs last week; great. Do we
have any movement towards somebody wanting to do builds, or decide about
releases?

As I said, I am willing to start passing the word for new volunteers.
If this mailing list remains silent for another couple of weeks, I will do
that presumptively...

(Please believe that I am only pushing on this because of the value of
Gargoyle to the IF community.)

--Z

> --
> You received this message because you are subscribed to the Google Groups "garglk-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to garglk-dev+...@googlegroups.com.
> To post to this group, send email to gargl...@googlegroups.com.
> Visit this group at https://groups.google.com/group/garglk-dev.
> For more options, visit https://groups.google.com/d/optout.

[Chris Spiegel]

On 03/18/2017 01:30 PM, Andrew Plotkin wrote:
> Nudging this question (and top-posting -- sorry -- because it's been a
> couple of weeks).
>
> I see that Chris Spiegel merged a couple of PRs last week; great. Do we
> have any movement towards somebody wanting to do builds, or decide about
> releases?
>
> As I said, I am willing to start passing the word for new volunteers.
> If this mailing list remains silent for another couple of weeks, I will do
> that presumptively...
>
> (Please believe that I am only pushing on this because of the value o

> Gargoyle to the IF community.)

I'm completely in favor of finding willing volunteers to do builds. I'm
not familiar enough with any of the target systems (including specific
Linux distributions) to be able to do builds, so I'd welcome anybody
with that knowledge to step forward and handle it.

As for release, is there anything anybody has that is considered a
blocker? From my perspective, there are two things:

1. Bocfel needs to be updated to the (forthcoming) latest release, which
will fix issues #238 and #231. I have these fixed locally, just need to
actually cut a release (so that will be easy to get done).

2. TADS needs to be updated to the latest version, which will fix issues
#236 and #203. This is a more major undertaking. I've got a branch
which could use testing:

https://github.com/cspiegel/garglk/tree/203-tads-upgrade

Because it makes use of code from FrobTADS, it should be solid on
Unix-like systems. I've tested with MinGW, and it appears to be working
fine there, too, although if you look at the code there are a few hacks
to work around some issues. These are mainly related to the filesystem
(symlinks) and permissions (it'd be nice to have a more complete
os_file_stat() implementation on MinGW but I don't know how necessary it
is to play most/all available games). And I don't have access to OS X
systems. I'm hoping they're POSIX enough to be covered but testing
would be immensely helpful.

If these are in, then I'm comfortable with a release. I think the TADS
issue is definitely a blocker, because it would be embarrassing to
release a version of Gargoyle with a TADS interpreter that can't play
some games released over 5 years ago.

In short, unless anybody has a very good objection, let's plan on a
release once we have a way to produce builds for all platforms, possibly
with a short prerelease phase to do some TADS testing, as well as iron
out issues with the builds themselves; for TADS, at least, I'm well
aware that just pointing to some source code somewhere isn't going to
result in as much testing as a binary prerelase would.

[Andrew Plotkin]

On Sat, 18 Mar 2017, Chris Spiegel wrote:

>
> I'm completely in favor of finding willing volunteers to do builds. I'm
> not familiar enough with any of the target systems (including specific
> Linux distributions) to be able to do builds, so I'd welcome anybody
> with that knowledge to step forward and handle it.

Ok, I'll ask around. I can continue to cover MacOS builds until my old
laptop expires.

> https://github.com/cspiegel/garglk/tree/203-tads-upgrade
>
> Because it makes use of code from FrobTADS, it should be solid on
> Unix-like systems. I've tested with MinGW, and it appears to be working
> fine there, too, although if you look at the code there are a few hacks
> to work around some issues. These are mainly related to the filesystem
> (symlinks) and permissions (it'd be nice to have a more complete
> os_file_stat() implementation on MinGW but I don't know how necessary it
> is to play most/all available games). And I don't have access to OS X
> systems. I'm hoping they're POSIX enough to be covered but testing
> would be immensely helpful.

I can try it on Mac, but you'll have to point me to testing resources. I
don't know what to try to call it verified.

> In short, unless anybody has a very good objection, let's plan on a
> release once we have a way to produce builds for all platforms, possibly
> with a short prerelease phase to do some TADS testing, as well as iron
> out issues with the builds themselves

Sounds good.

[Chris Spiegel]

On 03/19/2017 02:29 PM, Andrew Plotkin wrote:
>> https://github.com/cspiegel/garglk/tree/203-tads-upgrade
>>
>> Because it makes use of code from FrobTADS, it should be solid on
>> Unix-like systems. I've tested with MinGW, and it appears to be working
>> fine there, too, although if you look at the code there are a few hacks
>> to work around some issues. These are mainly related to the filesystem
>> (symlinks) and permissions (it'd be nice to have a more complete
>> os_file_stat() implementation on MinGW but I don't know how necessary it
>> is to play most/all available games). And I don't have access to OS X
>> systems. I'm hoping they're POSIX enough to be covered but testing
>> would be immensely helpful.
>
> I can try it on Mac, but you'll have to point me to testing resources. I
> don't know what to try to call it verified.

Unfortunately it doesn't look like there's any sort of official test to
rigorously run through everything. At the recommendation of Michael
Roberts, I've put the question to Nikos Chantziaras and Rune Berg, who
have done work on porting interpreters. I'll provide an update when I
have more information.

Until then, I would suspect the vast majority of OS-specific code in
TADS will be the file I/O used for save games, transcripts, and command
records, so testing these, at least, would be helpful. I've built the
sample game that comes with TADS and uploaded it here:

https://drive.google.com/open?id=0B5cozu32ALh1Z3R6cVQxV0dYdTQ

This should support SAVE/RESTORE, SCRIPT, and RECORD/REPLAY.

[Brad Town]

On Sunday, March 19, 2017 at 2:29:13 PM UTC-7, Andrew Plotkin wrote:

Ok, I'll ask around. I can continue to cover MacOS builds until my old
laptop expires.

I just made a pull request that improves building on macOS, so if someone can review it and perhaps even accept it, maybe macOS builds will be less painful. (It can use either MacPorts or Homebrew, it's more tolerant of changes to libraries used, and it builds on macOS Sierra.)

[Andrew Plotkin]

On Sat, 25 Mar 2017, Brad Town wrote:

> On Sunday, March 19, 2017 at 2:29:13 PM UTC-7, Andrew Plotkin wrote:
>>
>> Ok, I'll ask around. I can continue to cover MacOS builds until my old
>> laptop expires.
>>
>

> I just made a pull request <https://github.com/garglk/garglk/pull/244> that

> improves building on macOS, so if someone can review it and perhaps even
> accept it, maybe macOS builds will be less painful. (It can use either
> MacPorts or Homebrew, it's more tolerant of changes to libraries used, and
> it builds on macOS Sierra.)

Have you tested it back to OS 10.8 after building on Sierra?

Last time I tried building on 10.12, I got a binary which would not run on
10.11 and earlier.

(I have a 10.7 test machine but nothing between 10.8 and 10.11.)

My MacOS build update
(https://github.com/erkyrath/garglk/tree/buildports7) is much more
conservative; I build it on 10.7 with MacPorts and it works on everything
newer. I'll try yours and see what happens.

[Andrew Plotkin]

Okay, I have built two Mac versions, one using my gargoyle_osx.sh and one
using Brad's. (Don't mean to doubt you, I just want to test in parallel.)

Both are up-to-date with the master branch, plus the changes in
cspiegel/203-tads-upgrade. (That is, TADS 3.1.3.)

https://github.com/erkyrath/garglk/releases

Both work on MacOS 10.12. I've done a quick run-through of the TADS
save/restore/script/record/replay features; they all seem to work.

[Andrew Plotkin]

On Tue, 28 Mar 2017, Andrew Plotkin wrote:

> https://github.com/erkyrath/garglk/releases
>
> Both work on MacOS 10.12. I've done a quick run-through of the TADS
> save/restore/script/record/replay features; they all seem to work.

Update, after more testing... (Summarizing what I've been saying in the
thread and on Github:)

People have reported three distinct problems.

1) On Mac, Gargoyle won't load any game whose filename (or path) contains
non-ASCII characters. This has been true forever, or since 2012, at least.

2) The new TADS code works for the library sample.t3. However, on one game
(No_Quiero_Verla.t3, http://ifdb.tads.org/viewgame?id=zea8r0chhay0nv5r) it
fails to load, saying:

> this interpreter version cannot run this program (program requires
> intrinsic function set tads-net/030001, which is not available in this
> interpreter)

I suppose that's a network library? Anyway, not a blocker if most games
don't need it.

3) Brad Town's updated build script
(https://github.com/garglk/garglk/pull/244) isn't flying. I was able to do
a build with it on both my old 10.7 laptop and my current 10.12 machine,
but the resulting apps only ran on the OS version they were built on.

I would therefore rather stick to my build script
(https://github.com/erkyrath/garglk/tree/buildports7-tads203). If I run
that on 10.7, I get an app that runs on all MacOS versions 10.7 and up.
I'll make a pull request for this.
(https://github.com/garglk/garglk/pull/247)

[Andrew Plotkin]

On Sat, 1 Apr 2017, Andrew Plotkin wrote:

> 3) Brad Town's updated build script
> (https://github.com/garglk/garglk/pull/244) isn't flying.

I figured out what the problem was. My fault. (I was trying to use a set
of packages out of homebrew that weren't loaded correctly. See comments on
the PR linked above.)

I've put together another "kitchen sink" PR which starts with Brad's, and
then adds the TADS 3 work and some extra changes to support MacOS 10.7.

(I see the Unicode-pathname fix is now in master and all resolved, yay.)

https://github.com/garglk/garglk/pull/254

[Andrew Plotkin]

Time for me to rattle the list again... What is the current status on a
new release? I see Chris has been steadily merging in the pull requests.
Are there more of those to do?

Earlier this year I asked around for Windows build volunteers, but didn't
catch any. Is that still an issue? If it winds up being a release blocker,
I can re-post that request and let people know that it's important.

[Chris Spiegel]

On 06/12/2017 12:45 PM, Andrew Plotkin wrote:
> Time for me to rattle the list again... What is the current status on a
> new release? I see Chris has been steadily merging in the pull requests.
> Are there more of those to do?
>
> Earlier this year I asked around for Windows build volunteers, but
> didn't catch any. Is that still an issue? If it winds up being a release
> blocker, I can re-post that request and let people know that it's
> important.

I don't think there's anything critical, code-wise, that needs to be
done. I'm comfortable tagging a release at any point.

As far as I know, though, we're still in need of somebody capable of
doing a Windows build, which may include installer updates--I don't know
if the existing installer scripts still work.

--
Chris

[Andrew Plotkin]

Okay, I'll pass that around.

[Bertrand Augereau]

>> Earlier this year I asked around for Windows build volunteers, but
>> didn't catch any. Is that still an issue? If it winds up being a release
>> blocker, I can re-post that request and let people know that it's
>> important.

Hi guys.
I might be able to do this, I need to evaluate how much should be done first (lots of stuff on my plate, I'll get back to you soon).
Cheers,
Tramb

[Bertrand Augereau]

Hi guys,

I agree it would be great to have a modern WIN32 build for Gargoyle.
I just setup a MSYS2 toolchain to evaluate what needs to be done.
It doesn't build out of the box, but it's probably tractable cleanly in a finite time.
I'll keep you informed (but I've got lots of real work to do too) before two weeks (if nobody does it first :) )

Cheers,
Tramb

[Chris Spiegel]

Given that there appear to be no takers for the Windows build, I tried
my hand at it, and have produced something that at least works in Wine
on Linux (I don't currently have access to a Windows machine):

https://github.com/garglk/garglk/files/1438941/gargoyle-2017.11-testing-windows.zip

I'd really appreciate some testing of this. I don't know what the range
of supported Windows versions is, for example. I don't know if it acts
like a "normal" installer, although it should be using the same
installer scripts as the previous version, so I wouldn't expect major
issues.

2011.1 included an Ubuntu package, and if somebody can build one, great,
but I'm not going to consider that a blocker for release. Windows + OSX
is sufficient as far as I'm concerned.

[Tor Andersson]

Hi,

Just tested this on Windows 7. It works, but there are two potential
issues with it:

The "garglk.ini" file that is opened with the "Options..." menu has
unix line endings, and that confuses notepad. It would be nice if the
installer uses DOS line endings for this file.

Installing in the default "Program Files" directory means that files
inside it can only be modified by the administrator account. Thus the
"garglk.ini" file cannot be edited by default. This can be fixed by
installing outside the "Progam Files" directory, and should probably
be mentioned in the installer at the "Choose Install Location" screen
if possible.

Thanks again for keeping the torch lit!

Regards,
Tor

[Chris Spiegel]

On 11/05/2017 03:18 AM, Tor Andersson wrote:
> Hi,
>
> Just tested this on Windows 7. It works, but there are two potential
> issues with it:
>
> The "garglk.ini" file that is opened with the "Options..." menu has
> unix line endings, and that confuses notepad. It would be nice if the
> installer uses DOS line endings for this file.

Good idea. I've just submitted a pull request that does this.

> Installing in the default "Program Files" directory means that files
> inside it can only be modified by the administrator account. Thus the
> "garglk.ini" file cannot be edited by default. This can be fixed by
> installing outside the "Progam Files" directory, and should probably
> be mentioned in the installer at the "Choose Install Location" screen
> if possible.

The usage of garglk.ini does need to be better documented. A whole lot
better...

From reading the source, it looks like garglk.ini is searched for in the
following locations:

1. The directory containing gargoyle.exe (Windows), or /etc/garglk.ini
(Unix)
2. $GARGLK_INI/garglk.ini (plus, in the launcher only,
$GARGLK_INI/.garglkrc)
3. $HOME/.garglkrc
4. $HOME/garglk.ini
5. $XDG_CONFIG_HOME/.garglkrc
6. $XDG_CONFIG_HOME/garglk.ini
7. (game directory)/garglk.ini
8. (game directory)/(name of game).ini, e.g. zork1.ini.

And unfortunately, the launcher has its own code to do the same thing,
in order to find interpreters. At the very least the "find
gargoyle.ini" code should be consolidated, but I'm not sure looking in 8
places is ideal. For config options, all files are used, but if there
are duplicate config options, the last one takes precedence (so, for
example, garglk.ini in the game directory overrides config options in
~/.garglkrc).

1. $XDG_CONFIG_HOME should be confined to Unix (OS X? I don't know).
2. $HOME maybe should be Unix-only, too, and on Windows, a more proper
way to locate config files should be used. In Bocfel I look in $APPDATA
and $LOCALAPPDATA, but I'm not sure that's "proper". If any Windows
developers want to chime in that'd be great.
3. We should choose either .garglkrc or garglk.ini, or, more in line
with tradition, check both $HOME/.garglkrc and $XDG_CONFIG_HOME/garglkrc.
4. Allowing games themselves to provide configs should be optional; that
is, there should be an option like "ignore_game_config" or something
when, if true, stops ini parsing at step 6 above. This is probably less
important, and maybe just a personal thing: I don't like games
overriding my config options.
5. The "system" config file (number 1 above) should maybe just be an
example, i.e. not used by Gargoyle. It feels a little wrong to me for a
system-wide config file to exist, because it can require users to write
their configs to specifically counteract whatever the current system has.
6. $GARGLK_INI? I don't know... is it really necessary? If so, I'd at
least expect it to point to an actual config file instead of a directory.

To explain #5 a bit better, an example: I have a .vimrc file I copy
around to any system I'm going to be using vim on for an extended period
of time. Sometimes my vim starts acting really weird, even with my
config file, and it's because for some reason there's an /etc/vimrc file
which turns on some options I don't like. As a result, my vimrc, which
is meant to work with a non-configured vim, all of a sudden isn't
sufficient. I have to add more options to disable whatever the local
administrator has enabled. With something that end-users will be using
(i.e. not a system daemon), I just don't see the utility in a
system-wide configuration file. In short, I think that the proper
defaults should be built into Gargoyle, and only users, not the
administrator, should be able to modify them.

OK, so I'd tentatively propose something like the following for config
files:

1. <local configuration directory>/<.garglkrc or garglkrc or
garglk.ini>. This might search multiple locations.
2. (perhaps only if not disabled) <game directory>/garglk.ini.

> Thanks again for keeping the torch lit!

Thank you for creating what I consider the gold standard in desktop
interactive fiction.

--
Chris