Prev: Readahead in proc? Or mark something DATA in tcl?
Next: Using NRE inside of loops in C
From: Andrew Cheong on 9 Aug 2010 15:23
On Aug 9, 2:58 pm, Don Porter <d...(a)nist.gov> wrote:
> Andrew Cheong wrote:
> > On Aug 9, 2:09 pm, Don Porter <d...(a)nist.gov> wrote:
> >> Andrew Cheong wrote:
> >>> package provide Report 1.0
> >>> namespace eval ::Report::Html::Table {
> >>>     namespace export Merge
> >>>     namespace export Create
> >>> }
> >>> namespace eval ::Report::Html::Histogram {
> >>>     namespace export Create
> >>> }
> >>> proc ::Report::Html::Table::Merge {} { ... }
> >>> proc ::Report::Html::Table::Create {} { ... }
> >>> proc ::Report::Html::Histogram::Create {} { ... }
> >>> When I run pkg_mkIndex, I don't see any of the above in pkgIndex.tcl.
> >> What is it you believe you want to see in pkgIndex.tcl ?
> > If I rename one of the Create's to CreateUnique, I see this:
>
> > package ifneeded Report 1.0 [list tclPkgSetup $dir cama_Report 1.0
> > {{cama_Report.html.tcl source
> > {::Report::Html::Histogram::CreateUnique ::Report::Html::Table::Create ::Report::Html::Table::Merge}}}]
>
> > But I would like to see this:
>
> > package ifneeded Report 1.0 [list tclPkgSetup $dir cama_Report 1.0
> > {{cama_Report.html.tcl source
> > {::Report::Html::Histogram::Create ::Report::Html::Table::Create ::Report::Html::Table::Merge}}}]
>
> No.  I assert what you really want to see as the contents of
> pkgIndex.tcl is this:
>
> package ifneeded Report 1.0 \
>      [list source [file join $dir cama_Report.html.tcl]]
>
> Note that I've broken that onto two lines only to avoid wrapping
> issues in Usenet.  Single line in the actual file is fine.
>
> Now surely you don't need a tool to create a single line file.  So
> forget standing on your head attempting to make [pkg_mkIndex] do
> what you want (to say nothing of the 12-year-old version of
> [pkg_mkIndex] you must be stuck with) and just create that one line
> file.

The situation is a bit more complicated than I've portrayed it to be;
I simplified it for sake of clarity. In reality, there are many
packages written by various infrastructure, product, and operations
teams, and our automatic deployment software runs pkg_mkIndex as part
of its "Install" routine.

>
> > Hm, I see.  I was not aware of the -lazy and -direct distinctions;
> > indeed -direct would be my preference.  However, I work in a corporate
> > environment and I am not able to change the infrastructure; we run Tcl
> > 8.0.5 in all our server environments.
>
> > Would you explain why -lazy/-direct makes the difference in what I'm
> > doing?  Thank you.
>
> The -lazy mode pointlessly conflates package indexing with the enabling
> of autoloading.
>
> Autoloading is extremely overrated, and better left completely undone
> unless and until some measured need drives you to it.  And in the
> unlikely case such a need arises, autoloading ought to have an
> implementation orthogonal to the package machinery.
>
> The package machinery doesn't need to, and therefore should not, care
> one whit what commands are provided by your package.  All your troubles
> are arising because in a moderately non-trivial case, [pkg_mkIndex]
> is having trouble figuring out this thing it has no need to know.
>
> [pkg_mkIndex] was a well-intentioned, but failed experiment.  Drop it.
> Create the pkgIndex.tcl files you need by other means.
>
> --
> | Don Porter          Mathematical and Computational Sciences Division |
> | donald.por...(a)nist.gov             Information Technology Laboratory |
> |http://math.nist.gov/~DPorter/                                 NIST |
> |______________________________________________________________________|- Hide quoted text -
>
> - Show quoted text -

Thank you for your explanation--it makes sense. While I respect your
opinion and direction however, I'll have to find a way to hack it to
work. (I'm not even sure who I'll have to talk to in order to make
such a huge infrastructure change; all I know is that they're
somewhere in Europe. And it's not likely that anyone will listen...)

If anyone has a suggestion for a hack, please let me know.
From: Donald G Porter on 9 Aug 2010 21:46
Andrew Cheong wrote:
> The situation is a bit more complicated than I've portrayed it to be;
> I simplified it for sake of clarity. In reality, there are many
> packages written by various infrastructure, product, and operations
> teams, and our automatic deployment software runs pkg_mkIndex as part
> of its "Install" routine.

Ok, Let's nail down the precise constraint then. The [pkg_mkIndex]
use that is beyond your control...

1) Is it in fact the command as distributed with Tcl 8.0.5? That is,
none of the bug fixes or other revisions that have happened since?

2) What arguments are passed to [pkg_mkIndex] in the use you cannot
control? Any options? Do you have any control over what options
might be added or taken away?

We may be able to solve this yet, now that I know the best answers are
not going to work in your situation.

DGP
From: Donald G Porter on 9 Aug 2010 22:13
Andrew Cheong wrote:
> The situation is a bit more complicated than I've portrayed it to be;
> I simplified it for sake of clarity. In reality, there are many
> packages written by various infrastructure, product, and operations
> teams, and our automatic deployment software runs pkg_mkIndex as part
> of its "Install" routine.

Ok, Let's nail down the precise constraint then. The [pkg_mkIndex]
use that is beyond your control...

1) Is it in fact the command as distributed with Tcl 8.0.5? That is,
none of the bug fixes or other revisions that have happened since?

2) What arguments are passed to [pkg_mkIndex] in the use you cannot
control? Any options? Do you have any control over what options
might be added or taken away?

We may be able to solve this yet, now that I know the best answers are
not going to work in your situation.

DGP
First  |  Prev  | 
Pages: 1 2
Prev: Readahead in proc? Or mark something DATA in tcl?
Next: Using NRE inside of loops in C