tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: Documentation

[Larry W. V. <lv...@ca...>]

Re: what format for doc

The problem with choosing HTML is that currently that makes the 
doc unreadable by TkMan.  It would be much better to provide doc 
in one of the several formats that it reads.

Note that if one doesn't know *roff, there is always the pod2man 
filter that will convert from Perl's relatively simple format 
into a man page...


-- 
Larry W. Virden <URL: mailto:lv...@ca...> 
<URL: http://www.purl.org/net/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Documentation

[Joe E. <jen...@fl...>]

Jeffrey Hobbs wrote:
>
> This is a good question.  I think generally that HTML is a good minimum
> (can be read on all platforms).  It'd be nice to get an XML DTD standard
> in place so that we can start moving towards using XML as the base.
>
> Does anyone know how close we are to that?

The TMML DTD is now in pretty good shape, and the NROFF->TMML 
conversion script is running smoothly for the most part.

See <URL: http://www.flightlab.com/~joe/tmml/> for the current
snapshot.  I'm in the process of finishing the documentation
and putting together a tarball of the DTD, XSL scripts, and
up-conversion utilities.



--Joe English

  jen...@fl...

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Documentation

[Jeffrey H. <jef...@aj...>]

As soon as we can get the effort rolling, we want to make XML the
base format for all docs, with converters to man/html/winhelp/etc.

Starting with pod is definitely not an alternative.  Note that
many perl'ers don't even like pod's limitations.  No need to waste
effort there when we can start fresh with XML.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

> -----Original Message-----
> From: Mo DeJong [mailto:md...@cy...]
	...
> On Thu, 3 Aug 2000, Larry W. Virden wrote:
> 
> > Re: what format for doc
> > 
> > The problem with choosing HTML is that currently that makes the 
> > doc unreadable by TkMan.  It would be much better to provide doc 
> > in one of the several formats that it reads.
> > 
> > Note that if one doesn't know *roff, there is always the pod2man 
> > filter that will convert from Perl's relatively simple format 
> > into a man page...
> 
> I thought the docs were going to be written in XML and then
> get converted to HTML or whatever. It seems that people are
> going to complain about any one format that is picked.

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Documentation

[Mo D. <md...@cy...>]

On Thu, 3 Aug 2000, Larry W. Virden wrote:

> Re: what format for doc
> 
> The problem with choosing HTML is that currently that makes the 
> doc unreadable by TkMan.  It would be much better to provide doc 
> in one of the several formats that it reads.
> 
> Note that if one doesn't know *roff, there is always the pod2man 
> filter that will convert from Perl's relatively simple format 
> into a man page...

I thought the docs were going to be written in XML and then
get converted to HTML or whatever. It seems that people are
going to complain about any one format that is picked.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Documentation

[Jeffrey H. <jef...@aj...>]

This is a good question.  I think generally that HTML is a good minimum
(can be read on all platforms).  It'd be nice to get an XML DTD standard
in place so that we can start moving towards using XML as the base.

Does anyone know how close we are to that?

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

> -----Original Message-----
> From: Christopher Nelson [mailto:ch...@pi...]
> Sent: Thursday, August 03, 2000 7:30 AM
> To: Jeffrey Hobbs
> Subject: Documentation
>
>
> I've got a couple of widgets that I'm considering contributing to tcllib (or
> tklib, or whatever) but I'm not sure what form you expect or require
> documentation to be in.  I can do HTML fairly easily but nroff would be really
> hard.
>
>                                             Chris
> --
> Rens-se-LEER is a county.  RENS-se-ler is a city.  R-P-I is a school!

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Time to retire tk_menuBar and tk_bindForTraversal?

[Mo D. <md...@cy...>]

On Tue, 1 Aug 2000, Joe English wrote:

> 
> On 1 Aug 2000, after installing a brand-spanking-new,
> bleeding edge Tcl/Tk 8.4 alpha 1 distribution fresh out
> of the Ajuba CVS repository, you can still type 'man menubar'
> and get:

While we are at it, could we retire the old pack interface too?

pack - Obsolete syntax for packer geometry manager

pack after ...
pack append  ...
pack before ...
pack unpack ...

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Time to retire tk_menuBar and tk_bindForTraversal?

[Joe E. <jen...@fl...>]

On 1 Aug 2000, after installing a brand-spanking-new,
bleeding edge Tcl/Tk 8.4 alpha 1 distribution fresh out
of the Ajuba CVS repository, you can still type 'man menubar'
and get:

