And another deprecation joke

And another deprecation joke

[David Kastrup]

`dimensions->uniform-array' is deprecated.  Use `make-typed-array' instead.

Unfortunately, this was not even called in the application.

The actual function called was make-uniform-vector.

If we look at the documentation of make-typed-array, we find

<URL:http://www.gnu.org/software/guile/manual/html_node/Array-Procedures.html>

— Scheme Procedure: make-typed-array type fill bound ...
— C Function: scm_make_typed_array (type, fill, bounds)

    Create and return an array that has as many dimensions as there are
    bounds and (maybe) fill it with fill.

    The underlying storage vector is created according to type, which
    must be a symbol whose name is the `vectag' of the array as
    explained above, or #t for ordinary, non-specialized arrays.

This, however, is a lie, since there is no place above where "vectag"
would be explained.  There is an explanation about how it will be
printed as part of an array, but not how it is specified.

Would it please be possible

a) to not just deprecate some function when there are _callers_ in the
   guile code base that are _not_ explicitly deprecated
b) make sure that the recommended replacements are actually
   _documented_?

This is not the first such "deprecation" I have encountered, and it
shows a blatant disrespect of the user base.

-- 
David Kastrup

Re: And another deprecation joke

[Noah Lavine]

Hello,

> This, however, is a lie, since there is no place above where "vectag"
> would be explained.  There is an explanation about how it will be
> printed as part of an array, but not how it is specified.
>
> Would it please be possible
>
> a) to not just deprecate some function when there are _callers_ in the
>   guile code base that are _not_ explicitly deprecated
> b) make sure that the recommended replacements are actually
>   _documented_?
>
> This is not the first such "deprecation" I have encountered, and it
> shows a blatant disrespect of the user base.

Yes, I am well aware that the Guile documentation is missing some
pieces. I didn't know about the deprecation issue, but it fits.

If it makes you feel better though, I suspect that both of these
problems began before the current maintainers took over. As long as I
have been watching the mailing list, Andy and Ludo have been extremely
thorough, and I do not think they would have done something like this.

What you are noticing now is that Guile has some old bits of code that
were not implemented up to the standards we currently have. Since you
seem to be using all the weird corners of Guile, you have the
un-enviable job of going through and finding all of these places so we
can fix them.

I'm not going to solve this problem, because I don't know how, but I
did want to say that I appreciate you finding these things. It is not
a fun job, but it should be done.

Thanks,
Noah

Re: And another deprecation joke

[David Kastrup]

Noah Lavine <noah.b.lavine@gmail.com> writes:

> What you are noticing now is that Guile has some old bits of code that
> were not implemented up to the standards we currently have. Since you
> seem to be using all the weird corners of Guile, you have the
> un-enviable job of going through and finding all of these places so we
> can fix them.

I don't actually consider most of the corners that hit me so far all
that weird: actually they have been either rather basic, or I've had my
nose explicitly rubbed into them by Guile (like with the deprecation
warnings).  That there is no information about non-literal symbol
manipulation in the Guile-1.8 documentation (except mentioning one
should use modules, and the C interface SCM_define) is appalling.  The
Guile-2.0 documentation still does not give any Scheme interfaces, but
at least the C interface descriptions for modules make it easier
guessing the Scheme interfaces.

The Guile maintainers make it a point to say they won't bother with
Guile-1.8 documentation, but it is not like Guile-1.8 is going to
disappear from software distributions anytime soon due to compatibility
issues.

> I'm not going to solve this problem, because I don't know how, but I
> did want to say that I appreciate you finding these things. It is not
> a fun job, but it should be done.

It is not fun, but it is not as much a job rather than an impediment.
It is certainly not a fun job to hear me crash and burn either.  But I
doubt that crashing and burning silently, as others apparently do, will
be much preferable.

-- 
David Kastrup

Re: And another deprecation joke

[Andy Wingo]

On Wed 07 Dec 2011 13:58, David Kastrup <dak@gnu.org> writes:

> `dimensions->uniform-array' is deprecated.  Use `make-typed-array' instead.
>
> Unfortunately, this was not even called in the application.
>
> The actual function called was make-uniform-vector.

