[PATCH] Re: patch for chicken on 64-bit windows (msys and mingw-w64)
> Alright, I'm convinced. Attached is a patch to drop the damn thing. > Pushed (also to prerelease). Thanks. felix
Re: [PATCH] Re: patch for chicken on 64-bit windows (msys and mingw-w64)
On Mon, Aug 30, 2021 at 08:10:46PM +0300, elf wrote: > I do use Windows regularly and am looking to improve chicken support for it. Hi Elf, Cool to hear. What are your thoughts on the current situation? Which flavour of Windows build should we keep and which should we drop (if any)? What about WSL and MSVC? One thing I've been wondering about for a while now: Do you think we should switch our scripts from CMD to PowerShell? Would that reduce some of the pain or just bring new and interesting failure modes because it's even further removed from the UNIX world view? Cheers, Peter signature.asc Description: PGP signature
Re: [PATCH] Re: patch for chicken on 64-bit windows (msys and mingw-w64)
I do use Windows regularly and am looking to improve chicken support for it. -elf On 30 August 2021 19:55:03 GMT+03:00, felix.winkelm...@bevuta.com wrote: >> > * As far as I can tell, none of the CHICKEN developers use Windows >> > regularly. >> >> True. I have it running in a VM, but I always start it with a lot of >> trepidation and I don't fully understand the OS itself. For example, >> suddenly now "make check" has started to give a "permission denied - >> cannot delete read-lines.in" error where it's always worked before >> and I have no idea why it can't delete it. >> >> > * There are many combinations of Windows environments, leading to a >> > great variety of ways to break stuff. >> >> They all suck in their own way. I'm kind of thinking maybe we don't >> really need the cygwin build anymore now that there's WSL? >> >> > * We do not have automated tests on Windows. >> > >> > As a start, it would be nice to collect the information we need in a >> > wiki page (e.g., which variants of Windows we want to/can support, how >> > they differ etc.). At this point I'm lost at the combinations of >> > different Windows things that affect the build/execution of CHICKEN. >> > >> > I'd say we need help at that so that we can improve support on Windows. >> >> That's a catch-22 though: in order to get that help, we need CHICKEN >> in a useful-enough state that people can use it on Windows. And in >> general, out of the total set of users, only a small subset will >> actually contribute. > >I agree to all of this and I think we can't go on like this. We have to cut >down >support for all those Windows variants, even for Windows buffs this is a >nightmare to maintain (which we aren't). > >I see only two solutions: > >- Cut Windows support completely. Yeah, life is hard, but what"s the point if > the core developers don't use and don't know it? CHICKEN will always run > badly on Windows. > >- Support a single native variant of Windows, just the > bare minimum, provided there is some Mingw/Msys variant that works, and that > has at least a small chance of not becoming obsolete instantly. Drop Cygwin, > perhaps ensure WSL is a working option. > >What"s the state of all those Mingw variants? Are there resources where one >can find out about this? > > >felix > > >
[PATCH] Re: patch for chicken on 64-bit windows (msys and mingw-w64)
> > * As far as I can tell, none of the CHICKEN developers use Windows > > regularly. > > True. I have it running in a VM, but I always start it with a lot of > trepidation and I don't fully understand the OS itself. For example, > suddenly now "make check" has started to give a "permission denied - > cannot delete read-lines.in" error where it's always worked before > and I have no idea why it can't delete it. > > > * There are many combinations of Windows environments, leading to a > > great variety of ways to break stuff. > > They all suck in their own way. I'm kind of thinking maybe we don't > really need the cygwin build anymore now that there's WSL? > > > * We do not have automated tests on Windows. > > > > As a start, it would be nice to collect the information we need in a > > wiki page (e.g., which variants of Windows we want to/can support, how > > they differ etc.). At this point I'm lost at the combinations of > > different Windows things that affect the build/execution of CHICKEN. > > > > I'd say we need help at that so that we can improve support on Windows. > > That's a catch-22 though: in order to get that help, we need CHICKEN > in a useful-enough state that people can use it on Windows. And in > general, out of the total set of users, only a small subset will > actually contribute. I agree to all of this and I think we can't go on like this. We have to cut down support for all those Windows variants, even for Windows buffs this is a nightmare to maintain (which we aren't). I see only two solutions: - Cut Windows support completely. Yeah, life is hard, but what"s the point if the core developers don't use and don't know it? CHICKEN will always run badly on Windows. - Support a single native variant of Windows, just the bare minimum, provided there is some Mingw/Msys variant that works, and that has at least a small chance of not becoming obsolete instantly. Drop Cygwin, perhaps ensure WSL is a working option. What"s the state of all those Mingw variants? Are there resources where one can find out about this? felix
[PATCH] Re: patch for chicken on 64-bit windows (msys and mingw-w64)
On Sun, Aug 29, 2021 at 09:21:38PM +0200, Mario Domenech Goulart wrote:
> Hi,
>
> On Fri, 27 Aug 2021 18:09:09 +0200 felix.winkelm...@bevuta.com wrote:
> > Using the already provided implementation is preferable, I'd say - one way
> > to shift responsibility, which, in this utter mess of Windows API, seems to
> > be
> > the only way forward.
>
> I agree.
Alright, I'm convinced. Attached is a patch to drop the damn thing.
> > Do we already have test results on all supported Windows platforms? I lost
> > track.
>
> I think we have a set of problems related to Windows, which is going to
> be very hard for us to handle without help:
>
> * As far as I can tell, none of the CHICKEN developers use Windows
> regularly.
True. I have it running in a VM, but I always start it with a lot of
trepidation and I don't fully understand the OS itself. For example,
suddenly now "make check" has started to give a "permission denied -
cannot delete read-lines.in" error where it's always worked before
and I have no idea why it can't delete it.
> * There are many combinations of Windows environments, leading to a
> great variety of ways to break stuff.
They all suck in their own way. I'm kind of thinking maybe we don't
really need the cygwin build anymore now that there's WSL?
> * We do not have automated tests on Windows.
>
> As a start, it would be nice to collect the information we need in a
> wiki page (e.g., which variants of Windows we want to/can support, how
> they differ etc.). At this point I'm lost at the combinations of
> different Windows things that affect the build/execution of CHICKEN.
>
> I'd say we need help at that so that we can improve support on Windows.
That's a catch-22 though: in order to get that help, we need CHICKEN
in a useful-enough state that people can use it on Windows. And in
general, out of the total set of users, only a small subset will
actually contribute.
Cheers,
Peter
From 1edd51e77982ebce33b165e481da8df3f7ec813a Mon Sep 17 00:00:00 2001
From: Peter Bex
Date: Mon, 30 Aug 2021 12:20:03 +0200
Subject: [PATCH] Drop custom opendir/readdir implementation in Windows
Windows doesn't have these functions, but MinGW provides
them as part of its crt library.
Our own stub implementation had some issues which caused
an error to trigger a loop which resulted in a hanging
process when running chicken-install -update-db
---
NEWS | 3 ++-
file.scm | 82 ++--
2 files changed, 4 insertions(+), 81 deletions(-)
diff --git a/NEWS b/NEWS
index c30c4395..00e79659 100644
--- a/NEWS
+++ b/NEWS
@@ -3,7 +3,8 @@
- Core libraries
- The srfi-17 module now exports the `getter-with-setter` and `setter`
procedures, not just the set! macro (thanks to Lassi Kortela)
-
+ - Fix hang in chicken-install -update-db on Windows (thanks to Mark
+Fisher for reporting and Jani Hakala for debugging and patch).
5.3.0rc1
diff --git a/file.scm b/file.scm
index 18ce00f1..56e4c909 100644
--- a/file.scm
+++ b/file.scm
@@ -65,86 +65,8 @@
# define C_mkdir(str) C_fix(mkdir(C_c_string(str)))
#endif
-#if !defined(_WIN32) || defined(__CYGWIN__)
-# include
-# include
-#else
-struct dirent
-{
-char * d_name;
-};
-
-typedef struct
-{
-struct _finddata_t fdata;
-int handle;
-struct dirent current;
-} DIR;
-
-static DIR * C_fcall
-opendir(const char *name)
-{
-int name_len = strlen(name);
-int what_len = name_len + 3;
-DIR *dir = (DIR *)malloc(sizeof(DIR));
-char *what;
-if (!dir)
-{
- errno = ENOMEM;
- return NULL;
-}
-what = (char *)malloc(what_len);
-if (!what)
-{
- free(dir);
- errno = ENOMEM;
- return NULL;
-}
-C_strlcpy(what, name, what_len);
-if (strchr("\\/", name[name_len - 1]))
- C_strlcat(what, "*", what_len);
-else
- C_strlcat(what, "\\*", what_len);
-
-dir->handle = _findfirst(what, >fdata);
-if (dir->handle == -1)
-{
- free(what);
- free(dir);
- return NULL;
-}
-dir->current.d_name = NULL; /* as the first-time indicator */
-free(what);
-return dir;
-}
-
-static int C_fcall
-closedir(DIR * dir)
-{
-if (dir)
-{
- int res = _findclose(dir->handle);
- free(dir);
- return res;
-}
-return -1;
-}
-
-static struct dirent * C_fcall
-readdir(DIR * dir)
-{
-if (dir)
-{
- if (!dir->current.d_name /* first time after opendir */
- || _findnext(dir->handle, >fdata) != -1)
- {
- dir->current.d_name = dir->fdata.name;
- return >current;
- }
-}
-return NULL;
-}
-#endif
+#include
+#include
#define C_opendir(s,h) C_set_block_item(h, 0, (C_word) opendir(C_c_string(s)))
#define C_readdir(h,e) C_set_block_item(e, 0, (C_word) readdir((DIR *)C_block_item(h, 0)))
--
2.31.1
signature.asc
Description: PGP signature