| NAME
|   tk_menuBar,  tk_bindForTraversal - Obsolete  support for menu bars
|
| DESCRIPTION
|   These procedures were used in Tk 3.6 and earlier  releases
|   to  help  manage  pulldown menus and to implement keyboard
|   traversal of menus.  In Tk 4.0 and later releases they are
|   no  longer  needed.   Stubs for these procedures have been
|   retained for backward  compatibility,  but  they  have  no
|   effect.   You should remove calls to these procedures from
|   your code, since eventually the procedures will go away.


The 'menubar' man page from the Tk 4.0 release said the same
thing; that was in late 1994.  I think it's safe to say that
nobody is using these procedures anymore :-) and the following
files can be removed from the Tk distribution without any ill effect:

	library/obsolete.tcl
	doc/menubar.n

The pack-old(n) manpage is in a similar state.  Although
it's no longer even accurate (``this syntax continues
to be supported for backward compatibility'' -- it isn't)
it *might* still be useful to people who need to upgrade their
old Tk 3.3 apps.  Nevertheless, it too can probably be removed
without harm.

On a related note,  Interp(3) still describes the client-visible
fields of the Tcl_Interp structure (interp->result, interp->freeProc,
and interp->errorLine) in detail, even though access
to these fields has been deprecated at least since Tcl 7.4
(released mid-1995) and *strongly* deprecated since Tcl 8.0
(released mid-1997).  Perhaps this should go away as well?

Are there any other deprecated APIs anyone can think of?


--Joe English

  jen...@fl...

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Linux Weekly News and Tcl

[Andreas K. <a.k...@we...>]

