Re: Infrastructure work

Re: Infrastructure work

[Ian Roxborough]

On Wed, 2 Aug 2000, Ben Elliston wrote:
> 	* Removing the dependency on Tix.

They are a number of things that can be done,
using BWidgets it one of my favs. also BLT, which
could also be use to replace the Tree Widget which
is more of plain than Tix.

> 	* Removing the dependency on local changes to Tcl and Tk.

We are actively working towards this. 
(Are you using the development version?)

> 	* Making the extensions to the Tcl interpreter a loadable
> 	  library (ie. "hyper.so").

This would be cool, but then we are dependent on the user
having a "clean" Tcl version (Some Tcl/Tk apps require
core patching before they run).   (Of course I'm assume
you mean that we should load into the users local Tcl/Tk
and not a version from us.)

> 	* Making the syntax highlighters loadable libraries, too.

Hmmmm, I like this one a lot.

Ian. 

Re: Infrastructure work

[Ben Elliston]

   This would be cool, but then we are dependent on the user having a
   "clean" Tcl version (Some Tcl/Tk apps require core patching before
   they run).  (Of course I'm assume you mean that we should load into
   the users local Tcl/Tk and not a version from us.)

Couldn't snavigator's configure script test the installed Tcl/Tk to
determine if it was usable?  That's precisely what Autoconf is for!

Yes, that's what I meant.

   > 	* Making the syntax highlighters loadable libraries, too.
   
   Hmmmm, I like this one a lot.
   
Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
Perhaps they already allow it to be built shared?

Ben

Re: Infrastructure work

[Gilles J. Seguin]

Ian Roxborough wrote:
> 
> On Wed, 2 Aug 2000, Ben Elliston wrote:
> >    This would be cool, but then we are dependent on the user having a
> >    "clean" Tcl version (Some Tcl/Tk apps require core patching before
> >    they run).  (Of course I'm assume you mean that we should load into
> >    the users local Tcl/Tk and not a version from us.)
> >
> > Couldn't snavigator's configure script test the installed Tcl/Tk to
> > determine if it was usable?  That's precisely what Autoconf is for!
> 
> We could, but how many tests? and what needs tested to make
> sure we're not running on a SN safe tcl/tk.  Is it really important?
> I know it's going to be hard tracking down reported bugs only to
> find out the user is running on a none standard tcl/tk.

Can we target tcl/tk version 8.3 supposedly the version for
the upcoming Red Hat 7.0 version (pinestripe)

tcl/tk version 8.4, can you provide information how difficult
it will be.

The question here, how do I will manage all those versions
of tcl/tk. In the sense that nearly every application
require their own version of it.

> > Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.
> > Perhaps they already allow it to be built shared?
> 
> I'd like to see a more generic DB interface first so we can swap
> out our DB back ends.  I've not look at this yet, but may be they
> both go hand in hand.
> 
> Ian.

Re: Infrastructure work

[Mo DeJong]

On Tue, 1 Aug 2000, Ian Roxborough wrote:
 
> On Wed, 2 Aug 2000, Ben Elliston wrote:
> >    This would be cool, but then we are dependent on the user having a
> >    "clean" Tcl version (Some Tcl/Tk apps require core patching before
> >    they run).  (Of course I'm assume you mean that we should load into
> >    the users local Tcl/Tk and not a version from us.)
> > 
> > Couldn't snavigator's configure script test the installed Tcl/Tk to
> > determine if it was usable?  That's precisely what Autoconf is for!
> 
> We could, but how many tests? and what needs tested to make
> sure we're not running on a SN safe tcl/tk.  Is it really important?
> I know it's going to be hard tracking down reported bugs only to
> find out the user is running on a none standard tcl/tk.

I think we have to face reality here. People are never going to
have the "right" versions of Tcl/Tk on all systems. It is just
a lot easier to provide our own. Even if the versions of Tcl/Tk
matched, what if we fix a really critical bug in Tcl, we don't
want people to upgrade to a new OS to get a new version of Tcl
just so they can run SN.

> > Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
> > Perhaps they already allow it to be built shared?
> 
> I'd like to see a more generic DB interface first so we can swap
> out our DB back ends.  I've not look at this yet, but may be they
> both go hand in hand.

http://www.qs.co.nz/Tcl/DAS.html
http://zork.net/~phil/projects.html

I am sure there are others.

Mo DeJong
Red Hat Inc

Re: Infrastructure work

[Ian Roxborough]

On Wed, 2 Aug 2000, Ben Elliston wrote:
>    This would be cool, but then we are dependent on the user having a
>    "clean" Tcl version (Some Tcl/Tk apps require core patching before
>    they run).  (Of course I'm assume you mean that we should load into
>    the users local Tcl/Tk and not a version from us.)
> 
> Couldn't snavigator's configure script test the installed Tcl/Tk to
> determine if it was usable?  That's precisely what Autoconf is for!

We could, but how many tests? and what needs tested to make
sure we're not running on a SN safe tcl/tk.  Is it really important?
I know it's going to be hard tracking down reported bugs only to
find out the user is running on a none standard tcl/tk.

> Yeah.  It'd also be nice to make Berkeley DB a loadable library, too.  
> Perhaps they already allow it to be built shared?

I'd like to see a more generic DB interface first so we can swap
out our DB back ends.  I've not look at this yet, but may be they
both go hand in hand.
 
Ian.

Re: Infrastructure work

[Syd Polk]

At 09:24 AM 8/2/00 +1000, Ben Elliston wrote:
>    One of the reasons we never bothered with a shared build is that we
>    currently rely on our own version of Tcl/Tk. It should not conflict
>    with a pre-installed version.
>
>Speaking of which, some thoughts I had yesterday on "big" infrastructure
>work that really needs to be done:
>
>         * Removing the dependency on Tix.
>
>         * Removing the dependency on local changes to Tcl and Tk.
>
>         * Making the extensions to the Tcl interpreter a loadable
>           library (ie. "hyper.so").
>
>         * Making the syntax highlighters loadable libraries, too.
>
>Thoughts?
>
>Ben

Yes, all of these need to be done. They are a lot of work.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Infrastructure work

[Ben Elliston]

   One of the reasons we never bothered with a shared build is that we
   currently rely on our own version of Tcl/Tk. It should not conflict
   with a pre-installed version.

Speaking of which, some thoughts I had yesterday on "big" infrastructure
work that really needs to be done:

	* Removing the dependency on Tix.

	* Removing the dependency on local changes to Tcl and Tk.

	* Making the extensions to the Tcl interpreter a loadable
	  library (ie. "hyper.so").

	* Making the syntax highlighters loadable libraries, too.

Thoughts?

Ben