unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#27152: deprecation warnings with Guile 2.2.2
@ 2017-05-30 20:31 Ricardo Wurmus
  2017-05-31 21:00 ` Ludovic Courtès
  0 siblings, 1 reply; 8+ messages in thread
From: Ricardo Wurmus @ 2017-05-30 20:31 UTC (permalink / raw)
  To: 27152

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”.  Without
that variable I get a block of text that informs me that deprecated
features have been used.

This happens especially when running “make” or when not all files have
been compiled.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-05-30 20:31 bug#27152: deprecation warnings with Guile 2.2.2 Ricardo Wurmus
@ 2017-05-31 21:00 ` Ludovic Courtès
  2017-06-03  0:39   ` Maxim Cournoyer
  0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2017-05-31 21:00 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 27152

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.

So I’m tempted to do nothing.

Note that normally users do not see these deprecation warnings at all.

Thoughts?

Ludo’.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-05-31 21:00 ` Ludovic Courtès
@ 2017-06-03  0:39   ` Maxim Cournoyer
  2017-06-03  1:20     ` Mark H Weaver
  0 siblings, 1 reply; 8+ messages in thread
From: Maxim Cournoyer @ 2017-06-03  0:39 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 27152

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Wed, May 31, 2017 at 2:00 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> 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.
>
> 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.

Maxim

[-- Attachment #2: Type: text/html, Size: 1701 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-06-03  0:39   ` Maxim Cournoyer
@ 2017-06-03  1:20     ` Mark H Weaver
  2017-06-03  4:43       ` Maxim Cournoyer
  0 siblings, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2017-06-03  1:20 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 27152

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.

       Mark

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-06-03  1:20     ` Mark H Weaver
@ 2017-06-03  4:43       ` Maxim Cournoyer
  2017-06-04  5:18         ` Mark H Weaver
  0 siblings, 1 reply; 8+ messages in thread
From: Maxim Cournoyer @ 2017-06-03  4:43 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 27152

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> 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 thought
so. Otherwise, I just tried "guix pack guile@2.2" and the resulting
archive is 40 MiB.

I'm not saying it's worth it, but it's an option.

Maxim

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-06-03  4:43       ` Maxim Cournoyer
@ 2017-06-04  5:18         ` Mark H Weaver
  2017-06-04  5:51           ` Maxim Cournoyer
  0 siblings, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2017-06-04  5:18 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 27152

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-06-04  5:18         ` Mark H Weaver
@ 2017-06-04  5:51           ` Maxim Cournoyer
  2017-06-04 22:04             ` Mark H Weaver
  0 siblings, 1 reply; 8+ messages in thread
From: Maxim Cournoyer @ 2017-06-04  5:51 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 27152

Hello Mark,

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.

But I will leave it to the Guix maintainers to decide what works best
for minimizing their load :)

Thanks again for sharing your thoughts,

Maxim

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27152: deprecation warnings with Guile 2.2.2
  2017-06-04  5:51           ` Maxim Cournoyer
@ 2017-06-04 22:04             ` Mark H Weaver
  0 siblings, 0 replies; 8+ messages in thread
From: Mark H Weaver @ 2017-06-04 22:04 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 27152

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> 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 of
building Guix, Guile, GnuTLS, and maybe some other prerequisites from
source 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 distro
packages would have to be dropped (or not upgraded anytime soon) if we
stop 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 should
drop that support.  I don't feel strongly about it.

> Thanks again for sharing your thoughts,

Likewise, thanks for the discussion!

       Mark

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-06-04 22:05 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-30 20:31 bug#27152: deprecation warnings with Guile 2.2.2 Ricardo Wurmus
2017-05-31 21:00 ` Ludovic Courtès
2017-06-03  0:39   ` Maxim Cournoyer
2017-06-03  1:20     ` Mark H Weaver
2017-06-03  4:43       ` Maxim Cournoyer
2017-06-04  5:18         ` Mark H Weaver
2017-06-04  5:51           ` Maxim Cournoyer
2017-06-04 22:04             ` Mark H Weaver

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).