Prev: what do tclers think about google go?
Next: text .. index anchor
From: Donal K. Fellows on 3 Jan 2010 15:08
On 3 Jan, 18:35, Helmut Giese <hgi...(a)ratiosoft.com> wrote:
> This alone is not sufficient since Tcl's package mechanism only looks
> one level deep.

That's deliberate (and a change from how things were a number of years
ago[*]). Some installations of Tcl have /usr/lib on the auto_path, and
that's somewhere you *really* don't want to do a full recursive
descent search of at runtime.

Donal.
[* I think this was an early 8.4 issue. ]
From: Helmut Giese on 3 Jan 2010 17:46
Hi Donal,
>> This alone is not sufficient since Tcl's package mechanism only looks
>> one level deep.
this was in no way meant to criticize Tcl's behaviour - merely giving
a reason for the following explanation.

>That's deliberate (and a change from how things were a number of years
>ago[*]). Some installations of Tcl have /usr/lib on the auto_path, and
>that's somewhere you *really* don't want to do a full recursive
>descent search of at runtime.
Best regards
Helmut Giese
From: Will Duquette on 3 Jan 2010 18:02
On Jan 3, 11:04 am, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
> On Jan 2, 9:49 pm, Will Duquette <w...(a)wjduquette.com> wrote:
>
>
>
>
>
> > On Jan 2, 8:12 pm, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
>
> > > Anyway, this a long about way of pointing out that an application many
> > > have different priorities wrt sourcing code. The Tcl package system
> > > works good for general code, but less well for fast evolving or highly
> > > customized application code.
>
> > I dunno.  I have a standard architecture I use that revolves around
> > packages.  Every project has a lib directory containing 2+N
> > subdirectories: a non-GUI utility package, a GUI utility package, and
> > one for each application in the project.  Each of these is implemented
> > as a package.
>
> > Then, I have a bin directory that contains a short "loader" script for
> > each application, or more often, a single loader script that selects
> > the application package based on its first argument.  The loader adds
> > the ./lib directory to the auto_path, and then requires the
> > application package, which then requires the other packages it needs.
>
> > It's true that the package version number isn't of much use in this
> > case, and I pretty much set it to 1.0 and ignore it.  But the package
> > mechanism provides me with a standard mechanism for sourcing the
> > relevant files; and if I didn't use it I'd have to define a convention
> > of my own.  Easier to use a standard one.  Plus, it means the code
> > works the same whether it runs in my development environment or in a
> > starpack.
>
> > I've been doing it this way for over four years, and I've yet to find
> > a downside.
>
> It sounds to me like you have a two level package loader, which is
> what I have as well. The built-in Tcl package loader is great for
> library code, but it can't handle local configuration before and after
> loading the library code. This is handled by my specialized loader.
> Some code also needs initialization, which must occur in the correct
> sequence. My loader also records the actual files sourced, which helps
> track down errors. The Tcl package loader provides no means to record
> this information, and requires you to deal with errors generated in
> end user code.

Not as such--the "loader" script I talk about simply determines where
the application's lib directory is, prepends it to the auto_path, and
requires the application package. I'm not changing the default
packing loading mechanism at all.

I'm not sure what you mean by "local configuration".
From: Robert Heller on 3 Jan 2010 21:56
At Sat, 2 Jan 2010 19:18:48 -0800 (PST) Anuj <goyal.anujkumar(a)gmail.com> wrote:

>
> On Jan 3, 3:00=A0am, Robert Heller <hel...(a)deepsoft.com> wrote:
> > At Sat, 2 Jan 2010 05:36:09 -0800 (PST) "Donal K. Fellows" <donal.k.fell.=
> ..@manchester.ac.uk> wrote:
> >
> >
> >
> > > On 2 Jan, 12:07, Anuj <goyal.anujku...(a)gmail.com> wrote:
> > > > Can anybody please tell why we should use packages instead of using
> > > > source command directly?
> >
> > > Because the package manager looks after versioning for you. You don't
> > > have to know how a package works internally, just what it is called
> > > and what version(s) you want. This is easier for library code, much
> > > much easier.
> >
> > > You don't need to use packages for application-specific code. They're
> > > only really useful when the file is going to need to be sourced or
> > > loaded from multiple programs.
> >
> > It does help as a way of keeping code libraries organized, even when the
> > code might not be loaded by mulitple programs.
> >
> >
> >
> > > Donal.
> >
> > --
> > Robert Heller =A0 =A0 =A0 =A0 =A0 =A0 -- Get the Deepwoods Software FireF=
> ox Toolbar!
> > Deepwoods Software =A0 =A0 =A0 =A0-- Linux Installation and Administratio=
> nhttp://www.deepsoft.com/=A0-- Web Hosting, with CGI and Database
> > hel...(a)deepsoft.com =A0 =A0 =A0 -- Contract Programming: C/C++, Tcl/Tk
>
>
> Hi Robert,
>
> When we are using packages then also at least once we need to hard
> code the location of package in auto_path (I haven't used starkit so I
> don't know about it)
>
> For example, We are using IXIA for stream generation/analysis. In our
> framework, to use IXIA we need to add following 2 lines:
> lappend auto_path "C:/Program Files/Ixia/TclScripts/lib/ixTcl1.0"
> ...
> package require IxTclHal
>
> After that we can invoke IXIA API's from any script.
>
> Now lets assume instead of providing it's API's as package IXIA have
> provided them as normal binaries and a single file to source those
> binaries, 'IxTclHal.tcl'
> In this case above will become as follows:
>
> source "C:/Program Files/Ixia/TclScripts/lib/ixTcl1.0/IxTclHal.tcl"
>
> So I don't see any advantage w.r.t. hard coding of path.
>
> It looks like I'm not able to get the point. Can you please give some
> example?

If you are loading multiple files from a library that is always in some
relative location (WRT the main program) OR always in some well defined
library tree. There are three cases here:

1) development mode where some main script, main.tcl, loads several code
libraries, mymegawidget.tcl, myspecialSNITclass.tcl, etc. All source
code is in a common development directory:

lappend auto_path [file dirname [info script]]

2) You have a pile of assorted reusable code libraries stored in
$HOME/myTCLToolBoxLib:

lappend auto_path [file join $::env(HOME) myTCLToolBoxLib]


3) You are building your code into a starkit:

tclkit sdx qwrap program.tcl
tclkit sdx unwrap program.kit
mkdir program.vfs/lib/supportcode
cp mymegawidget.tcl myspecialSNITclass.tcl program.vfs/lib/supportcode
(cd program.vfs/lib/supportcode; echo 'pkg_mkIndex . *'|tclkit)
tclkit sdx wrap program.kit

(There is no need to mess with auto_path, since the tclkit startup takes
care of things.)

Note: auto_path can also be initialized from the environment variable
TCLLIBPATH.

> I want to understand the advantage of package because in our company
> we are also using a framework. In that all the libraries are used
> through sourcing and we are not using packages. So I just want to
> evaluate whether it's fruitful to change the strategy and move to
> packages.

It is very fruitful if the code library is used in many programs and
especially useful if the location of the code library is not always in
some hard coded place and/or the code library(-ies) are going to be
stored in a system location (eg under /usr/share/tcl<version> or
/usr/lib or packaged in a starkit or starpack). In these latter cases,
there is no need for wiring in a path to the code.

It is the same set of issues relating to: Should I make the <mumble>
C/C++ code library into its own binary library (eg .a/.lib, .so/.dll) or
not? Think of a Tcl 'package' in exactly the same way you would think
of a C/C++ .a/.lib or .so/.dll file. The Tcl package command deals with
the some of the same set of issues.

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

From: Donald G Porter on 3 Jan 2010 23:13
Helmut Giese <hgi...(a)ratiosoft.com> wrote:
>> This alone is not sufficient since Tcl's package mechanism only looks
>> one level deep.

Donal K. Fellows wrote:
> That's deliberate (and a change from how things were a number of years
> ago[*]).
....
> [* I think this was an early 8.4 issue. ]

Your memory is mistaken. [tclPkgUnknown] has limited its search for
pkgIndex.tcl files to one subdirectory level below the directories
in $::auto_path ever since it arrived in Tcl 7.5.

The one thing that has changed is whether the search reacts to changes
in the $::auto_path value that happen during the [source]-ing of all
the pkgIndex.tcl files. Perhaps that's what you are thinking of.

DGP

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: what do tclers think about google go?
Next: text .. index anchor