Ah, interesting.

You might not be a native english speaker; I don't know.  However, the
proper word is "bug", not "lie" or "disrespect".  Thanks for finding
them and pointing them out!  In the future though, please be nice, on
this list.

Thanks,

Andy
-- 
http://wingolog.org/

Re: And another deprecation joke

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 07 Dec 2011 13:58, David Kastrup <dak@gnu.org> writes:
>
>> `dimensions->uniform-array' is deprecated.  Use `make-typed-array' instead.
>>
>> Unfortunately, this was not even called in the application.
>>
>> The actual function called was make-uniform-vector.
>
> Ah, interesting.
>
> You might not be a native english speaker; I don't know.  However, the
> proper word is "bug", not "lie" or "disrespect".

Few people are native speakers: that capacity is usually acquired later
in life.

While I can't claim this status, I don't find that

    This, however, is a bug, since there is no place above where
    "vectag" would be explained.

and particularly

    This is not the first such "deprecation" I have encountered, and it
    shows a blatant bug of the user base.

are convincing replacements.  In the first case, "falsehood" would be a
less loaded term for the same situation.  In the second, "disregard".
And I am afraid it does not get less loaded than that.  The source of
information for users is the documentation.  Changing or adding code and
not documenting it does not cater to users' but to developers' needs.

And it is not like I go hunting for nitpicks.  I try using Guile, and
those things hit me right in the face.  The "deprecation warnings" are
_explicitly_ coded, and obviously nobody bothered checking even
superficially that the user-available documentation documented the
specified replacements.

Whatever procedures lead to that result, it does not appear that they
have working policies or mechanisms that would ascertain either end user
viability (since the end user gets to see the respective deprecation
warnings) or application programmer viability (since the application
programmer is responsible for doing the code replacements).

So when I talk about "shows a blatant disrespect", this does not locate
the source of that disrespect which can also be inherent in the
procedures leading to such results.

It would appear to me that the procedures related to deprecation of
functions could likely make use of some amendments leading to more
consistent usability of the results.

-- 
David Kastrup

Re: And another deprecation joke

[rixed]

You seam to believe that there is on one hand the guile developers and on
another one the guile users, facing each others on the ground of some kind
of contract that's being somewhat abused by the developers.  In reality, guile
is a project belonging to the commons and such demarcation does not exist: we
are all using guile as well as contributing to it (and you are doing some good
contributions by reporting all these bugs), and we all stands responsible for
its flaws.

I'm also having some ups and downs trying to use guile in a "professional"
project, having made some promise to my contractors to met some objectives;
but as far as I remember guile community never promised me anything neither
contractually nor informally. Users and providers are an artificial creation
of our times, there is no such thing here.

Re: And another deprecation joke

[David Kastrup]

rixed@happyleptic.org writes:

> You seam to believe that there is on one hand the guile developers and
> on another one the guile users, facing each others on the ground of
> some kind of contract that's being somewhat abused by the developers.
> In reality, guile is a project belonging to the commons and such
> demarcation does not exist: we are all using guile as well as
> contributing to it (and you are doing some good contributions by
> reporting all these bugs), and we all stands responsible for its
> flaws.

Projects have guidelines and policies, and development works in
transactions.  Deprecating features without providing a documented
alternative is a half-transaction.  In a sane project, they get finished
or unrolled.

There obviously isn't sufficient awareness that leaving them lying
around in half-finished and broken state is a bad idea.

I am trying to make a point that sticks.  This is not a question about
who should be doing what.  If nothing gets done, that's the way the
cookie crumbles.  It is a free project after all.

But if things get done that do more damage than good by making it
impossible to work with Guile if you are not the one having done the
change, it would be better if nothing got done.

And the more changes get done that make it impossible to work with
Guile, the less people will be found that will work on any aspect of
Guile.