On http://www.lwn.net/2000/0727/devel.php3 I see a section about
'Language Links'. One perl and three python links, but none for tcl :(

Which sites should we submit to them for inclusion ?


Oh, on a side note, if the domains
	http://www.tcltk.org/,
	http://www.tcl-tk.org/

etc. are not available anymore, think about

	http://www.tcl-lang.org/

Ruby uses that format for its toplevel site.

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Creative Tcl ChangeLog entries.

[Brent W. <we...@aj...>]

I'm the guilty party - as an old-fart vi user I don't have the fancy
emacs macros to help me generate the ChangeLog file.  I'll be more
standard in the future.

>>>Mo DeJong said:
 > I don't mean to complain, but I have noticed some
 > "creative" entries showing up in Tcl and Tk
 > Changelogs.
 > 
 > Most ChangeLogs entries follow this format:
 > 
 >         * unix/Makefile.in:
 >         * win/Makefile.in: makefile cleanup
 > 
 > But there also seem to be some "creative" ones:
 > 
 >         * win/{Makefile.in,configure.in,tkConfig.sh.in}: 
 >         Cleanup of defines in tkConfig.sh
 > 
 > This conflicts with the GNU coding standards.
 > 
 > http://www.gnu.org/prep/standards.html
 > 
 > Could we please stick to the GNU standards? It really
 > does make you life easier later one. For instance,
 > I might grep the ChangeLog for "win/Makefile.in",
 > that would not match win/{Makefile.in,...
 > 
 > thanks
 > Mo DeJong
 > Red Hat Inc
 > 
 > --
 > The TclCore mailing list is sponsored by Ajuba Solutions
 > To unsubscribe:  email tcl...@aj... with the 
 >                  word UNSUBSCRIBE as the subject.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: [TCLCORE] Linux Weekly News and Tcl

[Brent W. <we...@aj...>]

www.tcltk.org is available and owned by Michael McLennan.
I believe he is waiting until the new Tcl Core Team stuff actually
materializes and has its own website.  While I appreciate the power
of that motivation, I would still love to see it as an alias for
dev.scriptics.com in the meantime.  As creator of the dev.scriptics.com
site I can assure you that we are all eager to see that replaced by
a community-run website.  Also, Ajuba is also ready to pony up the
machine and our ISP connection to host www.tcltk.org.  I'm not really
wedded to any particular Tcl-powered web site: TclHttpd, Velocigen,
AOLserver.  I already use two of those.

>>>Andreas Kupries said:
 > 
 > On http://www.lwn.net/2000/0727/devel.php3 I see a section about
 > 'Language Links'. One perl and three python links, but none for tcl :(
 > 
 > Which sites should we submit to them for inclusion ?
 > 
 > 
 > Oh, on a side note, if the domains
 > 	http://www.tcltk.org/,
 > 	http://www.tcl-tk.org/
 > 
 > etc. are not available anymore, think about
 > 
 > 	http://www.tcl-lang.org/
 > 
 > Ruby uses that format for its toplevel site.
 > 
 > -- 
 > Sincerely,
 > 	Andreas Kupries <a.k...@we...>
 > 		<http://www.purl.org/NET/akupries/>
 > ----------------------------------------------------------------------------
     ---
 > 
 > --
 > The TclCore mailing list is sponsored by Ajuba Solutions
 > To unsubscribe:  email tcl...@aj... with the 
 >                  word UNSUBSCRIBE as the subject.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com

[TCLCORE] Re: TclDomPro?

[Al B. <aw...@aj...>]

There's currently no immediate active development of TclDomPro here at
Ajuba.  Since our goal in making TDP open source was to accomplish
a merge with TclDom, and as the nominal maintainer of TDP here at
Ajuba, I'd say go ahead with your changes.

But let us know first about anything that changes the API.

- Al   

Joe English wrote:
> 
> What's the status of the TclDomPRO package?
> 
> I've fixed some bugs and added a feature to the copy that
> Steve Ball checked in (CVS module external/tcldom/src),
> but haven't applied these to the original copy
> (CVS module external/tcldompro/src).
> 
> I'm about to do some more serious hacking on tcldom/src
> to integrate it with the Zveno tcldom package,
> so I guess I ought to coordinate with whoever
> is maintaining the "Pro" version...
> 
> --Joe English
> 
>   jen...@fl...
> 
> (P.S. Re: Creative ChangeLog entries -- I'm one of the guilty
> parties -- sorry about that -- although I plead ignorance.
> As penance I will re-read the GNU coding standards document :-)

-- 

Albert Biggerstaff           Phone: (650) 210-0142
Ajuba Solutions              Email: aw...@aj...

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: friday's "Patch submittal for generic/tclExecute.c"

[<mi...@ut...>]

Sorry, stupid mistake: the patch file enclosed on friday's message won't
even compile! So, again, disregard my last message.

I am enclosing a corrected patch with this, only in case you might be
curious ...  This one does compile and pass the tests.

The performance difference being so small, I think it is quite
understndable if you chose to diregard the whole thing anyway. As I
said, I believe the main difference may be to the programmer who wants
to touch TclExecuteByteCode rather than in the program itself.

The next one will be either much much better, or else non-existent; I
fear I may be becoming a candidate for no-spam lists.

Greetings
Miguel

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Andreas K. <a.k...@we...>]

> Also sprach Jeffrey Hobbs:
 
>> ...  Sure, Tcl is great as it is, but for a lot of people its only
>> great when they have itcl, blt, tix, patches for better C++
>> compatibility, more data structures, etc etc.  Fewer and fewer are
>> truly satisfied with what the "core" provides.

> This is just slightly off the point, but I don't understand this
> last couple of sentences.  It seems like you are implying that the
> fact that the core of Tcl, by itself, is an incomplete solution for
> most complicated tasks is a bad thing.  Is that right?
 
> I thought the aim was to get more stuff out of the core (making it
> thereby even LESS satisfactory by itself) and then making the
> process of acquiring & deploying extensions so easy that you would
> never hesitate to do so...  That is still our goal, right?

I can't speak for the others, but for me this is one of the goals to
pursue and quite high on the priority list.


> As for introducing backwards incompatibilities, I agree with Brent a
> bit that we should not break Tcl compatibility unless there is some
> really compelling need.  I don't see any evils of the Tcl language
> that we are likely to cure in a good way (as opposed to, for
> instance, introducing some other comment syntax that breaks the
> current Tcl mold), that would require backwards incompatilibilities
> at the syntax level.  But in any case, this should be approached
> with some caution.

As can be seen in the discussion on c.l.t about {}$ and {}[ by Paul
Duffin.  I certainly like the basic idea behind that but the chosen
syntax was something which felt like syntactic salt to me (in opposition
to the syntactic sugar Richard Suchenwirth is so fond of).

> It would, on the other hand, be nice to rearrange some of the
> commands to be a little more coherent.  It would be good to gather
> all the list commands together,

Part of that is already done through the 'listx' command.

> and maybe even make the open & socket commands return objects, so we
> can get rid of this horrible mess of fconfigure, fblocked, eof...
> But I don't think that any of the subsystems are so badly designed
> right now that we couldn't provide wrappers for the old syntax...
 
> As for C level changes, this should really be a community vote type
> thing.  We need to balance the desire to clean up & make more
> powerful the new internals that were introduced in 8.0 & friends,
> with the need to carry along most of the major extensions.  So
> before we start wholesale changes like this, we should have a
> discussion of the merits, and make sure we have easy transition
> paths for all the many bits of C code out there...
 

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] TclDomPro?

[Joe E. <jen...@fl...>]

What's the status of the TclDomPRO package?

I've fixed some bugs and added a feature to the copy that
Steve Ball checked in (CVS module external/tcldom/src),
but haven't applied these to the original copy
(CVS module external/tcldompro/src).

I'm about to do some more serious hacking on tcldom/src
to integrate it with the Zveno tcldom package,
so I guess I ought to coordinate with whoever
is maintaining the "Pro" version...


--Joe English

  jen...@fl...

(P.S. Re: Creative ChangeLog entries -- I'm one of the guilty
parties -- sorry about that -- although I plead ignorance.
As penance I will re-read the GNU coding standards document :-)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Creative Tcl ChangeLog entries.

[Mo D. <md...@cy...>]

I don't mean to complain, but I have noticed some
"creative" entries showing up in Tcl and Tk
Changelogs.

Most ChangeLogs entries follow this format:

        * unix/Makefile.in:
        * win/Makefile.in: makefile cleanup

But there also seem to be some "creative" ones:

        * win/{Makefile.in,configure.in,tkConfig.sh.in}: 
        Cleanup of defines in tkConfig.sh

This conflicts with the GNU coding standards.

http://www.gnu.org/prep/standards.html

Could we please stick to the GNU standards? It really
does make you life easier later one. For instance,
I might grep the ChangeLog for "win/Makefile.in",
that would not match win/{Makefile.in,...

thanks
Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Karl L. <ka...@Ne...>]

Brent Welch wrote:

> I'm probably and old man here, but I think we can revitalize Tcl without
> breaking backwards compatibility.  In fact, enough incompatibility could
> really hurt us.  We've finally got a stable C API through stubs - it seems
> a shame to make gratuitous changes to "clean things up".

I agree with this 100%.

> Now, I'm all for things like Feather and factoring the core so it can
> be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
> some features, then they should be able to use Tcl 9 without major pain.
> I'd probably also live with a binary-incompatibilty but source-compatibilty
> approach, which is probably necessary if we muck with the Tcl_Obj and
> Tcl_ObjType structures.

I think factoring the core is interesting and has some cool aspects, and if
someone does it and does a good job, let's embrace it.  I don't think it will
yield very many new Tcl design wins.

I think it would be a big deal to have a build system that cranks out binary
releases of a mega-Tcl with lots of extensions across many platforms.  There was
some discussion of this recently in the newsgroup.  Any thoughts or ideas?

Karl


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Patch submittal for generic/tclExecute.c

[<mi...@ut...>]

Enclosed please find a patch file you might consider. It is a diff file
to
generic/tclExecute.c of tcl8.4a1; if I should rather send the complete
file,
please let me know. Remark that the file header (with CVS reference,
etc)
was NOT modified as it should ...

It modifies the file tclExecute.c (mainly the function
TclExecuteByteCode)
in the following manner:

A - Replaces the manner of addressing the Tcl stack; the programs do not

       use an index into an array but a pointer to the top item in the
stack. Hence
       the "idiom"  stackPtr[stackTop] is replaced by *stackTopPtr.

        This saves indexing into an array at every stack access, and
requires one
        fewer register variable - no need to keep stackPtr handy. On the
other hand,
        it costs an addition every time the stack is cached or decached
- because
        the environment keeps an index into the stack, and not the
address of the top
        item. It gives a modest speed increase (maybe 10% in the
bytecode-intensive
        parts of tclbench)

       The modifications are mainly in the macros DECACHE_STACK_INFO,
        CACHE_STACK_INFO, PUSH_OBJECT(objPtr) and POP_OBJECT.
        Declarations in several functions where changed, as well as
isolated
        instances of direct access to the stack (mainly in
TclExecuteByteCode,
        I can't remember if somewhere else also ...)


B - It does a general variable cleanup in TclExecuteByteCode. All
auxiliary variables
       are now constrained to blocks enclosing the different bytecode
instructions, except
        for those which really need to have function scope.

        Eliminates the variables opnd, pcAdjustment, valuePtr,
value2Ptr, objPtr, bytes,
        length and i from the function declaration.

        This "elimination of global variables" has probably no effect on
performance; I think
         however it will be of value to maintainers as it simplifies the
analysis of instructions.


Your comments are of course welcome.  Cheers

Miguel Sofer

Re: [TCLCORE] Re: Notes about Perl6 ideas - good to read

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

> Also sprach Jeffrey Hobbs:
 
>> ...  Sure, Tcl is great as it is, but for a lot of people its only
>> great when they have itcl, blt, tix, patches for better C++
>> compatibility, more data structures, etc etc.  Fewer and fewer are
>> truly satisfied with what the "core" provides.

> This is just slightly off the point, but I don't understand this
> last couple of sentences.  It seems like you are implying that the
> fact that the core of Tcl, by itself, is an incomplete solution for
> most complicated tasks is a bad thing.  Is that right?
 
> I thought the aim was to get more stuff out of the core (making it
> thereby even LESS satisfactory by itself) and then making the
> process of acquiring & deploying extensions so easy that you would
> never hesitate to do so...  That is still our goal, right?

I can't speak for the others, but for me this is one of the goals to
pursue and quite high on the priority list.


> As for introducing backwards incompatibilities, I agree with Brent a
> bit that we should not break Tcl compatibility unless there is some
> really compelling need.  I don't see any evils of the Tcl language
> that we are likely to cure in a good way (as opposed to, for
> instance, introducing some other comment syntax that breaks the
> current Tcl mold), that would require backwards incompatilibilities
> at the syntax level.  But in any case, this should be approached
> with some caution.

As can be seen in the discussion on c.l.t about {}$ and {}[ by Paul
Duffin.  I certainly like the basic idea behind that but the chosen
syntax was something which felt like syntactic salt to me (in opposition
to the syntactic sugar Richard Suchenwirth is so fond of).

> It would, on the other hand, be nice to rearrange some of the
> commands to be a little more coherent.  It would be good to gather
> all the list commands together,

Part of that is already done through the 'listx' command.

> and maybe even make the open & socket commands return objects, so we
> can get rid of this horrible mess of fconfigure, fblocked, eof...
> But I don't think that any of the subsystems are so badly designed
> right now that we couldn't provide wrappers for the old syntax...
 
> As for C level changes, this should really be a community vote type
> thing.  We need to balance the desire to clean up & make more
> powerful the new internals that were introduced in 8.0 & friends,
> with the need to carry along most of the major extensions.  So
> before we start wholesale changes like this, we should have a
> discussion of the merits, and make sure we have easy transition
> paths for all the many bits of C code out there...
 

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Jeffrey H. <jef...@aj...>]

I should have noted this before, but my initial post was just a
copy of the one I made on the newsgroup (in response to Laird,
subject: Content of the Perl6 talk), since many that are on the
CC list may not get the opportunity to read everything on the
newsgroup regularly.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

> -----Original Message-----
> From: John Ousterhout [mailto:ou...@aj...]
> Subject: [TCLCORE] Re: Notes about Perl6 ideas - good to read
> 
> 
> May I suggest that we should move most of these discussions to
> comp.lang.tcl?  If we want to eliminate the appearance of a group
> of Tcl "insiders", it would be better to make these discussions
> as public as possible.
> 
> -John-

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[John O. <ou...@aj...>]

May I suggest that we should move most of these discussions to
comp.lang.tcl?  If we want to eliminate the appearance of a group
of Tcl "insiders", it would be better to make these discussions
as public as possible.

-John-

At 11:09 AM 7/28/2000 -0700, Mo DeJong wrote:
>On Fri, 28 Jul 2000, Jim Ingham wrote:
>
> > I thought the aim was to get more stuff out of the core (making it thereby
> > even LESS satisfactory by itself) and then making the process of acquiring &
> > deploying extensions so easy that you would never hesitate to do so...  That
> > is still our goal, right?
>
>I hope that is still the goal. We do need to do some work to make
>it easier to build and add new extensions, but I think we have the
>right goal.
>
> > As for introducing backwards incompatibilities, I agree with Brent a bit
> > that we should not break Tcl compatibility unless there is some really
> > compelling need.  I don't see any evils of the Tcl language that we are
> > likely to cure in a good way (as opposed to, for instance, introducing some
> > other comment syntax that breaks the current Tcl mold), that would require
> > backwards incompatilibilities at the syntax level.  But in any case, this
> > should be approached with some caution.
>
>I don't think we need any syntax changes. I do think that a "no commands
>must ever change" mentality will end up making things a lot harder
>in the long run. Honestly, if you need to run some 10 year old code,
>why can't you use an old version of Tcl? Why can't you do a bit of
>porting to get it working with Tcl 9.0?
>
> > It would, on the other hand, be nice to rearrange some of the commands to be
> > a little more coherent.  It would be good to gather all the list commands
> > together, and maybe even make the open & socket commands return objects, so
> > we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
> > don't think that any of the subsystems are so badly designed right now that
> > we couldn't provide wrappers for the old syntax...
>
>I would suggest that folks check out my EasySocket API, is it a
>lot easier to use than the plain socket interface.
>
>Mo DeJong
>Red Hat Inc 

________________________________________________________________________
John Ousterhout                            650-210-0102 tel
Chairman and Chief Technology Officer      650-230-4070 fax
Ajuba Solutions                            ou...@aj...
(Scriptics has changed its name...)        http://www.ajubasolutions.com

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Mo D. <md...@cy...>]

On Fri, 28 Jul 2000, Jim Ingham wrote:

> I thought the aim was to get more stuff out of the core (making it thereby
> even LESS satisfactory by itself) and then making the process of acquiring &
> deploying extensions so easy that you would never hesitate to do so...  That
> is still our goal, right?

I hope that is still the goal. We do need to do some work to make
it easier to build and add new extensions, but I think we have the
right goal.

> As for introducing backwards incompatibilities, I agree with Brent a bit
> that we should not break Tcl compatibility unless there is some really
> compelling need.  I don't see any evils of the Tcl language that we are
> likely to cure in a good way (as opposed to, for instance, introducing some
> other comment syntax that breaks the current Tcl mold), that would require
> backwards incompatilibilities at the syntax level.  But in any case, this
> should be approached with some caution.

I don't think we need any syntax changes. I do think that a "no commands
must ever change" mentality will end up making things a lot harder
in the long run. Honestly, if you need to run some 10 year old code,
why can't you use an old version of Tcl? Why can't you do a bit of
porting to get it working with Tcl 9.0?

> It would, on the other hand, be nice to rearrange some of the commands to be
> a little more coherent.  It would be good to gather all the list commands
> together, and maybe even make the open & socket commands return objects, so
> we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
> don't think that any of the subsystems are so badly designed right now that
> we couldn't provide wrappers for the old syntax...

I would suggest that folks check out my EasySocket API, is it a
lot easier to use than the plain socket interface.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Jim I. <ji...@ap...>]

Also sprach Jeffrey Hobbs:

>                           ...  Sure, Tcl is great as it is, but for a lot
> of people its only great when they have itcl, blt, tix, patches for better
> C++ compatibility, more data structures, etc etc.  Fewer and fewer are
> truly satisfied with what the "core" provides.

This is just slightly off the point, but I don't understand this last couple
of sentences.  It seems like you are implying that the fact that the core of
Tcl, by itself, is an incomplete solution for most complicated tasks is a
bad thing.  Is that right?

I thought the aim was to get more stuff out of the core (making it thereby
even LESS satisfactory by itself) and then making the process of acquiring &
deploying extensions so easy that you would never hesitate to do so...  That
is still our goal, right?

As for introducing backwards incompatibilities, I agree with Brent a bit
that we should not break Tcl compatibility unless there is some really
compelling need.  I don't see any evils of the Tcl language that we are
likely to cure in a good way (as opposed to, for instance, introducing some
other comment syntax that breaks the current Tcl mold), that would require
backwards incompatilibilities at the syntax level.  But in any case, this
should be approached with some caution.

It would, on the other hand, be nice to rearrange some of the commands to be
a little more coherent.  It would be good to gather all the list commands
together, and maybe even make the open & socket commands return objects, so
we can get rid of this horrible mess of fconfigure, fblocked, eof...  But I
don't think that any of the subsystems are so badly designed right now that
we couldn't provide wrappers for the old syntax...

As for C level changes, this should really be a community vote type thing.
We need to balance the desire to clean up & make more powerful the new
internals that were introduced in 8.0 & friends, with the need to carry
along most of the major extensions.  So before we start wholesale changes
like this, we should have a discussion of the merits, and make sure we have
easy transition paths for all the many bits of C code out there...

Jim
-- 
Jim Ingham                                 ji...@ap...
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Jeffrey H. <jef...@aj...>]

