[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW open-process, take N
From: |
Eli Zaretskii |
Subject: |
Re: MinGW open-process, take N |
Date: |
Tue, 12 Jul 2016 17:46:42 +0300 |
> From: Andy Wingo <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Tue, 12 Jul 2016 16:05:35 +0200
>
> > It's hard for me to build Guile from Git, due to the additional
> > prerequisites that needs.
>
> Understood, in that case please note that there is also an automatic
> build service that runs "make" and "make dist" to make tarballs:
>
> https://hydra.nixos.org/job/gnu/guile-2-0/tarball
>
> Just click through and you can download a tarball. For example:
>
>
> https://hydra.nixos.org/build/37557639/download/3/guile-2.0.11.238-e1cb7.tar.gz
>
> There is .xz too. This service exists for Guile master too:
>
> https://hydra.nixos.org/job/gnu/guile-master/tarball
Thanks, I will try that when I have time, if Guile is not released
before that.
> getuid is used in boot-9.scm, so if it's unavailable, we cannot build
> Guile without making changes in the Scheme code. I don't know if that
> convinces you, and I have no practical way of counting their uses in
> Guile programs outside Guile itself.
>
> But in reality the getuid is of this form:
>
> (define (load-user-init)
> (let* ((home (or (getenv "HOME")
> (false-if-exception (passwd:dir (getpwuid (getuid))))
> file-name-separator-string)) ;; fallback for cygwin etc.
> (init-file (in-vicinity home ".guile")))
> (if (file-exists? init-file)
> (primitive-load init-file))))
>
> So, no problem.
Won't this fail to compile during boot, or at least produce a warning?
> > The only other issue I see is the type of the value returned by
> > start_child, and as result by scm_open_process. On Windows, the value
> > returned has the type HANDLE, which is actually a pointer in disguise.
> > I used intptr_t for that, but you changed it to just int. This will
> > not work in 64-bit MinGW builds, where a pointer is a 64-bit type. I
> > think we should go back to intptr_t, and also change the conversion to
> > the value returned by scm_open_process, since scm_from_int will AFAIK
> > not support 64-bit integer types. Note that the MinGW waitpid
> > implementation also expects to get a valu that is interpreted as a
> > handle.
>
> Hummmm, I don't know, there are a number of other things in that file
> which treat PIDs as ints (scm_waitpid, scm_getppid, etc etc etc). I
> think that would need to be another patch that adds scm_from_pid_t and
> scm_to_pid_t and so on. And then what is this?
>
> http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/12235
The process ID is indeed an int, but my code hides a process handle
inside it.
> I will apply your patch though and I look forward to hearing if it works
> for you :)
The above is not a problem for me, since I use the 32-bit MinGW, where
a handle is a 32-bit type. This is only a potential problem in 64-bit
builds.
Thanks.
- MinGW open-process, take N, Andy Wingo, 2016/07/11
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/12
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/12
- Re: MinGW open-process, take N,
Eli Zaretskii <=
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16