John, thanks a lot for the detailed response, this is appreciated. I appreciate
even more the work put into PSPP, and didn't intend to criticize the state of
things, nor the decision not to invest more time into maintaining the Windows
builds. I was just asking because I don't have the skills to easily do the
build myself.
If it were a practical option for me, I would indeed have switched to a Linux
platform long ago, but as these things go, my employer only supports Windows
clients...
Cheers, M.
PS: If anyone with the right skill set finds this exchange motivating to look
into becoming the new maintainer for the Windows PSPP binaries business: be
assured of my gratitude 😊.
-----Ursprüngliche Nachricht-----
Von: John Darrington <j...@darrington.wattle.id.au>
Gesendet: Dienstag, 31. August 2021 16:16
An: Quandt, Markus <markus.qua...@gesis.org>
Cc: Julia Klausli, Ph.D. <jklausli....@divinemercy.edu>; pspp-users@gnu.org
Betreff: Re: no more PSPP for Windows?
On Tue, Aug 31, 2021 at 01:17:22PM +0000, Quandt, Markus wrote:
It has in my experience a nasty problem with the Windows output interface
sometimes being very unresponsive, if you produce large outputs, but works fine
for most every-day analyses and teaching, I would say. All Windows versions I
ever used had the same problem, by the way, IIRC.
Any operation on PSPP which takes a long time is going to make the GUI
unresponsive for the time it takes to complete. For example, processing a very
large number of cases, or generating very large ouput.
From time to time we get requests to "fix" this. Whilst might be possible to
provide a fix which would allow the GUI to remain responsive whilst processing,
the following caveats would still apply:
1. Until the procedure has completed, it would still not be possible to start
any new procedure.
2. Allowing the GUI to respond, would slow down the total time it takes for the
procedure to complete.
3. Such a change would not be simple and would take a lot of developer time.
For these reasons, such a fix has not been considered high priority.
Having said that, if anybody wishes to contribute such a fix then it'll
probably be accepted.
Also, although the problem exists on all systems (not only Windows) PSPP runs
magnitudes faster on GNU/Linux than on Windows, so I would suggest that you try
that instead.
This being said, I was wondering myself whether there is a perspective for
the pre-compiled Windows versions being brought up to date again. There
definitely are some fixes and features missing in the Windows version by now.
Harry (who used to provide the Windows builds) has said that he doesn't intend
to do this any more. However, I think his last build includes the the most
recent release 1.4.1 - any changes after that are not released, and like any
unreleased software you should think twice before using it.
So far as whether any pre-compiled Windows binaries will be made publically
available depends on whether anyone volunteers to do the job. Performing the
builds is not too onerous, but maintaining such a public service is harder than
one might imagine. For a start, it is not just a build for "Windows".
Today there is Windows7, Windows10, WindowsCE ... then for each variant of
Windows there is today not only intel architectures to consider, but i386, AMD,
ARM and possibly others. Then Harry found there was demand for debug and non
debug versions... So that's 3 x 3 x 2 = 18 different binaries for each release.
At the end of the day, if you want a pre-compiled binary, it is far easier to
let OS vendor do it for you. However, whereas most vendors are happy to
include PSPP in their distribution (see https://pkgs.org/download/pspp) I
suspect that if you wrote to Microsoft asking "Please include PSPP in the next
release of Windows" you probably would not receive a reply.
PSPP is a GNU project, and so supporting the GNU system comes first. Other
free systems come second, and non-free systems such as Windows have the lowest
priority.