I should note that it's not just Perl6, but the next major rev of Python
that has clearly announced that it will sacrifice some aspect of backwards
compatability (although they aren't as far along in public planning yet).

Is it major pain when just a translation script is needed?  I think that
Tcl is already a better language in that we could likely provide a Tcl
level compatability mode that's like the translation on the fly.  Thus
the request for 'package require Tcl 8' in Tcl9 would shift around the
necessary bits to make it look like Tcl8.  The user wouldn't gain whatever
advantages Tcl9 has, but things would still work.  I think we could
achieve that with 99% compatability at the Tcl level.

Tcl at the C level would be trickier, as we'd want to reconsider some of
the designs of basic public structures (like Tcl_Obj, and finally getting
the Var structures public).  Sure, Tcl is great as it is, but for a lot
of people its only great when they have itcl, blt, tix, patches for better
C++ compatibility, more data structures, etc etc.  Fewer and fewer are
truly satisfied with what the "core" provides.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

> -----Original Message-----
> From: Brent Welch [mailto:we...@aj...]
	...
> I'm probably and old man here, but I think we can revitalize Tcl without
> breaking backwards compatibility.  In fact, enough incompatibility could
> really hurt us.  We've finally got a stable C API through stubs - it seems
> a shame to make gratuitous changes to "clean things up".
>
> Now, I'm all for things like Feather and factoring the core so it can
> be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
> some features, then they should be able to use Tcl 9 without major pain.
> I'd probably also live with a binary-incompatibilty but source-compatibilty
> approach, which is probably necessary if we muck with the Tcl_Obj and
> Tcl_ObjType structures.

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Notes about Perl6 ideas - good to read

[Brent W. <we...@aj...>]

I'm probably and old man here, but I think we can revitalize Tcl without
breaking backwards compatibility.  In fact, enough incompatibility could
really hurt us.  We've finally got a stable C API through stubs - it seems
a shame to make gratuitous changes to "clean things up".

Now, I'm all for things like Feather and factoring the core so it can
be smaller, but if someone doesn't want a "Tcl-lite" that just eliminates
some features, then they should be able to use Tcl 9 without major pain.
I'd probably also live with a binary-incompatibilty but source-compatibilty
approach, which is probably necessary if we muck with the Tcl_Obj and
Tcl_ObjType structures.

>>>"Jeffrey Hobbs" said:
 > A Ruby user's perspective on the announced plans:
 > 	http://deja.com/=dnc/getdoc.xp?AN=651665267
 > 
 > And a more Perl-oriented technical perspective:
 > 	http://www.perl.com/pub/2000/07/perl6.html
 > 
 > These are good notes about planning for a major revision upgrade, most
 > notably that Perl6 plans to break compatability with Perl5, maintaining
 > upwards compatability only via a translation script (that won't guarantee
 > 100% compatability).
 > 
 > Perhaps before we start to worry too much about the nearer term but not
 > ambitious 8.4, whoever becomes the future Tcl Core Team should focus on
 > Tcl9 and a plan to truly revitalize Tcl.
 > 
 > Jeffrey Hobbs                     Tcl Ambassador
 > ho...@Aj...          Ajuba Solutions (née Scriptics)
 > 
 > --
 > The TclCore mailing list is sponsored by Ajuba Solutions
 > To unsubscribe:  email tcl...@aj... with the 
 >                  word UNSUBSCRIBE as the subject.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Notes about Perl6 ideas - good to read

[Jeffrey H. <jef...@aj...>]

A Ruby user's perspective on the announced plans:
	http://deja.com/=dnc/getdoc.xp?AN=651665267

And a more Perl-oriented technical perspective:
	http://www.perl.com/pub/2000/07/perl6.html

These are good notes about planning for a major revision upgrade, most
notably that Perl6 plans to break compatability with Perl5, maintaining
upwards compatability only via a translation script (that won't guarantee
100% compatability).

Perhaps before we start to worry too much about the nearer term but not
ambitious 8.4, whoever becomes the future Tcl Core Team should focus on
Tcl9 and a plan to truly revitalize Tcl.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.