str...@cs.UMD.EDU didn't work.
Herbert
--
http://PSTricks.tug.org
http://www.dante.de/CTAN/info/math/voss/
I think you are going to struggle. A few searches give no hits after
1997 for him!
Joseph Wright
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
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
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
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
> 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.
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
> =?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>
> 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>
> 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
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.
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 Hefferon
tug.ctan.org
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
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
> 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>
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
Given that it is now covered by LPPL, it seems Heiko will have
to change the name of his new package.
Dan
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
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.
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"?
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
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>
> 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>
> 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>
> 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>
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.
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
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
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
> 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>