Prev: what do tclers think about google go?
Next: text .. index anchor
From: Anuj on 2 Jan 2010 22:18
On Jan 3, 3:00 am, Robert Heller <hel...(a)deepsoft.com> wrote:
> At Sat, 2 Jan 2010 05:36:09 -0800 (PST) "Donal K. Fellows" <donal.k.fell....(a)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             -- Get the Deepwoods Software FireFox Toolbar!
> Deepwoods Software        -- Linux Installation and Administrationhttp://www.deepsoft.com/ -- Web Hosting, with CGI and Database
> hel...(a)deepsoft.com       -- 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?
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.
From: tom.rmadilo on 2 Jan 2010 23:12
On Jan 2, 7:18 pm, Anuj <goyal.anujku...(a)gmail.com> wrote:
> It looks like I'm not able to get the point. Can you please give some
> example?
> 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.

If you have a well managed framework, you don't need to use the
package concept...which roots around to fill dependencies.

The problem with packages is that they package version usually doesn't
track with the patch level. This does not matter for libraries, the
base Tcl packages. But it does not work very well for application
code. Of course just IMHO.

I use a framework which uses explicit sourcing. One issue I haven't
fixed is dealing with configuration. The framework has many non-tcl
packages, and not every installation will use every package (and some
applications may add new ones). The problem is to separate
configuration so it isn't part of the actual code.

Another issue un-addressed by the package system is non-tcl code. For
instance, my "packages" divide code into a number of directories: tcl,
www, admin, sql, bin, etc, and maybe a few others if needed. Only the
tcl directory contains library code, but the code there isn't meant to
be sourced in some random order.

I also replace the source command so that I know what file is being
sourced prior to the operation...just in case a bug aborts the source
of a particular file.

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.
From: Will Duquette on 3 Jan 2010 00:49
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.
From: Helmut Giese on 3 Jan 2010 13:35
Hi,
>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"
<shudder> I'd never want to do this.
>...
>package require IxTclHal
Here is what I am doing: I add a folder 'addons' to Tcl's lib
directory and there I put every package into its own sub-folder. This
then looks something like:
<path to tcl>/lib/addons
/pkgFoo
/pkgBar
/pkgBaz
This alone is not sufficient since Tcl's package mechanism only looks
one level deep - that is, it looks into the folder 'addons' but not
deeper. So 'addons' gets a file pkgIndex.tcl with the following
content (lines will wrap):
---
#
# Modelled after the example in tcllib1.x
#
set maindir $dir
set dir [file join $maindir pkgFoo] ; source [file join $dir
pkgIndex.tcl]
set dir [file join $maindir pkgBar] ; source [file join $dir
pkgIndex.tcl]
set dir [file join $maindir pkgBaz] ; source [file join $dir
pkgIndex.tcl]
unset maindir
---
Of course every package needs to provide its own pkgIndex.tcl file,
but that's a given - else it would not be a proper package to begin
with.
Advantages:
- I never adjust any paths.
- If I install a newer version of Tcl beside my current one I only
copy the 'addons' folder and everything just continues to work.
- Heck, I can even copy the 'addons' folder on a USB stick, take it
somewhere else, copy it into a different Tcl installation on whatever
path it is - and things still work.

The beauty of this solution is that I never have to care about paths
anymore - Tcl's package mechanism takes care of this.

A side point: If you have Tcl installed under C:/program files/tcl you
will probably need to turn admin to create the 'addons' folder - but
that's Windows for you. I never install Tcl there.

HTH
Helmut Giese
From: tom.rmadilo on 3 Jan 2010 14:04
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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: what do tclers think about google go?
Next: text .. index anchor