deprecation warnings with Guile 2.2.2

DoneSubmitted by Ricardo Wurmus.
Details
4 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
normal
R
R
Ricardo Wurmus wrote on 30 May 2017 22:31
(address . bug-guix@gnu.org)
87wp8y2ijw.fsf@elephly.net
I get a couple of deprecation warnings with Guile 2.2.2, for example
Import (ice-9 threads) to have access to `current-processor-count'. `_IOFBF' is deprecated. Use the symbol 'block instead.
I only see them after “export GUILE_WARN_DEPRECATED=detailed”. Withoutthat variable I get a block of text that informs me that deprecatedfeatures have been used.
This happens especially when running “make” or when not all files havebeen compiled.
-- Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAChttps://elephly.net
L
L
Ludovic Courtès wrote on 31 May 2017 23:00
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 27152@debbugs.gnu.org)
87h90091y4.fsf@gnu.org
Hi,
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (5 lines)> I get a couple of deprecation warnings with Guile 2.2.2, for example>> Import (ice-9 threads) to have access to `current-processor-count'.> `_IOFBF' is deprecated. Use the symbol 'block instead.
We can fix the first one with #:use-module (ice-9 threads).
The second one is just a pain: in 2.2 one is supposed to write
(setvbuf port 'block)
instead of
(setvbuf port _IOFBF)
So we could do:
(cond-expand (guile-2.2 (define _IOFBF 'block)) (else #t))
in some central place (that doesn’t exist), but really, that’s annoying.
So I’m tempted to do nothing.
Note that normally users do not see these deprecation warnings at all.
Thoughts?
Ludo’.
M
M
Maxim Cournoyer wrote on 3 Jun 2017 02:39
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAN-vT6T8_ajiXi0crfywO7sM8Wqj6+GmhgH3rYVn8-PT0BfBMA@mail.gmail.com
On Wed, May 31, 2017 at 2:00 PM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (25 lines)> Hi,>> Ricardo Wurmus <rekado@elephly.net> skribis:>> > I get a couple of deprecation warnings with Guile 2.2.2, for example> >> > Import (ice-9 threads) to have access to `current-processor-count'.> > `_IOFBF' is deprecated. Use the symbol 'block instead.>> We can fix the first one with #:use-module (ice-9 threads).>> The second one is just a pain: in 2.2 one is supposed to write>> (setvbuf port 'block)>> instead of>> (setvbuf port _IOFBF)>> So we could do:>> (cond-expand (guile-2.2 (define _IOFBF 'block))> (else #t))>
in some central place (that doesn’t exist), but really, that’s annoying.
Toggle quote (8 lines)>> So I’m tempted to do nothing.>> Note that normally users do not see these deprecation warnings at all.>> Thoughts?>
Why not let good old sed have a run at it? Seems like a simple find andreplace operation, and 'block looks nicer than _IOFBF to my eyes.
Maxim
Attachment: file
M
M
Mark H Weaver wrote on 3 Jun 2017 03:20
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
871sr1yiik.fsf@netris.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (34 lines)> On Wed, May 31, 2017 at 2:00 PM, Ludovic Courtès <ludo@gnu.org> wrote:>> Ricardo Wurmus <rekado@elephly.net> skribis:>> > I get a couple of deprecation warnings with Guile 2.2.2, for example> >> > Import (ice-9 threads) to have access to `current-processor-count'.> > `_IOFBF' is deprecated. Use the symbol 'block instead.>> We can fix the first one with #:use-module (ice-9 threads).>> The second one is just a pain: in 2.2 one is supposed to write>> (setvbuf port 'block)>> instead of>> (setvbuf port _IOFBF)>> So we could do:>> (cond-expand (guile-2.2 (define _IOFBF 'block))> (else #t))>> in some central place (that doesn’t exist), but really, that’s annoying.>> So I’m tempted to do nothing.>> Note that normally users do not see these deprecation warnings at all.>> Thoughts?>> Why not let good old sed have a run at it? Seems like a simple find and replace operation, and 'block looks nicer than _IOFBF to my eyes.
If we did that, then Guix would stop working with guile-2.0. Given thatguile-2.2 is not yet available from many popular distros, I think itwould be unwise to drop guile-2.0 at this time.
Mark
M
M
Maxim Cournoyer wrote on 3 Jun 2017 06:43
(name . Mark H Weaver)(address . mhw@netris.org)
87h8zxr89y.fsf@gmail.com
Hi Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (40 lines)> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>> On Wed, May 31, 2017 at 2:00 PM, Ludovic Courtès <ludo@gnu.org> wrote:>>>> Ricardo Wurmus <rekado@elephly.net> skribis:>>>> > I get a couple of deprecation warnings with Guile 2.2.2, for example>> >>> > Import (ice-9 threads) to have access to `current-processor-count'.>> > `_IOFBF' is deprecated. Use the symbol 'block instead.>>>> We can fix the first one with #:use-module (ice-9 threads).>>>> The second one is just a pain: in 2.2 one is supposed to write>>>> (setvbuf port 'block)>>>> instead of>>>> (setvbuf port _IOFBF)>>>> So we could do:>>>> (cond-expand (guile-2.2 (define _IOFBF 'block))>> (else #t))>>>> in some central place (that doesn’t exist), but really, that’s annoying.>>>> So I’m tempted to do nothing.>>>> Note that normally users do not see these deprecation warnings at all.>>>> Thoughts?>>>> Why not let good old sed have a run at it? Seems like a simple find and replace operation, and 'block looks nicer than _IOFBF to my eyes.>> If we did that, then Guix would stop working with guile-2.0. Given that> guile-2.2 is not yet available from many popular distros, I think it> would be unwise to drop guile-2.0 at this time.
Isn't Guile included in the Guix binary releases? I would have thoughtso. Otherwise, I just tried "guix pack guile@2.2" and the resultingarchive is 40 MiB.
I'm not saying it's worth it, but it's an option.
Maxim
M
M
Mark H Weaver wrote on 4 Jun 2017 07:18
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
871sr0wcto.fsf@netris.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (14 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>>>> Why not let good old sed have a run at it? Seems like a simple find>>> and replace operation, and 'block looks nicer than _IOFBF to my>>> eyes.>>>> If we did that, then Guix would stop working with guile-2.0. Given that>> guile-2.2 is not yet available from many popular distros, I think it>> would be unwise to drop guile-2.0 at this time.>> Isn't Guile included in the Guix binary releases?
Yes, but that's not the only supported method to install Guix. While Iacknowledge that most new users are happy to use our binary tarball,many users prefer to compile our source tarball, or to try out a Guixpackage provided by their existing distribution.
Security conscious users tend to be nervous about entrusting theircomputer's security to a source of precompiled binaries that is new tothem.
While it's true that they will need our bootstrap binaries, and thatthey are highly likely to end up using our binary substitutes beforelong, it nonetheless seems to me that it is best not to ask newcomers totrust a large binary from us as their first step into our community,without providing other easy methods that are more comfortable to them.Users are comfortable installing a package from a distro that they'vealready put their trust in.
So, I would prefer to continue supporting guile-2.0 until guile-2.2 ismore widely deployed in popular distros, or at least until it becomes ahassle to continue supporting guile-2.0.
I'll also mention that there's apparently an unresolved bug somewhere(guile2.2-ssh?) that prevents us from using guix-based-on-guile-2.2 onhydra.gnu.org:
https://bugs.gnu.org/26976
Mark
M
M
Maxim Cournoyer wrote on 4 Jun 2017 07:51
(name . Mark H Weaver)(address . mhw@netris.org)
878tl8pag3.fsf@gmail.com
Hello Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (45 lines)> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>> Mark H Weaver <mhw@netris.org> writes:>>>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>>>>>> Why not let good old sed have a run at it? Seems like a simple find>>>> and replace operation, and 'block looks nicer than _IOFBF to my>>>> eyes.>>>>>> If we did that, then Guix would stop working with guile-2.0. Given that>>> guile-2.2 is not yet available from many popular distros, I think it>>> would be unwise to drop guile-2.0 at this time.>>>> Isn't Guile included in the Guix binary releases?>> Yes, but that's not the only supported method to install Guix. While I> acknowledge that most new users are happy to use our binary tarball,> many users prefer to compile our source tarball, or to try out a Guix> package provided by their existing distribution.>> Security conscious users tend to be nervous about entrusting their> computer's security to a source of precompiled binaries that is new to> them.>> While it's true that they will need our bootstrap binaries, and that> they are highly likely to end up using our binary substitutes before> long, it nonetheless seems to me that it is best not to ask newcomers to> trust a large binary from us as their first step into our community,> without providing other easy methods that are more comfortable to them.> Users are comfortable installing a package from a distro that they've> already put their trust in.>> So, I would prefer to continue supporting guile-2.0 until guile-2.2 is> more widely deployed in popular distros, or at least until it becomes a> hassle to continue supporting guile-2.0.>> I'll also mention that there's apparently an unresolved bug somewhere> (guile2.2-ssh?) that prevents us from using guix-based-on-guile-2.2 on> hydra.gnu.org:>> https://bugs.gnu.org/26976>> Mark
OK, I understand better your point of view now, thanks for taking thetime to explain it in details! I'd be somewhat concerned though aboutGuix sooner than later not running smoothly on Guile 2.0 due to the vastmajority of users using and testing with Guile 2.2 rather than Guile2.0. There was some breaking changes in 2.2, and it seems like wanting tosupport both might lead to code complexity or restraint that wouldotherwise allow simplifications and clean-ups of the code base.
Also, nothing is stopping security minded individuals from buildingGuile 2.2 from sources, so the argument about security seems a bit mootto me.
But I will leave it to the Guix maintainers to decide what works bestfor minimizing their load :)
Thanks again for sharing your thoughts,
Maxim
M
M
Mark H Weaver wrote on 5 Jun 2017 00:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87h8zvv28h.fsf@netris.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (59 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>>>> Mark H Weaver <mhw@netris.org> writes:>>>>>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:>>>>>>>>> Why not let good old sed have a run at it? Seems like a simple find>>>>> and replace operation, and 'block looks nicer than _IOFBF to my>>>>> eyes.>>>>>>>> If we did that, then Guix would stop working with guile-2.0. Given that>>>> guile-2.2 is not yet available from many popular distros, I think it>>>> would be unwise to drop guile-2.0 at this time.>>>>>> Isn't Guile included in the Guix binary releases?>>>> Yes, but that's not the only supported method to install Guix. While I>> acknowledge that most new users are happy to use our binary tarball,>> many users prefer to compile our source tarball, or to try out a Guix>> package provided by their existing distribution.>>>> Security conscious users tend to be nervous about entrusting their>> computer's security to a source of precompiled binaries that is new to>> them.>>>> While it's true that they will need our bootstrap binaries, and that>> they are highly likely to end up using our binary substitutes before>> long, it nonetheless seems to me that it is best not to ask newcomers to>> trust a large binary from us as their first step into our community,>> without providing other easy methods that are more comfortable to them.>> Users are comfortable installing a package from a distro that they've>> already put their trust in.>>>> So, I would prefer to continue supporting guile-2.0 until guile-2.2 is>> more widely deployed in popular distros, or at least until it becomes a>> hassle to continue supporting guile-2.0.>>>> I'll also mention that there's apparently an unresolved bug somewhere>> (guile2.2-ssh?) that prevents us from using guix-based-on-guile-2.2 on>> hydra.gnu.org:>>>> https://bugs.gnu.org/26976>>>> Mark>> OK, I understand better your point of view now, thanks for taking the> time to explain it in details! I'd be somewhat concerned though about> Guix sooner than later not running smoothly on Guile 2.0 due to the vast> majority of users using and testing with Guile 2.2 rather than Guile> 2.0. There was some breaking changes in 2.2, and it seems like wanting to> support both might lead to code complexity or restraint that would> otherwise allow simplifications and clean-ups of the code base.>> Also, nothing is stopping security minded individuals from building> Guile 2.2 from sources, so the argument about security seems a bit moot> to me.
It's true that security conscious users would still have the option ofbuilding Guix, Guile, GnuTLS, and maybe some other prerequisites fromsource code, but that's a lot of work to try Guix for the first time.
The other option currently available to them is to install a 'guix'package from their distro, but I guess that most of those distropackages would have to be dropped (or not upgraded anytime soon) if westop supporting guile-2.0.
Having said all of this, I acknowledge that it's not a strong argument,and if it starts becoming difficult to support guile-2.0, then we shoulddrop that support. I don't feel strongly about it.
Toggle quote (2 lines)> Thanks again for sharing your thoughts,
Likewise, thanks for the discussion!
Mark
L
L
Ludovic Courtès wrote on 26 Aug 2017 12:08
control message for bug #27152
(address . control@debbugs.gnu.org)
87bmn2bpzj.fsf@gnu.org
tags 27152 wontfixclose 27152
?
Your comment

This issue is archived.

To comment on this conversation send email to 27152@debbugs.gnu.org