More resources are _destroyed_ than used in that manner.  And you
complain that I try making this a sore point with people.

> I'm also having some ups and downs trying to use guile in a
> "professional" project, having made some promise to my contractors to
> met some objectives; but as far as I remember guile community never
> promised me anything neither contractually nor informally. Users and
> providers are an artificial creation of our times, there is no such
> thing here.

For every change, there is one provider and multiple users.  If the
change is not intended to have the qualities where anybody but the
provider could use it, then it should stay out of the central
repository.  Otherwise, you get dozens of half-baked half-documented
implementations of the same functionality in your code base because
nobody can work with the undocumented half-baked implementation of
somebody else and just commits his own version.  The next one to come
around and look closely finds a heap of things he could almost but not
quite use, and after investing a week of work, throws up his hands in
disgust and chooses a different tool.

This is not a question of available manpower.  It is one of discipline
and policies.  I don't know the control structures of this project.  So
I make this a sore point with anybody bothering enough about it to be
reading the developer list.  That's the best I can do.  Making people
annoyed, incredulous, possibly even ashamed about how they permit their
project get destroyed by sloppiness, because that sloppiness costs them
their user and in following their developer base.

If I wanted an incoherent junk yard of half-features, I would start with
Common Lisp instead of Scheme.

-- 
David Kastrup

Re: And another deprecation joke

[Andy Wingo]

Hi David,

Again, thank you for your bug reports, but Guile development is not
driven by shame.  So please keep up your (useful!) bug reports, but try
to give them a more positive flavor :)

Thanks,

Andy
-- 
http://wingolog.org/

Re: And another deprecation joke

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> Again, thank you for your bug reports, but Guile development is not
> driven by shame.

Obviously.

> So please keep up your (useful!) bug reports, but try to give them a
> more positive flavor :)

Could you give an example how to deliver with a positive flavor a report
about deprecation messages talking about the wrong function, telling you
in vague terms to use something instead for which no documentation is
available, with both the state of documentation and message apparently
being the same for years?

I mean, reporting to the authorities even something as unsavory as a bug
has a sinister flavor to it after all.  It has found a home and place it
has been enjoying for years in peace and company.

-- 
David Kastrup

Re: And another deprecation joke

[Andy Wingo]

On Thu 08 Dec 2011 21:32, David Kastrup <dak@gnu.org> writes:

>> So please keep up your (useful!) bug reports, but try to give them a
>> more positive flavor :)
>
> Could you give an example how to deliver with a positive flavor a report
> about deprecation messages talking about the wrong function, telling you
> in vague terms to use something instead for which no documentation is
> available, with both the state of documentation and message apparently
> being the same for years?

Sure!  Here's one from about a week ago:

  http://thread.gmane.org/gmane.lisp.guile.bugs/5953

There are many more there.

Using bug-guile also has the advantage that it's given an entry in
debbugs, so that we don't forget about it.

Regards,

Andy
-- 
http://wingolog.org/

Re: And another deprecation joke

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Thu 08 Dec 2011 21:32, David Kastrup <dak@gnu.org> writes:
>
>>> So please keep up your (useful!) bug reports, but try to give them a
>>> more positive flavor :)
>>
>> Could you give an example how to deliver with a positive flavor a report
>> about deprecation messages talking about the wrong function, telling you
>> in vague terms to use something instead for which no documentation is
>> available, with both the state of documentation and message apparently
>> being the same for years?
>
> Sure!  Here's one from about a week ago:
>
>   http://thread.gmane.org/gmane.lisp.guile.bugs/5953
>
> There are many more there.
>
> Using bug-guile also has the advantage that it's given an entry in
> debbugs, so that we don't forget about it.

An application "bug-guile" is not available as a command line tool, or
as a guile function in a standard installation of Guile on Ubuntu.

The Guile reference manual for the currently distributed version (1.8.8)
has a long chapter "Reporting Bugs" that starts with

    Any problems with the installation should be reported to
    <bug-guile@gnu.org>.

