askinclude.sty
Herbert Voss
has anybody a working email address of Pablo A. Straub,
the author of the askinclude package?
str...@cs.UMD.EDU didn't work.
Herbert
--
http://PSTricks.tug.org
http://www.dante.de/CTAN/info/math/voss/
Joseph Wright
I think you are going to struggle. A few searches give no hits after
1997 for him!
Joseph Wright
Robin Fairbairns
>On Oct 15, 9:06 am, Herbert Voss <herber...@googlemail.com> wrote:
>> has anybody a working email address of Pablo A. Straub,
>> the author of the askinclude package?
>>
>> str...@cs.UMD.EDU didn't work.
>
>1997 for him!
i suspect i did the patches to make it work for 2e because i couldn't
find him back then, even. there's more in google, now, than there was
in altavista then, and i too couldn't find him in google when i tried
a couple of days ago.
bit sad, really: the beastly package has a licence that precludes it
going into tex-live (though it's in current tex-live, by mistake --
commercial users shouldn't use it).
--
Robin Fairbairns, Cambridge
Joseph Wright
The implication of that is, given his disappearance, someone should re-
implement the functionality in a new version that does not suffer from
the restricted licence.
Joseph Wright
Sébastien Mengin
> The implication of that is, given his disappearance, someone should re-
> implement the functionality in a new version that does not suffer from
> the restricted licence.
And, by the way, add some scripting functionality, so as to be able to
list the files in the current directory and provide auto-completion for
them, for example.
I'm totally unable to do this, but it would be great if it existed :)
--
Sébastien
http://edilibre.net
Robin Fairbairns
it would be great if tex were able to support it.
i'm not sure if luatex could be coaxed into this sort of behaviour,
but it's certainly not something you could do with today's tex
distributions.
--
Robin Fairbairns, Cambridge
Joseph Wright
> =?iso-8859-1?Q?S=E9bastien?= Mengin <sebast...@edilibre.net> writes:
>
> >Le 15-10-2007, Joseph Wright <joseph.wri...@morningstar2.co.uk> a écrit :
> >> The implication of that is, given his disappearance, someone should re-
> >> implement the functionality in a new version that does not suffer from
> >> the restricted licence.
>
> >And, by the way, add some scripting functionality, so as to be able to
> >list the files in the current directory and provide auto-completion for
> >them, for example.
>
> >I'm totally unable to do this, but it would be great if it existed :)
>
> it would be great if tex were able to support it.
>
> i'm not sure if luatex could be coaxed into this sort of behaviour,
> but it's certainly not something you could do with today's tex
> distributions.
> --
> Robin Fairbairns, Cambridge
Before people start suggesting new features, it might be a good idea
to find out why Herbert Voss wants to get hold of Pablo A. Straub. I
guess there must be some reason, which probably means bugs.
More crucially, at this stage no-one has said that they are going to
actually look at this package. I guess if there is a need, and I can
find the time, I might. However, I'm sure others are better
qualified!
Joseph Wright
Herbert Voss
> Before people start suggesting new features, it might be a good idea
> to find out why Herbert Voss wants to get hold of Pablo A. Straub. I
> guess there must be some reason, which probably means bugs.
I am only interested in changing the license to LPPL.
> More crucially, at this stage no-one has said that they are going to
> actually look at this package. I guess if there is a need, and I can
> find the time, I might. However, I'm sure others are better
> qualified!
go on.
Joseph Wright
Okay, I (hope) it won't take too long. I'll look at a
reimplementation, under the LPPL. It strikes me that I will tackle
the problem in a slightly different way. Apart from Sébastien
Mengin's rather hopeful feature request, does anyone have any comments
on how the package currently works.
Will a new name be needed, or is it acceptable to request replacement
of a package by a reimplementation under the same name? If a new name
is needed, I'm open to suggestions!
Joseph Wright
Heiko Oberdiek
> =?iso-8859-1?Q?S=E9bastien?= Mengin <seba...@edilibre.net> writes:
> >Le 15-10-2007, Joseph Wright <joseph...@morningstar2.co.uk> a écrit :
> >> The implication of that is, given his disappearance, someone should re-
> >> implement the functionality in a new version that does not suffer from
> >> the restricted licence.
> >
> >And, by the way, add some scripting functionality, so as to be able to
> >list the files in the current directory and provide auto-completion for
> >them, for example.
> >
> >I'm totally unable to do this, but it would be great if it existed :)
>
> it would be great if tex were able to support it.
>
> i'm not sure if luatex could be coaxed into this sort of behaviour,
I have just written a new package that replaces askinclude.
Of course, auto-completion isn't supported, but the package
lists the files, found in \include of the previous run.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Okay, I (hope) it won't take too long. I'll look at a
> reimplementation, under the LPPL. It strikes me that I will tackle
> the problem in a slightly different way. Apart from Sébastien
> Mengin's rather hopeful feature request, does anyone have any comments
> on how the package currently works.
>
> Will a new name be needed, or is it acceptable to request replacement
> of a package by a reimplementation under the same name? If a new name
> is needed, I'm open to suggestions!
%%% cut %%% askinc.sty %%% cut %%%
%%
%% This is file `askinc.sty',
%% generated with the docstrip utility.
%%
%% The original source files were:
%%
%% askinc.dtx (with options: `package')
%%
%% This is a generated file.
%%
%% Copyright (C) 2007 by Heiko Oberdiek <ober...@uni-freiburg.de>
%%
%% This work may be distributed and/or modified under the
%% conditions of the LaTeX Project Public License, either
%% version 1.3 of this license or (at your option) any later
%% version. The latest version of this license is in
%% http://www.latex-project.org/lppl.txt
%% and version 1.3 or later is part of all distributions of
%% LaTeX version 2005/12/01 or later.
%%
%% This work has the LPPL maintenance status "maintained".
%%
%% This Current Maintainer of this work is Heiko Oberdiek.
%%
%% This work consists of the main source file askinc.dtx
%% and the derived files
%% askinc.sty, askinc.pdf, askinc.ins, askinc.drv.
%%
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{askinc}
[2007/10/15 v1.0 Ask for included files (HO)]%
\def\AskInc@Star{*}
\def\AskInc@Minus{-}
\global\let\AskInc@Answer\AskInc@Star
\def\AskInc@SaveAnswer{%
\if@filesw
\immediate\write\@mainaux{%
\string\gdef\string\AskInc@Answer{\AskInc@Answer}%
}%
\fi
}
\AtEndOfPackage{%
\AtBeginDocument{\AskInc@SaveAnswer}%
}
\RequirePackage{auxhook}[2007/04/06]
\AddLineBeginMainAux{%
\string\providecommand\string\AskInc@AddFile[1]{}%
}
\gdef\AskInc@Files{}
\def\AskInc@AddFile#1{%
\ifx\AskInc@Files\@empty
\gdef\AskInc@Files{#1}%
\else
\g@addto@macro\AskInc@Files{,#1}%
\fi
}
\newcommand{\AskInc@OrgInclude}{}
\let\AskInc@OrgInclude\include
\renewcommand*{\include}[1]{%
\if@filesw
\immediate\write\@mainaux{%
\string\AskInc@AddFile{#1}%
}%
\fi
\AskInc@OrgInclude{#1}%
}
\if@partsw
\PackageWarningNoLine{%
Previous \string\includeonly\space detected,\MessageBreak
therefore asking for files is suppressed%
}%
\expandafter\endinput
\fi
\newcommand{\AskInc@OrgIncludeOnly}{}
\let\AskInc@OrgIncludeOnly\includeonly
\renewcommand*{\includeonly}[1]{%
\PackageWarning{askinc}{%
\string\includeonly\space is disabled%
}%
}
\def\AskInc@AskForFiles{%
\typeout{}%
\typeout{*******************************}%
\typeout{*** Package askinc Question ***}%
\typeout{*******************************}%
\typeout{}%
\ifx\AskInc@Files\@empty
\else
\typeout{Include files detected from previous run:}%
\typeout{ \space`\AskInc@Files'}%
\typeout{}%
\fi
\ifx\AskInc@Answer\@empty
\else
\typeout{Previous answer:}%
\typeout{ \space`\AskInc@Answer'}%
\typeout{}%
\fi
\begingroup
\typeout{Which files do you want to include?}%
\typeout{ \space`*' selects all files}%
\typeout{ \space`-' disables all files}%
\typeout{ \space`' uses previous answer}%
\typeout{ \space`file1,file2' selects `file1' and `file2'}%
\typein[\files]{Enter file list:}
\ifx\files\@empty
\else
\global\let\AskInc@Answer\files
\fi
\endgroup
\ifx\AskInc@Answer\AskInc@Star
\else
\ifx\AskInc@Answer\AskInc@Minus
\AskInc@OrgIncludeOnly{}%
\else
\expandafter\AskInc@OrgIncludeOnly\expandafter{\AskInc@Answer}%
\fi
\fi
}
\AtBeginDocument{\AskInc@AskForFiles}
\endinput
%%
%% End of file `askinc.sty'.
%%% cut %%% askinc.sty %%% cut %%%
CTAN update intended tonight or tomorrow
(with fix of wrong date in auxhook.sty).
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Ulrike Fischer
> Hi,
> has anybody a working email address of Pablo A. Straub,
> the author of the askinclude package?
>
> str...@cs.UMD.EDU didn't work.
http://www.ctan.org/tex-archive/obsolete/help/tex-styles-and-macros.txt
gives another mail:
straub (at) ing (dot) puc (dot) cl
and the web side
www.ing.puc.cl lists an Pablo Straub as exalumni with a contact
mail:
http://www.ing.puc.cl/esp/busquedas/personas/index.html?Terms=straub&action=FindInAll<p=P
(the above address without the "ing (dot)").
And with a certain probability (same university ...) this is the
same Straub:
http://weblogs.udp.cl/base.php?usuario=pablo.straub
--
Ulrike Fischer
Herbert Voss
> Joseph Wright <joseph...@morningstar2.co.uk> wrote:
>
>> Okay, I (hope) it won't take too long. I'll look at a
>> reimplementation, under the LPPL. It strikes me that I will tackle
>> the problem in a slightly different way. Apart from Sébastien
>> Mengin's rather hopeful feature request, does anyone have any comments
>> on how the package currently works.
>>
>> Will a new name be needed, or is it acceptable to request replacement
>> of a package by a reimplementation under the same name? If a new name
>> is needed, I'm open to suggestions!
>
> %%% cut %%% askinc.sty %%% cut %%%
> %%
> %% This is file `askinc.sty',
very good!
But can we have the same package name please. The original
askinclude has no LPPL license, hence it is not forbidden to
choose the same name.
David Kastrup
Huh? The license of the original is completely irrelevant here since
Heiko wrote this from scratch (at least that's what I think the point
of the exercise was supposed to be). And the name alone is not
subject to copyright.
--
David Kastrup
Jim
Jim Hefferon
tug.ctan.org
Joseph Wright
> Joseph Wright <joseph.wri...@morningstar2.co.uk> wrote:
> > Okay, I (hope) it won't take too long. I'll look at a
> > reimplementation, under the LPPL. It strikes me that I will tackle
> > the problem in a slightly different way. Apart from Sébastien
> > Mengin's rather hopeful feature request, does anyone have any comments
> > on how the package currently works.
>
> > Will a new name be needed, or is it acceptable to request replacement
> > of a package by a reimplementation under the same name? If a new name
> > is needed, I'm open to suggestions!
>
> %%% cut %%% askinc.sty %%% cut %%%
> %%
> %% This is file `askinc.sty',
> %% generated with the docstrip utility.
> %%
> %% The original source files were:
> %%
> %% askinc.dtx (with options: `package')
> %%
> %% This is a generated file.
> %%
Hmm, my previous post seems to have been eaten by Google Groups. To
repeat myself:
Ah, I knew someone better qualified would volunteer! I see Ulrike
Fischer also seems to have tracked down the mystery Pablo A. Straub,
so it looks like one way or another I'm off the hook. By the way, I
had thought of a slightly different set of answers, modelled on the
DOS copy command:
"Include <filename> Yes/No/All/eXclude all: ?"
at each \include. I also thought that for the first one, you would
say "Just press <Enter> to keep the same choices as last time", and I
guess I would have retained * and - for compatibility. I realise
this would be a change from the existing package, but it seemed like
possibly like a good idea. Luckily I've not had to work out how to
implement it.
Joseph Wright
Joseph Wright
> > Okay, I (hope) it won't take too long. I'll look at a
> > reimplementation, under the LPPL. It strikes me that I will tackle
> > the problem in a slightly different way. Apart from Sébastien
> > Mengin's rather hopeful feature request, does anyone have any comments
> > on how the package currently works.
>
> > Will a new name be needed, or is it acceptable to request replacement
> > of a package by a reimplementation under the same name? If a new name
> > is needed, I'm open to suggestions!
>
> %%% cut %%% askinc.sty %%% cut %%%
> %%
> %% This is file `askinc.sty',
> %% generated with the docstrip utility.
> %%
> %% The original source files were:
> %%
> %% askinc.dtx (with options: `package')
> %%
> %% This is a generated file.
> %%
Ah, I knew someone better qualified would volunteer! I see Ulrike
Fischer also seems to have tracked down the mystery Pablo A. Straub,
so it looks like one way or another I'm off the hook. Phew!
Joseph Wright
Heiko Oberdiek
> On Oct 15, 4:08 pm, Heiko Oberdiek <oberd...@uni-freiburg.de> wrote:
> > Joseph Wright <joseph.wri...@morningstar2.co.uk> wrote:
> > > Okay, I (hope) it won't take too long. I'll look at a
> > > reimplementation, under the LPPL. It strikes me that I will tackle
> > > the problem in a slightly different way. Apart from Sébastien
> > > Mengin's rather hopeful feature request, does anyone have any comments
> > > on how the package currently works.
> >
> > > Will a new name be needed, or is it acceptable to request replacement
> > > of a package by a reimplementation under the same name? If a new name
> > > is needed, I'm open to suggestions!
> >
> > %%% cut %%% askinc.sty %%% cut %%%
> [...]
> > %%% cut %%% askinc.sty %%% cut %%%
> [...]
> By the way, I
> had thought of a slightly different set of answers, modelled on the
> DOS copy command:
>
> "Include <filename> Yes/No/All/eXclude all: ?"
>
> at each \include. I also thought that for the first one, you would
> say "Just press <Enter> to keep the same choices as last time", and I
> guess I would have retained * and - for compatibility. I realise
> this would be a change from the existing package, but it seemed like
> possibly like a good idea.
Implemented.
Herbert Voss wrote:
> But can we have the same package name please.
Also done.
Release candidate (before upload to CTAN):
http://www.informatik.uni-freiburg.de/~oberdiek/tmp/askinclude.pdf
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Joseph Wright
You seem to have done a very thorough job on that. From first mention
to a very well-implemented package in less than 24 hours - I can only
look on in wonder!
Joseph Wright
Jim
change of license to the LaTeX Project Public License. Thanks to him,
and thanks also to Ulrike for locating the address.
Jim
Dan
Given that it is now covered by LPPL, it seems Heiko will have
to change the name of his new package.
Dan
Herbert Voss
no, the old one should go into /obsolete
Robin Fairbairns
>Dan schrieb:
>> On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
>>> The original package author, Pablo Straub, has graciously agreed to a
>>> change of license to the LaTeX Project Public License. Thanks to him,
>>> and thanks also to Ulrike for locating the address.
>>
>> to change the name of his new package.
>
>no, the old one should go into /obsolete
or something. heiko's package is definitely a different one; does it
provide an interface compatible with the old one? (if not, it should
have a different name -- note i've only scanned the specs.)
we're surely making no change until heiko actually submits.
--
Robin Fairbairns, Cambridge
Joseph Wright
As it is a re-write, I can't quite see that. If I write a new
package, the name is up to me. The license of an existing package
can't prevent me choosing the same name for a new one, as long as what
I've written is not based on the same code (simply doing the same
thing is not enough).* Of course, usually it would be very impolite
to release a new package with the same name as an existing one. But
if the whole point is to re-implement functionality with a more open
license, then surely it is up to the CTAN people which one they have
available (or which one goes where).
Joseph Wright
* Of course, if it is a trademarked term, then things are different.
I'd get into trouble if I wanted to call a new program "Windows", for
example.
Joseph Wright
As it is a re-write, I can't quite see that. If I write a new
package, the name is up to me. The license of an existing package
can't prevent me choosing the same name for a new one, as long as what
I've written is not based on the same code (simply doing the same
thing is not enough).* Of course, usually it would be very impolite
to release a new package with the same name as an existing one. But
if the whole point is to re-implement functionality with a more open
license, then surely it is up to the CTAN people which one they have
available (or which one goes where).
On the other hand, did you mean that "now that the license problem is
solved, Heiko's package is not needed for the original reason, and so
a new name would be appropriate"?
Robin Fairbairns
>On Oct 17, 4:29 pm, Dan <lueck...@uark.edu> wrote:
>> On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
>>
>> > The original package author, Pablo Straub, has graciously agreed to a
>> > change of license to the LaTeX Project Public License. Thanks to him,
>> > and thanks also to Ulrike for locating the address.
>>
>> to change the name of his new package.
>
>package, the name is up to me.
sure.
>The license of an existing package
>can't prevent me choosing the same name for a new one, as long as what
>I've written is not based on the same code (simply doing the same
>thing is not enough).* Of course, usually it would be very impolite
>to release a new package with the same name as an existing one. But
>if the whole point is to re-implement functionality with a more open
>license, then surely it is up to the CTAN people which one they have
>available (or which one goes where).
it would make life damnably difficult for us. we can't (by our own
rules) accept something with the same name as an existing package. i
believe i could convince myself that it would be ok if we believed
that heiko's package is a drop in replacment (with some desirable
upgrade features). otoh, heiko's a phenomenon the community can ill
afford to lose, so we really don't want to offend him.
perhaps we can assign the (now vacant, by the author's request)
maintainership of the package to heiko, and let heiko's own conscience
decide where to go...
>On the other hand, did you mean that "now that the license problem is
>solved, Heiko's package is not needed for the original reason, and so
>a new name would be appropriate"?
remember that heiko's original suggestion was a different name...
--
Robin Fairbairns, Cambridge
Heiko Oberdiek
No, I don't know this version. Also it's a reimplementation.
Thus I am free in choosing the name.
However, It is polite to use another name. Thus I have
already changed it back to `askinc'.
But I am not too satisfied with the current situation, because
we have now two packages for the same purpose,
the old askinclude, superseded now by askinc.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Dan schrieb:
> > On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
> >> The original package author, Pablo Straub, has graciously agreed to a
> >> change of license to the LaTeX Project Public License. Thanks to him,
> >> and thanks also to Ulrike for locating the address.
> >>
> >> Jim
> >
> > Given that it is now covered by LPPL, it seems Heiko will have
> > to change the name of his new package.
>
> no, the old one should go into /obsolete
This I would consider as most user friendly solution to have
one name.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Herbert Voss <herb...@googlemail.com> writes:
> >Dan schrieb:
> >> On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
> >>> The original package author, Pablo Straub, has graciously agreed to a
> >>> change of license to the LaTeX Project Public License. Thanks to him,
> >>> and thanks also to Ulrike for locating the address.
> >>
> >> Given that it is now covered by LPPL, it seems Heiko will have
> >> to change the name of his new package.
> >
> >no, the old one should go into /obsolete
>
> or something. heiko's package is definitely a different one; does it
> provide an interface compatible with the old one?
Yes, this was the intention. But it adds a new major feature
(the possibility to ask for each file). Also it behaves in a different
way, if \includeonly is used (usually a user that wants to use
askinc*, would not want to use \includeonly). This allows
some batch mode use cases, e.g.:
latex '\includeonly{chap1}\input{job}'
without asking and commenting the askinc*.
> we're surely making no change until heiko actually submits.
Ok, I delay the submission to tomorrow to give the solution of the
name problem a further chance.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> On Oct 17, 4:29 pm, Dan <lueck...@uark.edu> wrote:
> > On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
> >
> > > The original package author, Pablo Straub, has graciously agreed to a
> > > change of license to the LaTeX Project Public License. Thanks to him,
> > > and thanks also to Ulrike for locating the address.
> >
> > > Jim
> >
> > Given that it is now covered by LPPL, it seems Heiko will have
> > to change the name of his new package.
> >
> > Dan
>
>
> As it is a re-write, I can't quite see that. If I write a new
> package, the name is up to me. The license of an existing package
> can't prevent me choosing the same name for a new one, as long as what
> I've written is not based on the same code (simply doing the same
> thing is not enough).* Of course, usually it would be very impolite
> to release a new package with the same name as an existing one. But
> if the whole point is to re-implement functionality with a more open
> license, then surely it is up to the CTAN people which one they have
> available (or which one goes where).
>
> On the other hand, did you mean that "now that the license problem is
> solved, Heiko's package is not needed for the original reason, and so
> a new name would be appropriate"?
It's a superset and is able to replace the old one.
A user would have to remember two names for the same purpose.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Herbert Voss
> Joseph Wright <joseph...@morningstar2.co.uk> writes:
>> On Oct 17, 4:29 pm, Dan <lueck...@uark.edu> wrote:
>>> On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
>>>
>>>> The original package author, Pablo Straub, has graciously agreed to a
>>>> change of license to the LaTeX Project Public License. Thanks to him,
>>>> and thanks also to Ulrike for locating the address.
>>> Given that it is now covered by LPPL, it seems Heiko will have
>>> to change the name of his new package.
>> As it is a re-write, I can't quite see that. If I write a new
>> package, the name is up to me.
>
> sure.
>
>> The license of an existing package
>> can't prevent me choosing the same name for a new one, as long as what
>> I've written is not based on the same code (simply doing the same
>> thing is not enough).* Of course, usually it would be very impolite
>> to release a new package with the same name as an existing one. But
the license of the old package is still not LPPL!
The permission of the author to change the current
one is a permission, no more no less ... we can change
it or not ...
> remember that heiko's original suggestion was a different name...
In this case it makes no sense to have a package with a
different name.
Dan
> Dan schrieb:
>
> > On Oct 16, 7:19 pm, Jim <jim.heffe...@gmail.com> wrote:
> >> The original package author, Pablo Straub, has graciously agreed to a
> >> change of license to the LaTeX Project Public License. Thanks to him,
> >> and thanks also to Ulrike for locating the address.
>
> >> Jim
>
> > Given that it is now covered by LPPL, it seems Heiko will have
> > to change the name of his new package.
>
> no, the old one should go into /obsolete
Since it has not become obsolete, and the author has not
agreed to that (or at least I have as yet seen no information
that he has) this would be presumptuous.
Having just reread the LPPLv1.3c, I see it does not mention
renaming at all anymore. IANAL, but David seems to be correct:
the name appears to be irrelevant to the license. A Derived Work
with a different name seems to be covered by the license. The
question is therefore whether a drop-in replacement with the same
name, but written from scratch, is a Derived Work.
Still, renaming the package would seem to be better than having
incompatible packages with the same name. The LPPL is supposed
to help "provide reliability and stability for the user community",
and
a change of name is more in that spirit.
The best course would be for Straub to give up status as
Current Maintainer and/or Copyright Holder and transfer
the rights to Heiko.
Dan
Robin Fairbairns
>It's a superset and is able to replace the old one.
in that circumstance, i would reassign maintenance of the existing
package to you, and you then "update" it to your version. would that
be ok for you -- if so, i'll start a thread on the ctan internal list.
>A user would have to remember two names for the same purpose.
or at least remember the one not to use. let's not go there, if we
can possibly avoid it.
--
Robin Fairbairns, Cambridge
Robin Fairbairns
>The best course would be for Straub to give up status as
>Current Maintainer and/or Copyright Holder and transfer
>the rights to Heiko.
pablo straub has given up his status as maintainer, since he doesn't
use latex any more.
which is why i mentioned ^^there somewhere that an appropriate move
would be for us to assign the status of maintainer to heiko.
--
Robin Fairbairns, Cambridge
Heiko Oberdiek
> it would make life damnably difficult for us. we can't (by our own
> rules) accept something with the same name as an existing package.
Therefore I can live with `askinc' without problems, even less letters
to type. The renaming was a request of a user (Herbert). And I
understand the argument not having lots of packages doing the same.
> perhaps we can assign the (now vacant, by the author's request)
> maintainership of the package to heiko, and let heiko's own conscience
> decide where to go...
Currently I only have information pieces by third party about the
intensions of the original, previously missing author.
Therefore I have just written an email to the author (or tried to do
so, I still don't know his correct and uptodate address).
Despite the licenses would allow the same name I prefer
an official permission of the original author.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
David Kastrup
It seems quite silly to assign the status of maintainer to Heiko for a
package Heiko has neither written nor used nor touched, just to have
Heiko formally declare it obsolete and replace it by a completely new
package.
What kind of maintenance is that? A movement to "obsolete" is not
rename, and it does not touch the maintainer status of a package. It
is a decision for the CTAN maintainers to make, probably taking
courtesy and Pablo into account and making sure no bad blood arises
because of it.
But I don't see how Heiko comes into play with regard to Pablo's
package and its maintenance at all.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Karl Berry
packages or files (though it is strongly recommended). What it
requires is changing of "identification", which can be entirely within
the file. This was the major change in LPPL 1.3.
Regardless of the legalities, it would be very unusual, in my
experience, to replace an existing package with an entirely new
implementation with the same name.
Joachim Schrod
You guys are beyond recognition. I don't want to cite a personal
email of Jim, but this is a discussion to drive volunteers away.
Pablo said explicitly that he wants another person to take this
package. He just asked if he can be recognized as the original
author. He didn't use LaTeX for years, and wrote that he is not
able to maintain askinclude.sty any more.
If you go beyond the actual implementation; would it really be such
a hassle for you guys to accept a new and better implementation of
askinclude.sty, with the same name, and recognize in that
implementation that Pablo did a first implementation of the
relevant interface? Certainly we CTAN guys are able to do so.
You know, just caring for what users want?
Joachim
PS: Please don't tell me that this is not possible due to the
change of Pable to the LPPL licence. That's not true, reread what
Robin posted.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jsc...@acm.org
Roedermark, Germany
David Kastrup
Timothy Murphy
>> Regardless of the legalities, it would be very unusual, in my
>> experience, to replace an existing package with an entirely new
>> implementation with the same name.
>
> Does "unusual" mean the same as "bad"?
I would say it _is_ bad, in principle.
In this case I am sure Heiko has ensured that there would be no surprises.
But this might not always be true.
I would vote for askinc.sty
David Kastrup
> David Kastrup wrote:
>
>>> Regardless of the legalities, it would be very unusual, in my
>>> experience, to replace an existing package with an entirely new
>>> implementation with the same name.
>>
>> Does "unusual" mean the same as "bad"?
>
> I would say it _is_ bad, in principle.
What principle would that be?
> In this case I am sure Heiko has ensured that there would be no
> surprises. But this might not always be true.
It is never true with any update/change.
--
David Kastrup
Ulrike Fischer
> David Kastrup wrote:
>
>>> Regardless of the legalities, it would be very unusual, in my
>>> experience, to replace an existing package with an entirely new
>>> implementation with the same name.
>>
>> Does "unusual" mean the same as "bad"?
>
> I would say it _is_ bad, in principle.
I don't know why. An author can replace his packages with completly
rewritten versions. The only difference here is that two authors are
involved.
> In this case I am sure Heiko has ensured that there would be no surprises.
> But this might not always be true.
Every update or upgrade of a package can lead to surprises.
> I would vote for askinc.sty
I would vote for the old name (only if the old version is move to
/obsolete or renamed). I always have to look up if subfigure or
subfig is the newer version, and I remember similar problems with
caption/caption2.
--
Ulrike Fischer
Joseph Wright
> > In this case I am sure Heiko has ensured that there would be no
> > surprises. But this might not always be true.
>
> It is never true with any update/change.
>
> --
> David Kastrup
The same surely applies to the original author(s) reimplementing a
package, for example because they find that their first approach has
some flaws. There are several cases where new versions of packages
are specifically flagged up as not behaving in the same way as older
ones. Even changing a package to fix a bug means that it functions
differently to the older versions, which can cause some people issues
(if they have implemented a work-around that gets broken or rely on
something that is not supposed to happen). I'd say that re-
implementation (by any authors) should be considered on the merits of
the case. If the new package can be used as a replacement for the old
one, even if features are added, then surely this is reasonable.
After all, this is the case with e-TeX, pdfTeX, etc. when compared to
Knuth's TeX. On most modern systems, typing "tex" at the command line
does not run Knuth's code (most likely it is pdfTeX). The benefits
outweigh the issues.
Joseph Wright
David Kastrup
> of the case. If the new package can be used as a replacement for
> the old one, even if features are added, then surely this is
> reasonable. After all, this is the case with e-TeX, pdfTeX,
> etc. when compared to Knuth's TeX. On most modern systems, typing
> "tex" at the command line does not run Knuth's code (most likely it
> is pdfTeX).
Huh? Can you name a single "modern system" where "tex" does _not_ run
the original TeX? "latex" most likely runs PDFTeX, sure. But "tex"?
--
David Kastrup
Axel Sommerfeldt
> I would vote for the old name (only if the old version is move to
> /obsolete or renamed). I always have to look up if subfigure or
> subfig is the newer version, and I remember similar problems with
> caption/caption2.
As a person who is confronted with the confusion of the users about this
all the time, I strongly supports Ulrikes point of view.
But IMHO Pablo should (of course!) be mentioned in the docs resp. version
history.
Axel
Joseph Wright
> Huh? Can you name a single "modern system" where "tex" does _not_ run
> the original TeX? "latex" most likely runs PDFTeX, sure. But "tex"?
>
> --
> David Kastrup
Opps, sorry my mistake. I tend to think of "latex" as simply a
shortcut for "tex &latex". As you rightly point out, that is not
correct (on my system, "latex" uses the pdfTeX engine whereas "tex"
does indeed use an unmodified version).
Okay, perhaps a better example would have been LaTeX. LaTeX 2e is
different to 2.09, and is by a different set of authors. But I think
most (I'll avoid saying all) people are happy with it still being
called "LaTeX". The same seems likely to apply to LaTeX 3 - what has
been done so far is clearly getting on for a total re-implementation,
but the name LaTeX will stick (at least that seems to be the case at
the moment).
Sorry for getting my facts wrong.
Joseph Wright
Luis Rivera
> Heiko Oberdiek wrote:
>
> Pablo said explicitly that he wants another person to take this
> package. He just asked if he can be recognized as the original
> author. He didn't use LaTeX for years, and wrote that he is not
> able to maintain askinclude.sty any more.
>
I think this statement settles the issue: Pablo just relinquished his
maintainership; and I think Heiko wouldn't object to mentioning Pablo
as the original developer-maintainer, although stating that this new
version is a full reimplementation of the package. It's a bit like
what Lamport did when he handed LaTeX to the LaTeX team.
Luis.
Boris Veytsman
JW> Date: Thu, 18 Oct 2007 05:31:24 -0700
JW> Even changing a package to fix a bug means that it functions
JW> differently to the older versions, which can cause some people issues
JW> (if they have implemented a work-around that gets broken or rely on
JW> something that is not supposed to happen).
There is a reason God was able to create the universe in just six
days. He did not have to think about backward compatibility.
--
Good luck
-Boris
The meek shall inherit the earth; but by that time there won't be
anything left worth inheriting.
Robin Fairbairns
>JW> From: Joseph Wright <joseph...@morningstar2.co.uk>
>JW> Date: Thu, 18 Oct 2007 05:31:24 -0700
>
>
>JW> Even changing a package to fix a bug means that it functions
>JW> differently to the older versions, which can cause some people issues
>JW> (if they have implemented a work-around that gets broken or rely on
>JW> something that is not supposed to happen).
>
>There is a reason God was able to create the universe in just six
>days. He did not have to think about backward compatibility.
nah. he just had *very* long days. (~=500myears each.)
--
Robin Fairbairns, Cambridge
David Kastrup
Well, that seems to be somewhat of a misestimate even for programmers'
standards. He probably had quite some fallout with management for
that.
Timothy Murphy
>>>> Regardless of the legalities, it would be very unusual, in my
>>>> experience, to replace an existing package with an entirely new
>>>> implementation with the same name.
>>>
>>> Does "unusual" mean the same as "bad"?
>>
>> I would say it _is_ bad, in principle.
>
> What principle would that be?
The principle that different programs by different people
should have different names,
even if they aim to do the same thing.
>> In this case I am sure Heiko has ensured that there would be no
>> surprises. But this might not always be true.
>
> It is never true with any update/change.
That's a bit sweeping.
I use askinclude all the time,
and intend to change it to askinc.
(This seems a very small change to me.)
If it works fine, as I expect, I shall leave it.
If it doesn't, I shall revert to askinclude.
Axel Sommerfeldt
> I use askinclude all the time,
> and intend to change it to askinc.
> (This seems a very small change to me.)
> If it works fine, as I expect, I shall leave it.
> If it doesn't, I shall revert to askinclude.
And what do you do if a different package doesn't work fine anymore after
an update? And whatever you do in this case: Why can't you just do the same
for askinclude.sty?
Robin Fairbairns
>> I use askinclude all the time,
>> and intend to change it to askinc.
>> (This seems a very small change to me.)
>> If it works fine, as I expect, I shall leave it.
>> If it doesn't, I shall revert to askinclude.
this isn't altered by the proposed arrangement -- with a copy of the
old version on the obsolete/ tree on ctan, you can downgrade again in
the unlikely event that you want to.
and you don't even have to change the file name in your documents.
>And what do you do if a different package doesn't work fine anymore after
>an update? And whatever you do in this case: Why can't you just do the same
>for askinclude.sty?
get irritated, i'll bet. who wants the hassle?
fortunately, my guess is heiko's version will work without trouble.
--
Robin Fairbairns, Cambridge
David Kastrup
> David Kastrup wrote:
>
>>>>> Regardless of the legalities, it would be very unusual, in my
>>>>> experience, to replace an existing package with an entirely new
>>>>> implementation with the same name.
>>>>
>>>> Does "unusual" mean the same as "bad"?
>>>
>>> I would say it _is_ bad, in principle.
>>
>> What principle would that be?
>
> The principle that different programs by different people should
> have different names, even if they aim to do the same thing.
I would really, really be quite annoyed if all GNU/Linux programs had
names different from the UNIX (BSD or AT/T) counterparts that they aim
to duplicate. The whole point of an alternate universe is that you
can interchange it without editing all referers.
Timothy Murphy
>> The principle that different programs by different people should
>> have different names, even if they aim to do the same thing.
>
> I would really, really be quite annoyed if all GNU/Linux programs had
> names different from the UNIX (BSD or AT/T) counterparts that they aim
> to duplicate. The whole point of an alternate universe is that you
> can interchange it without editing all referers.
That's not even an approximate parallel.
It makes a big difference if wheels on the _same_ car are different sizes.
We are talking about different LaTeX packages with the same name.
Surely it must be obvious that this could cause problems.
Timothy Murphy
>> I use askinclude all the time,
>> and intend to change it to askinc.
>> (This seems a very small change to me.)
>> If it works fine, as I expect, I shall leave it.
>> If it doesn't, I shall revert to askinclude.
>
> And what do you do if a different package doesn't work fine anymore after
> an update?
Utter appropriate expletives and write to comp.text.tex.
> And whatever you do in this case: Why can't you just do the
> same for askinclude.sty?
I would.
David Kastrup
But providing the same functionality with the same interface.
> Surely it must be obvious that this could cause problems.
You are asking for the spare wheel to have a different size so that it
won't get confused with the regular wheels. That pretty much defeats
the concept of a spare wheel.
--
David Kastrup
Luis Rivera
> r...@cl.cam.ac.uk (Robin Fairbairns) writes:
> > Boris Veytsman <bor...@lk.net> writes:
>
> >>There is a reason God was able to create the universe in just six
> >>days. He did not have to think about backward compatibility.
>
> > nah. he just had *very* long days. (~=500myears each.)
>
> Well, that seems to be somewhat of a misestimate even for programmers'
> standards. He probably had quite some fallout with management for
> that.
>
He may not have had such a fallout, if he is his own boss, working in
his own hack. :-)
Luis.
Frank Mittelbach
If i understand the situation correctly then
a) the package has LPPL as the license
b) original owner retired from maintaining the package
c) all he asked for is to be acknowledge as the original developer of the
package (and the concepts behind it)
that allows anybody to step up and become maintainer of the package. With
Heiko's reputation I'm fairly sure that the original owner would be quite
happy with that (and given that I understand he is contactable that could
even be confirmed).
Assuming Heiko would be the maintainer, he would be free to reimplement the
package concepts using a different implementation. He would also be free to
publish that as a new version of the package (or if he feels that it is
changed in a way that users might wish to use the versions in alternation,
give it a new name).
My understanding is further that Heiko's feeling and/or those on the list
here who have looked through his new code think that it is a valid
reimplmentation (perhaps with additional features) and should therefore
preferably kept its name.
LPPL's maintainer part was precisely written to help avoid getting packages
in an unmaintained state and forcing the comunity to start up with new
package names when there is no good reason for it.
so to me the situation is simple ... keep the established name ... unless
the package does something quite different from the older one (not that
additional features are not an argument since they are covered by version
numbers and happen in all packages without the authrs each time issuing new
names.
regards
frank
David Kastrup
I have not tracked this closely, but wasn't there supposed to be
evidence of a rather big bang concerning this project?
Michael Ehrt
> Luis Rivera <jlr...@gmail.com> writes:
>
>> On Oct 18, 1:24 pm, David Kastrup <d...@gnu.org> wrote:
>>> r...@cl.cam.ac.uk (Robin Fairbairns) writes:
>>> > Boris Veytsman <bor...@lk.net> writes:
>>>
>>> >>There is a reason God was able to create the universe in just six
>>> >>days. He did not have to think about backward compatibility.
>>>
>>> > nah. he just had *very* long days. (~=500myears each.)
>>>
>>> Well, that seems to be somewhat of a misestimate even for programmers'
>>> standards. He probably had quite some fallout with management for
>>> that.
>>
>> He may not have had such a fallout, if he is his own boss, working
>> in his own hack. :-)
His own boss? You mean he wasn't married? :-)
> I have not tracked this closely, but wasn't there supposed to be
> evidence of a rather big bang concerning this project?
I just don't know why an image of his wife slamming the door of his
workshop comes to my mind ... :-))
Cheers
Michael
Heiko Oberdiek
> Currently I only have information pieces by third party about the
> intensions of the original, previously missing author.
> Therefore I have just written an email to the author (or tried to do
> so, I still don't know his correct and uptodate address).
> Despite the licenses would allow the same name I prefer
> an official permission of the original author.
I have successfully contacted Pablo Straub and have its permission.
Also I implemented some support for regular expressions
using wildcard matching of package makematch or regular expressions
provided by the undocumented feature \pdfmatch of pdfTeX.
License is LPPL, the name is askinclude.
CTAN:macros/latex/contrib/oberdiek/askinclude.pdf
Yours sincerely
Heiko <ober...@uni-freiburg.de>