An application "guile-bug" is mentioned nowhere.  The most up to date
version of the reference manual, namely that in the repository, can be
read at
<URL:http://hydra.nixos.org/build/1574618/download/2/guile.html/Reporting-Bugs.html#Reporting-Bugs>.
And look and behold, it does not contain a mention of bug-guile either.

You really need to get rid of this "oral tradition" habit and actually
bother writing things down in the manual where people have a chance to
see them.  I often get the "oh, we won't bother updating the manual in
the 1.8 Guile branch anymore, that is so yesterday" brush-off, but it is
not like you actually bother updating the 2.0 Guile manual all that much
either.

So how about starting with the bug reporting instructions, and actually
writing down what a reporter should do to avoid being told his way of
reporting bugs has gone out of fashion?

Then you have a better reason to tell people they are doing it wrong.

-- 
David Kastrup

Re: And another deprecation joke

[dsmich]

---- David Kastrup <dak@gnu.org> wrote: 
> Andy Wingo <wingo@pobox.com> writes:
> 
> > On Thu 08 Dec 2011 21:32, David Kastrup <dak@gnu.org> writes:
> >
> >>> So please keep up your (useful!) bug reports, but try to give them a
> >>> more positive flavor :)
> >>
> >> Could you give an example how to deliver with a positive flavor a report
> >> about deprecation messages talking about the wrong function, telling you
> >> in vague terms to use something instead for which no documentation is
> >> available, with both the state of documentation and message apparently
> >> being the same for years?
> >
> > Sure!  Here's one from about a week ago:
> >
> >   http://thread.gmane.org/gmane.lisp.guile.bugs/5953
> >
> > There are many more there.
> >
> > Using bug-guile also has the advantage that it's given an entry in
> > debbugs, so that we don't forget about it.
> 
> An application "bug-guile" is not available as a command line tool, or
> as a guile function in a standard installation of Guile on Ubuntu.
> 
> The Guile reference manual for the currently distributed version (1.8.8)
> has a long chapter "Reporting Bugs" that starts with
> 
>     Any problems with the installation should be reported to
>     <bug-guile@gnu.org>.
> 
> An application "guile-bug" is mentioned nowhere.

"bug-guile@gnu.org" is a mailing list, not an application.  You use your email application to send the bug report.

-Dale

Re: And another deprecation joke

[David Kastrup]

<dsmich@roadrunner.com> writes:

> ---- David Kastrup <dak@gnu.org> wrote: 
>
>> An application "guile-bug" is mentioned nowhere.
>
> "bug-guile@gnu.org" is a mailing list, not an application.  You use
> your email application to send the bug report.

Indeed.  At some point of time I lost sight that this was not the bug
list.

To make a non-bug specific suggestion to developers: try to answer each
question (that is not solely restricted to an individual's problem) by
quoting a manual passage.  Even if it means having to write or rewrite
or reindex that manual passage first.

If you have trouble finding the right passage, so will the user.  If you
feel that the manual passage is not quite right, so will the user.

There will be hundreds of users with the same problem, hopefully.  They
are all capable of reading the manual.  They are not capable of reading
your mind: that's something you have to do yourself, then write up an
answer.

Make it a habit to write a useful answer once.  Then only reference it.
It is more work the first time round.  But if Guile is supposed to be
successful, that first time is going to have dozens of repetitions.

Be prepared for Guile's success.

-- 
David Kastrup

Re: And another deprecation joke

[Andy Wingo]

On Fri 09 Dec 2011 10:23, David Kastrup <dak@gnu.org> writes:

> To make a non-bug specific suggestion to developers: try to answer each
> question (that is not solely restricted to an individual's problem) by
> quoting a manual passage.  Even if it means having to write or rewrite
> or reindex that manual passage first [...]
>
> Be prepared for Guile's success.

Good suggestions, all.

Happy hacking,

Andy
-- 
http://wingolog.org/