tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Lars H. <Lar...@re...>]

Kevin Kenny skrev 2011-02-16 03.27:
> On 02/15/2011 01:04 PM, Andreas Kupries wrote:
>> Regarding the core assumption behind the argument, of git not being good on
>> Win, that I can't really evaluate. I haven't used git very much and not at all
>> on Windows.
>
> Git sort of works on Windows, but you have to install a ton of other
> stuff first, and I'd practically have to virtualize to do it (cygwin
> conflicts and the like). Fossil is a single executable on Windows and
> works just as well there as it does on Unix. My only annoyance is that
> it cannot be configured to do line-ending substitution.

That could actually be a show-stopper. It seems that quite commonly editors 
on Windows (at least those which students can easily obtain, install, and 
use) can only do CRLF line-ends, whereas Unix utilities (of course) insist on 
LF. Not getting line conversions out-of-the-box is to be asking for trouble.

Lars Hellström

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Lars H. <Lar...@re...>]

Will Duquette skrev 2011-02-15 01.32:
> Lars,
>
> Provable immutability is one of Fossil's requirements; in the development
> arena that Richard was (and might still be) targetting, it was required that
> a file with a given revision UUID could simply not be changed.

But that's true for git too! The rebase command *cannot* change the data in 
an existing commit. It creates a new commit, which frequently has the same 
contents (tree) as the original, but since it has a different history it will 
also have a different ID.

> You can read
> more about that at the fossil website. This is not a requirement for most
> users. In short, I don't think Richard is saying that git is substandard in
> this area, but rather that Fossil provides a stronger form of immutability if
> you happen to need that.

The point where I fear Richard is making an unfounded claim is rather the 
point before, where he says "Single file database (fossil): good, safe. Pile 
of files on disk like git: bad, unsafe." The thing he worries about seems to 
be corruption of data due to interrupted updates of it (and as a database 
expert, it is his job to be concerned about this). However, because of the 
immutability of objects (blobs, trees, and commits) in a git repository, the 
files which store these /aren't/ updated; "modified" contents will, by virtue 
of being different, receive a different ID and therefore end up in a 
different file.

The whole thing is actually quite similar to the way Tcl handles values and 
variables. Commits, trees, and blobs are immutable like a value (indeed, this 
is very much because EIAS), while "branch heads" and tags are mutable like a 
variable. You can change what value is stored in a variable, but you cannot 
alter the value itself.

Lars Hellström

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Jeff H. <je...@Ac...>]

On 2011-02-15, at 6:27 PM, Kevin Kenny wrote:
> On 02/15/2011 01:04 PM, Andreas Kupries wrote:
>> Regarding the core assumption behind the argument, of git not being good on
>> Win, that I can't really evaluate. I haven't used git very much and not at all
>> on Windows.
> 
> Git sort of works on Windows, but you have to install a ton of other
> stuff first, and I'd practically have to virtualize to do it (cygwin
> conflicts and the like). Fossil is a single executable on Windows and
> works just as well there as it does on Unix. My only annoyance is that
> it cannot be configured to do line-ending substitution. One of these
> days I'll do some scripts to work around it; I understand drh's
> reluctance to have the capability in the fossil mainline, given
> that the committed version of a file must be bit-for-bit identical
> to what the developer presented.

That is false logic, and is why all other revision control systems have the option to tag a file as text or binary.  To the developer, it's not bit-for-bit a file, it is a TEXT file with set contents.  You should be able to diff, push and pull those across different OSes and see exactness (or lack thereof) in a TEXT context.

Jeff

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Kevin K. <kk...@ny...>]

On 02/15/2011 01:04 PM, Andreas Kupries wrote:
> Regarding the core assumption behind the argument, of git not being good on
> Win, that I can't really evaluate. I haven't used git very much and not at all
> on Windows.

Git sort of works on Windows, but you have to install a ton of other
stuff first, and I'd practically have to virtualize to do it (cygwin
conflicts and the like). Fossil is a single executable on Windows and
works just as well there as it does on Unix. My only annoyance is that
it cannot be configured to do line-ending substitution. One of these
days I'll do some scripts to work around it; I understand drh's
reluctance to have the capability in the fossil mainline, given
that the committed version of a file must be bit-for-bit identical
to what the developer presented.

-- 
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Kevin K. <kk...@ny...>]

On 02/15/2011 01:01 PM, Donald G Porter wrote:
> ...that's not been the history of these packages, and since a big part
> of SCM is preserving history, that presses toward keeping things
> together.
>
> Also, those packages are not separately releaseable in their current
> state.  (All the control over `make install` for them is over in Tcl's
> Makefile, etc.; their tests, docs, and ChangeLogs are all mixed into
> Tcl's).
>
> So for now, I've decided not to do that level of breaking up, and just
> accept that if breaking apart does become feasible later, it will be a
> more difficult task to confront then.

And not even *much* more difficult.  It's easy to *extract* history.
What's insanely difficult is to *merge* history.  Which is what we face
in any CVS->DVCS conversion; CVS maintains all history on the individual
files, and we're trying to reconstruct coherent changesets and branch
histories from the histories of the files.  Once you have changesets,
it's easy to filter out only those changesets that affect a given
set of files and lift them out.  (Not trivial, but much easier than
a CVS conversion.)

-- 
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Damon C. <da...@tc...>]

> Even with going "git" Tcl(lib)s visibility is determined by actual marketing, 
> i.e. evangelization.

Yes, but you can't argue that Tcl will get more visibility on some fossil site than on some place like Github.  Github has tremendous momentum behind it and has some really nice tools available.  Though I would caution against their issue tracker since it is VERY barebones and kinda sucks.  Also we run into the same issue of being able to get our data back out.

Once we move to a DVCS we never need worry about getting our data back from someone else ever again.  Everyone with a copy has all the history and data.  Placing Tcl on Github can only help with visibility.

> There is one argument which I was told in private mail, against "git", namely 
> that it(s support) is not very good on windows, and that this might drive 
> developers away, given that Tcl prides itself on good x-platform portability, 
> which means that we need good windows support in our tools for easy development 
> on that platform. At least for those people not using a mix of platforms like 
> me (*).
> 
> Regarding the core assumption behind the argument, of git not being good on 
> Win, that I can't really evaluate. I haven't used git very much and not at all 
> on Windows.
> 
> Given my own preference for fossil I will certainly ask this question on the 
> fossil list as well, for while I am using fossil often now I haven't used it on 
> windows either.

Git on Windows is fine.  It uses MSYS, which is not ideal, but with msysgit and TortoiseGit, you can be up and running doing Windows development in minutes.  I use Git (and Github) for most of my projects now, and setting things up Windows has never been anything more than running a couple of installers.

I'm familiar enough with Fossil as well, and I think either one would be a fine choice on their technical merits.  So much so that I don't even feel it's worth arguing.  You want to argue the difference between the engine in a Honda vs. a Toyota, but both are damn good engines and will get you where you need to go without a care.  It's the trim and options we need to be looking at.

Git has a TON of momentum behind it, both open source and commercial.  I've been really surprised at the number of tools I've seen being created around Git.  Given that I've only played with Fossil a little, I can't speak to the "options" it offers, but I've seen a few.  A wiki?  We already have a great wiki that is used by everyone in the community.  A bug tracker?  Well, that's definitely nice to have as we have seen that as a problem in the past.

But a bug tracker can be written by any Tcl'er in a few nights if we had a mind to.  There are other commercial and open source solutions out there, but do we want to get stuck in holding our data in another proprietary silo?  That would be the one major advantage to Fossil is that the bugs are kept along with the source.

What else?

D

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

On 2/14/2011 4:41 PM, Michael Schlenker wrote:
> Hi Andreas,
>
> I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use.
>
>  From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of
> users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves
> us forward faster, who cares?

> And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share.
>
> So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using

I should clarify here my previous example/argument I made, about the GSoC 
student. The argument is one of "lower barrier to entry". It is not a 
(auto)magic visibility of the form "If you build it they will come".

Even with going "git" Tcl(lib)s visibility is determined by actual marketing, 
i.e. evangelization.

There is one argument which I was told in private mail, against "git", namely 
that it(s support) is not very good on windows, and that this might drive 
developers away, given that Tcl prides itself on good x-platform portability, 
which means that we need good windows support in our tools for easy development 
on that platform. At least for those people not using a mix of platforms like 
me (*).

Regarding the core assumption behind the argument, of git not being good on 
Win, that I can't really evaluate. I haven't used git very much and not at all 
on Windows.

Given my own preference for fossil I will certainly ask this question on the 
fossil list as well, for while I am using fossil often now I haven't used it on 
windows either.


> a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate.

I would not describe fossil as 'fringe' with its negative connotations. Niche, 
yes, fringe, no.

> I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best
> of breed for sure, so both fossils trackers and github or others might offer improvements.

(*) With the mix of boxes I have access to, and the shared file systems all the 
VCS ops happen on linux and files are copied to windows boxes for building. No 
direct VCS ops on the windows boxes.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Donald G P. <don...@ni...>]

Andreas Kupries wrote:
Donald G Porter wrote:
>> So, if there's ever a dream to make separate releases of the packages
>> that make up tcllib, that task will be far easier if they each go into
>> their own repositories now, as part of this transition. (*)

Andreas Kupries wrote:
> Huh. Yes. A difficult topic.

Just a bit more on it.

The same issues confront the tcl/library/* subdirs in a Tcl distro.
In principle, we can imagine the msgcat, tcltest, opt, http, etc.
packages getting released separate from Tcl.  And I find something
attractive about imagining that's a state we will reach one day.

But...

...that's not been the history of these packages, and since a big part
of SCM is preserving history, that presses toward keeping things
together.

Also, those packages are not separately releaseable in their current
state.  (All the control over `make install` for them is over in Tcl's
Makefile, etc.; their tests, docs, and ChangeLogs are all mixed into
Tcl's).

So for now, I've decided not to do that level of breaking up, and just
accept that if breaking apart does become feasible later, it will be a
more difficult task to confront then.

If similar descriptions cover the tcllib packages, I think it sensible
to reach the same conclusion.

Contrast with the Thread package, which has a separate history, has made
separate releases, and is only now coming into tcl/pkgs.  That one made
sense to make a separate repository from the beginning.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

On 2/15/2011 6:33 AM, Donald G Porter wrote:
> Andreas Kupries wrote:
>> One last issue. As (1) shows, we have lots of subprojects. Seven. While these
>> are all handled by a single CVS repository directory hierarchy, when going to
>> DVCS we should really split them up, each as their own XXX repository. One of
>> them, tclbench, should possibly even migrate out of the tcllib more to the
>> core itself, given that it is the core whose performance this project is
>> testing.
>
> Something to consider, if only briefly...
>
> One guideline that came out of the chat discussion on these matters is
> "Separately releaseable things should have separate repositories"
>
> So, if there's ever a dream to make separate releases of the packages
> that make up tcllib, that task will be far easier if they each go into
> their own repositories now, as part of this transition. (*)
>
> OTOH, if that's never going to happen, then that would be significant
> work for no benefit.
>
> I can support either choice, but I mention the question so the choice
> is made actively, not passively.

> (*) Or to support the ability to take a select subset of tcllib for
> re-distribution under tcl/pkgs/

Huh. Yes. A difficult topic.

On the one hand, each of the packages inside the tcllib and tklib bundles can, 
theoretically, be released on its own.

On the other hand, the forces which drove the bundling are not really gone. The 
TEA framework we have is very good for binary packages, and not so much for 
pure Tcl. With a package consisting of two files (.tcl and pkgIndex) the 
overhead is high, plus impedance mismatches in the standard code. The bundling 
allowed us to amortize the cost of maintaining a pseudo-TEA configure/Makefile 
across many packages. That is still true, I believe.

And yes, I am aware that I am possibly opening another can of worms^W^W^Wline 
of discussion here which is, I believe one of our big pain points.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Donald G P. <don...@ni...>]

Andreas Kupries wrote:
> One last issue. As (1) shows, we have lots of subprojects. Seven. While these 
> are all handled by a single CVS repository directory hierarchy, when going to 
> DVCS we should really split them up, each as their own XXX repository. One of 
> them, tclbench, should possibly even migrate out of the tcllib more to the core 
> itself, given that it is the core whose performance this project is testing.

Something to consider, if only briefly...

One guideline that came out of the chat discussion on these matters is
"Separately releaseable things should have separate repositories"

So, if there's ever a dream to make separate releases of the packages
that make up tcllib, that task will be far easier if they each go into
their own repositories now, as part of this transition. (*)

OTOH, if that's never going to happen, then that would be significant
work for no benefit.

I can support either choice, but I mention the question so the choice
is made actively, not passively.

(*) Or to support the ability to take a select subset of tcllib for
re-distribution under tcl/pkgs/

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Arjen M. <arj...@de...>]

Hi everybody,

On 2011-02-15 08:58, Steve Landers wrote:
> On 15/02/2011, at 3:41 PM, Harald Oehlmann wrote:
> 
>> Am 15.02.2011 02:10, schrieb Andreas Kupries:
>>> On 2/14/2011 4:36 PM, Will Duquette wrote:
>>>> It probably makes sense to adopt whatever is adopted for the Tcl core.
>>> Gerald Lester made the same point in direct mail.
>>>
>> Same opinion, tcllib is tcl - keep it close.
> 
> Same opinion, with one caveat. Make sure the Tcl core developers keep the needs of Tcllib developers in mind too.  Or (put differently) the decision isn't only about maintaining C code in the core.
> 

I have no strong opinions one way or the other, except that I have
experience with fossil, not with git. It seems quite sensible to adopt
the same solution as for Tcl, but Steve's remark does raise a question:
how would the needs for maintaining C and for maintaining Tcl differ?
And how would that influence the decision for either?

Regards,

Arjen
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Steve L. <st...@di...>]

On 15/02/2011, at 3:41 PM, Harald Oehlmann wrote:

> Am 15.02.2011 02:10, schrieb Andreas Kupries:
>> On 2/14/2011 4:36 PM, Will Duquette wrote:
>>> It probably makes sense to adopt whatever is adopted for the Tcl core.
>> 
>> Gerald Lester made the same point in direct mail.
>> 
> Same opinion, tcllib is tcl - keep it close.

Same opinion, with one caveat. Make sure the Tcl core developers keep the needs of Tcllib developers in mind too.  Or (put differently) the decision isn't only about maintaining C code in the core.

Steve

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Harald O. <har...@el...>]

Am 15.02.2011 02:10, schrieb Andreas Kupries:
> On 2/14/2011 4:36 PM, Will Duquette wrote:
>> It probably makes sense to adopt whatever is adopted for the Tcl core.
> 
> Gerald Lester made the same point in direct mail.
> 
Same opinion, tcllib is tcl - keep it close.

Sorry Andreas, I have checked in bwidget stuff yesterday.

-Harald

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

On 2/14/2011 4:36 PM, Will Duquette wrote:
> It probably makes sense to adopt whatever is adopted for the Tcl core.

Gerald Lester made the same point in direct mail.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Michael S. <sc...@un...>]

Hi Andreas,

I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use.

From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of
users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves
us forward faster, who cares?

And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share.

So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using
a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate.

I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best
of breed for sure, so both fossils trackers and github or others might offer improvements.

Michael









 



 

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Will D. <wi...@wj...>]

Andreas,

I don't have any particular preference.  I use fossil, and like it; git is clearly worth learning, and I've been meaning to do that.  And either will work.

I think the question is, do we want to host it "ourselves", in which case Fossil is the big winner, or do we want to let someone else host it, in which case git is the big winner.

It probably makes sense to adopt whatever is adopted for the Tcl core.

Will

On Feb 14, 2011, at 1:21 PM, Andreas Kupries wrote:

> Hi all you developers of Tcllib, Tklib, BWidget, etc. ..
> 
> You might have noted that the SourceForge CVS was down for two weeks,
> after a hack attack on them.
> 
> This downtime ended last week, allowing us, in principle, to continue 
> development and re-start commits.
> 
> There is however a fly in the soup. Quoting from Jeff's mail to tcl-core
> 
> 	In the interim, SF also let us know that cvs is now considered
> 	a legacy service.
> 
> In other words, the end-of-life of CVS repositories on SF, and maybe in general 
> is on the radar now, and it behooves us, IMHO, to do the transition to 
> something else _now_.
> 
> As such I ask everyone to hold back from commiting anything to any of the 
> projects under tcllib (1) until we have this issue resolved.
> 
> 
> While SourceForge apparently will offer a migration service from CVS to SVN I 
> agree with Jeff that we should transition to a proper DVCS instead.
> 
> Related to the choicce of DVCS is also the issue of hosting, i.e. depending on 
> what our choice of system we have less or more options for hosting.
> 
> Following the discussions on the chat, about the same issue, only for core 
> Tcl/Tk the main contenders are
> 
> 	our own Richard Hipp's "fossil" 	(2),
> 	and the ubiquitous 800lb gorilla "git"	(3)
> 
> From a technical point of view both will do the job, and are pretty much 
> equivalent. Conversion to either should be relatively trivial via "cvs2git" 
> (4), both support the fast-export file-format generated by the converter.
> 
> Non-technical arguments for either are
> 
> *	fossil is small, clean, simple, easy to learn, with the developer part
> 	of the Tcl community, and known to be responsive. Pretty much on call.
> 
> *	git, while not small, and with a steep learning curve, however is
> 	*ubiquitous*, with a much larger community. Students learn it.
> 	Using it means that a GSoC student (for example), can simply be
> 	pointed to the git repository and told to branch.
> 
> *	On the hosting front, using git give us lots of alternatives as:
> 
> 		SourceForge, github, gitorious(sp?), assembla
> 
> *	For fossil we either have to either use the pretty much unknown
> 
> 		chiselapp
> 
> 	or self-host. The latter might actually not be to onerous, given that
> 	fossil comes with a builtin web server. Just needs a box.
> 
> *	Richard has its own comparison and reasons for either at
> 	http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
> 
> 
> Do I have my own preference ? Yes. And I sincerely hope that I managed to keep 
> it out of the arguments above.
> 
> 
> One last issue. As (1) shows, we have lots of subprojects. Seven. While these 
> are all handled by a single CVS repository directory hierarchy, when going to 
> DVCS we should really split them up, each as their own XXX repository. One of 
> them, tclbench, should possibly even migrate out of the tcllib more to the core 
> itself, given that it is the core whose performance this project is testing.
> 
> Discussion is open.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (1) Which are
> 	bwidget
> 	mclistbox
> 	tclapps
> 	tclbench
> 	tcllib	(sic)
> 	tklib
> 	widget
> 
> (2)	http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
> (3)	http://www.kernel.org/pub/software/scm/git/docs/git.html
> 
> (4)	In contrast to Tcl/Tk core tcllib does not have vendor branches in the
> 	history AFAIK.
> 
> -- 
> Andreas Kupries
> Senior Tcl Developer
> ActiveState, The Dynamic Language Experts
> 
> P: 778.786.1122
> F: 778.786.1133
> and...@ac...
> http://www.activestate.com
> Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel


Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Will D. <wi...@wj...>]

Lars,

Provable immutability is one of Fossil's requirements; in the development arena that Richard was (and might still be) targetting, it was required that a file with a given revision UUID could simply not be changed.  You can read more about that at the fossil website.  This is not a requirement for most users.  In short, I don't think Richard is saying that git is substandard in this area, but rather that Fossil provides a stronger form of immutability if you happen to need that.

Will

On Feb 14, 2011, at 3:10 PM, Lars Hellström wrote:

> Andreas Kupries skrev 2011-02-14 22.21:
>> *	fossil is small, clean, simple, easy to learn,
> [snip]
>> *	git, while not small, and with a steep learning curve,
> 
> Hmm... I have to say I find those claims somewhat contrary to own experience, 
> although I cannot claim that this experience would constitute a comprehensive 
> survey of both systems. In particular:
> 
>  * IMHO git both seems fairly small and wasn't too hard to learn.
>    (Once I got past the slightly scary step that one was supposed to
>    use git to download the manpages for git.)
> 
>  * Fossil having tickets, wiki, and blog built in doesn't strike me as
>    clean (possibly convenient, if you want those features, but not clean),
>    and should pose a challenge to being small. But perhaps the comparison
>    is with git + 3rd party tools for tickets, wiki, and blog.
> 
>  * The web interface to Fossil regularly strikes me as being awkward,
>    at least when one encounters it as an outsider (which is not a use-case
>    that should be ignored); the requirement to log in as anonymous to
>    access certain information is particularly discouraging. It may seem
>    more natural for registered users, however.
> 
>> *	Richard has its own comparison and reasons for either at
>> 	http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
> 
> That does take a rather "databases are where it's at" view of the matter, 
> which is not surprising given DRH's area of expertise, but in some cases I 
> find myself wondering how deep the analysis is that underlies his evaluation 
> of git. In particular the points about immutability and pile-of-files seem 
> open to interpretation; git does have immutability, but it is local rather 
> than the global immutability fossil appears to set as standard. The "git uses 
> pile-of-files, hence it is transactionally unsafe" point in that summary 
> /may/ be based on discovering a proper vulnerability in git, but I /fear/ it 
> could rather be based on a failure to understand that local immutability 
> suffices for the wanted transactional safety. I would appreciate it if DRH 
> can lay that fear to rest, however.
> 
>> Do I have my own preference ? Yes. And I sincerely hope that I managed to keep
>> it out of the arguments above.
> 
> Well, if your intent was to not show your own preferrence, then you probably 
> failed. :-)
> 
> Lars Hellström
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel


Will Duquette, OP
will -at- wjduquette dot com  
http://foothills.wjduquette.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Lars H. <Lar...@re...>]

Andreas Kupries skrev 2011-02-14 22.21:
> *	fossil is small, clean, simple, easy to learn,
[snip]
> *	git, while not small, and with a steep learning curve,

Hmm... I have to say I find those claims somewhat contrary to own experience, 
although I cannot claim that this experience would constitute a comprehensive 
survey of both systems. In particular:

  * IMHO git both seems fairly small and wasn't too hard to learn.
    (Once I got past the slightly scary step that one was supposed to
    use git to download the manpages for git.)

  * Fossil having tickets, wiki, and blog built in doesn't strike me as
    clean (possibly convenient, if you want those features, but not clean),
    and should pose a challenge to being small. But perhaps the comparison
    is with git + 3rd party tools for tickets, wiki, and blog.

  * The web interface to Fossil regularly strikes me as being awkward,
    at least when one encounters it as an outsider (which is not a use-case
    that should be ignored); the requirement to log in as anonymous to
    access certain information is particularly discouraging. It may seem
    more natural for registered users, however.

> *	Richard has its own comparison and reasons for either at
> 	http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

That does take a rather "databases are where it's at" view of the matter, 
which is not surprising given DRH's area of expertise, but in some cases I 
find myself wondering how deep the analysis is that underlies his evaluation 
of git. In particular the points about immutability and pile-of-files seem 
open to interpretation; git does have immutability, but it is local rather 
than the global immutability fossil appears to set as standard. The "git uses 
pile-of-files, hence it is transactionally unsafe" point in that summary 
/may/ be based on discovering a proper vulnerability in git, but I /fear/ it 
could rather be based on a failure to understand that local immutability 
suffices for the wanted transactional safety. I would appreciate it if DRH 
can lay that fear to rest, however.

> Do I have my own preference ? Yes. And I sincerely hope that I managed to keep
> it out of the arguments above.

Well, if your intent was to not show your own preferrence, then you probably 
failed. :-)

Lars Hellström

[Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

Hi all you developers of Tcllib, Tklib, BWidget, etc. ..

You might have noted that the SourceForge CVS was down for two weeks,
after a hack attack on them.

This downtime ended last week, allowing us, in principle, to continue 
development and re-start commits.

There is however a fly in the soup. Quoting from Jeff's mail to tcl-core

	In the interim, SF also let us know that cvs is now considered
	a legacy service.

In other words, the end-of-life of CVS repositories on SF, and maybe in general 
is on the radar now, and it behooves us, IMHO, to do the transition to 
something else _now_.

As such I ask everyone to hold back from commiting anything to any of the 
projects under tcllib (1) until we have this issue resolved.


While SourceForge apparently will offer a migration service from CVS to SVN I 
agree with Jeff that we should transition to a proper DVCS instead.

Related to the choicce of DVCS is also the issue of hosting, i.e. depending on 
what our choice of system we have less or more options for hosting.

Following the discussions on the chat, about the same issue, only for core 
Tcl/Tk the main contenders are

	our own Richard Hipp's "fossil" 	(2),
	and the ubiquitous 800lb gorilla "git"	(3)

 From a technical point of view both will do the job, and are pretty much 
equivalent. Conversion to either should be relatively trivial via "cvs2git" 
(4), both support the fast-export file-format generated by the converter.

Non-technical arguments for either are

*	fossil is small, clean, simple, easy to learn, with the developer part
	of the Tcl community, and known to be responsive. Pretty much on call.

*	git, while not small, and with a steep learning curve, however is
	*ubiquitous*, with a much larger community. Students learn it.
	Using it means that a GSoC student (for example), can simply be
	pointed to the git repository and told to branch.

*	On the hosting front, using git give us lots of alternatives as:

		SourceForge, github, gitorious(sp?), assembla

*	For fossil we either have to either use the pretty much unknown

		chiselapp

	or self-host. The latter might actually not be to onerous, given that
	fossil comes with a builtin web server. Just needs a box.

*	Richard has its own comparison and reasons for either at
	http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki


Do I have my own preference ? Yes. And I sincerely hope that I managed to keep 
it out of the arguments above.


One last issue. As (1) shows, we have lots of subprojects. Seven. While these 
are all handled by a single CVS repository directory hierarchy, when going to 
DVCS we should really split them up, each as their own XXX repository. One of 
them, tclbench, should possibly even migrate out of the tcllib more to the core 
itself, given that it is the core whose performance this project is testing.

Discussion is open.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) Which are
	bwidget
	mclistbox
	tclapps
	tclbench
	tcllib	(sic)
	tklib
	widget

(2)	http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
(3)	http://www.kernel.org/pub/software/scm/git/docs/git.html

(4)	In contrast to Tcl/Tk core tcllib does not have vendor branches in the
	history AFAIK.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

[Tcllib-devel] Tcllib 1.13 has been released.

[Andreas K. <aku...@sh...>]

To be found under

	https://sourceforge.net/projects/tcllib/files/tcllib/1.13/

Overview
========

    44  new packages                in 10  modules
    29  changed packages            in 24  modules
    62  internally changed packages in 11  modules
    207 unchanged packages          in 79  modules
    348 packages, total             in 103 modules, total

New in tcllib 1.13
==================

    Module           Package                              New Version   
Comments
    ---------------- ------------------------------------ ------------- 
----------
    base64           ascii85                              1.0
    gpx              gpx                                  1
    ---------------- ------------------------------------ ------------- 
----------
    grammar_aycock   grammar::aycock                      1.0
                     grammar::aycock::debug               1.0
                     grammar::aycock::runtime             1.0
    ---------------- ------------------------------------ ------------- 
----------
    hook             hook                                 0.1
    imap4            imap4                                0.3
    ---------------- ------------------------------------ ------------- 
----------
    math             math::calculus::symdiff              1.0
                     math::numtheory                      1.0
    ---------------- ------------------------------------ ------------- 
----------
    namespacex       namespacex                           0.1
    pki              pki                                  0.1
    ---------------- ------------------------------------ ------------- 
----------
    pt               char                                 1
                     configuration                        1
                     paths                                1
                     pt::ast                              1.1
                     pt::cparam::configuration::critcl    1.0.1
                     pt::parse::peg                       1
                     pt::pe                               1
                     pt::pe::op                           1
                     pt::peg                              1
                     pt::peg::container                   1
                     pt::peg::container::peg              1
                     pt::peg::export                      1
                     pt::peg::export::container           1
                     pt::peg::export::json                1
                     pt::peg::export::peg                 1
                     pt::peg::from::json                  1
                     pt::peg::from::peg                   1
                     pt::peg::import                      1
                     pt::peg::import::json                1
                     pt::peg::interp                      1
                     pt::peg::op                          1
                     pt::peg::to::container               1
                     pt::peg::to::cparam                  1.0.1
                     pt::peg::to::json                    1
                     pt::peg::to::param                   1
                     pt::peg::to::peg                     1
                     pt::peg::to::tclparam                1
                     pt::pgen                             1
                     pt::rde                              1.0.1
                     pt::tclparam::configuration::snit    1.0.1
                     pt::tclparam::configuration::tcloo   1.0.1
                     text::write                          1
    ---------------- ------------------------------------ ------------- 
----------
    tepam            tepam                                0.2.0
    ---------------- ------------------------------------ ------------- 
----------

Changes from tcllib 1.12 to 1.13
================================

                                         tcllib 1.12   tcllib 1.13
    Module         Package               Old Version   New Version   Comments
    -------------- --------------------- ------------- ------------- ----------
    aes            aes                   1.0.1         1.0.2         B
    asn            asn                   0.8.3         0.8.4         B
    base64         base64                2.4.1         2.4.2         D B
    cmdline        cmdline               1.3.1         1.3.2         D B
    comm           comm                  4.6.1         4.6.2         B
    csv            csv                   0.7.1         0.7.2         D B
    dns            ip                    1.1.3         1.2           EF
    docstrip       docstrip::util        1.2           1.3           D EF B
    -------------- --------------------- ------------- ------------- ----------
    doctools       doctools              1.4.3         1.4.11        EF B
                   doctools::idx         1.0.3         1.0.4         B
                   doctools::idx         2             2             B
                   doctools::toc         1.1.2         1.1.3         B
                   doctools::toc         2             2             B
    -------------- --------------------- ------------- ------------- ----------
    doctools2idx   doctools::idx         1.0.3         1.0.4         B
                   doctools::idx         2             2             B
    -------------- --------------------- ------------- ------------- ----------
    doctools2toc   doctools::toc         1.1.2         1.1.3         B
                   doctools::toc         2             2             B
    -------------- --------------------- ------------- ------------- ----------
    fileutil       fileutil              1.14.2        1.14.4        B EF
    ftpd           ftpd                  1.2.4         1.2.5         B
    json           json                  1.0.1         1.1.1         I B
    map            map::slippy           0.2           0.3           B
    -------------- --------------------- ------------- ------------- ----------
    math           math::fuzzy           0.2           0.2.1         B
                   math::geometry        1.0.4         1.1.2         EF B D
                   math::linearalgebra   1.1.3         1.1.4         B
                   math::statistics      0.6.3         0.7.0         EF T
    -------------- --------------------- ------------- ------------- ----------
    pop3           pop3                  1.7           1.8           EF
    sha1           sha256                1.0.2         1.0.3         B
    -------------- --------------------- ------------- ------------- ----------
    snit           snit                  1.4.1         1.4.2         D B
                   snit                  2.3.1         2.3.2         D B
    -------------- --------------------- ------------- ------------- ----------
    struct         struct::list          1.7           1.8           EF T D
                   struct::queue         1.4.1         1.4.2         I T
                   struct::stack         1.4           1.5.1         EF I
    -------------- --------------------- ------------- ------------- ----------
    tar            tar                   0.6           0.7           EF
    units          units                 2.1           2.1.1         B
    -------------- --------------------- ------------- ------------- ----------
    wip            wip                   1.1.2         1.2           EF
                   wip                   2.1.2         2.2           EF
    -------------- --------------------- ------------- ------------- ----------
    yaml           huddle                0.1.4         0.1.5         B
    -------------- --------------------- ------------- ------------- ----------

Invisible changes (documentation, testsuites)
=============================================

                                                            tcllib 1.12   
tcllib 1.13
    Module                  Package                         Old Version   New 
Version   Comments
    ----------------------- ------------------------------- ------------- 
------------- ----------
    coroutine               coroutine                       1             1    
         D
                            coroutine::auto                 1             1    
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    doctools2base           doctools::msgcat                0.1           0.1  
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    doctools2idx            doctools::idx::export           0.1           0.1  
         D
                            doctools::idx::export::docidx   0.1           0.1  
         D
                            doctools::idx::export::html     0.2           0.2  
         D
                            doctools::idx::export::json     0.1           0.1  
         D
                            doctools::idx::export::nroff    0.3           0.3  
         D
                            doctools::idx::export::text     0.2           0.2  
         D
                            doctools::idx::export::wiki     0.2           0.2  
         D
                            doctools::idx::import           0.1           0.1  
         D
                            doctools::idx::import::docidx   0.1           0.1  
         D
                            doctools::idx::import::json     0.1           0.1  
         D
                            doctools::msgcat::idx::c        0.1           0.1  
         D
                            doctools::msgcat::idx::de       0.1           0.1  
         D
                            doctools::msgcat::idx::en       0.1           0.1  
         D
                            doctools::msgcat::idx::fr       0.1           0.1  
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    doctools2toc            doctools::msgcat::toc::c        0.1           0.1  
         D
                            doctools::msgcat::toc::de       0.1           0.1  
         D
                            doctools::msgcat::toc::en       0.1           0.1  
         D
                            doctools::msgcat::toc::fr       0.1           0.1  
         D
                            doctools::toc::export           0.1           0.1  
         D
                            doctools::toc::export::doctoc   0.1           0.1  
         D
                            doctools::toc::export::html     0.1           0.1  
         D
                            doctools::toc::export::json     0.1           0.1  
         D
                            doctools::toc::export::nroff    0.2           0.2  
         D
                            doctools::toc::export::text     0.1           0.1  
         D
                            doctools::toc::export::wiki     0.1           0.1  
         D
                            doctools::toc::import           0.1           0.1  
         D
                            doctools::toc::import::doctoc   0.1           0.1  
         D
                            doctools::toc::import::json     0.1           0.1  
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    http                    autoproxy                       1.5.1         
1.5.1         D
    mime                    smtp                            1.4.5         
1.4.5         D
    simulation              simulation::random              0.1           0.1  
         D
    struct                  struct::graph::op               0.11.3        
0.11.3        D T
    ----------------------- ------------------------------- ------------- 
------------- ----------
    virtchannel_base        tcl::chan::fifo                 1             1    
         D
                            tcl::chan::fifo2                1             1    
         D
                            tcl::chan::halfpipe             1             1    
         D
                            tcl::chan::memchan              1             1    
         D
                            tcl::chan::null                 1             1    
         D
                            tcl::chan::nullzero             1             1    
         D
                            tcl::chan::random               1             1    
         D
                            tcl::chan::string               1             1    
         D
                            tcl::chan::textwindow           1             1    
         D
                            tcl::chan::variable             1             1    
         D
                            tcl::chan::zero                 1             1    
         D
                            tcl::randomseed                 1             1    
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    virtchannel_core        tcl::chan::core                 1             1    
         D
                            tcl::chan::events               1             1    
         D
                            tcl::transform::core            1             1    
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------
    virtchannel_transform   tcl::transform::adler32         1             1    
         D
                            tcl::transform::base64          1             1    
         D
                            tcl::transform::counter         1             1    
         D
                            tcl::transform::crc32           1             1    
         D
                            tcl::transform::hex             1             1    
         D
                            tcl::transform::identity        1             1    
         D
                            tcl::transform::limitsize       1             1    
         D
                            tcl::transform::observe         1             1    
         D
                            tcl::transform::otp             1             1    
         D
                            tcl::transform::rot             1             1    
         D
                            tcl::transform::spacer          1             1    
         D
                            tcl::transform::zlib            1             1    
         D
    ----------------------- ------------------------------- ------------- 
------------- ----------

Unchanged
=========

    base32, base32::core, base32::hex, bee, bench, bench::in,
    bench::out::csv, bench::out::text, bibtex, blowfish,
    cache::async, calendar, cksum, control, counter, crc16, crc32,
    des, dns, docstrip, doctools::changelog, doctools::config,
    doctools::cvs, doctools::html, doctools::html::cssdefaults,
    doctools::idx::parse, doctools::idx::structure,
    doctools::nroff::man_macros, doctools::paths,
    doctools::tcl::parse, doctools::text, doctools::toc::parse,
    doctools::toc::structure, exif, fileutil::magic::cfront,
    fileutil::magic::cgen, fileutil::magic::filetype,
    fileutil::magic::mimetype, fileutil::magic::rt, fileutil::multi,
    fileutil::multi::op, fileutil::traverse, ftp, ftp::geturl,
    grammar::fa, grammar::fa::dacceptor, grammar::fa::dexec,
    grammar::fa::op, grammar::me::cpu, grammar::me::cpu::core,
    grammar::me::cpu::gasm, grammar::me::tcl, grammar::me::util,
    grammar::peg, grammar::peg::interp, html, htmlparse, ident,
    inifile, interp, interp::delegate::method,
    interp::delegate::proc, irc, javascript, jpeg, json::write,
    ldap, ldapx, log, logger, logger::appender, logger::utils,
    map::slippy::cache, map::slippy::fetcher, mapproj, math,
    math::bigfloat, math::bignum, math::calculus,
    math::complexnumbers, math::constants, math::fourier,
    math::interpolate, math::machineparameters, math::optimize,
    math::polynomials, math::rationalfunctions, math::roman,
    math::special, md4, md5, md5crypt, mime, multiplexer, nameserv,
    nameserv::auto, nameserv::common, nameserv::server, ncgi, nmea,
    nntp, otp, page::analysis::peg::emodes,
    page::analysis::peg::minimize, page::analysis::peg::reachable,
    page::analysis::peg::realizable, page::compiler::peg::mecpu,
    page::gen::peg::canon, page::gen::peg::cpkg, page::gen::peg::hb,
    page::gen::peg::me, page::gen::peg::mecpu, page::gen::peg::ser,
    page::gen::tree::text, page::parse::lemon, page::parse::peg,
    page::parse::peghb, page::parse::pegser, page::pluginmgr,
    page::util::flow, page::util::norm::lemon,
    page::util::norm::peg, page::util::peg, page::util::quote,
    picoirc, pluginmgr, png, pop3d, pop3d::dbox, pop3d::udb,
    profiler, rc4, rcs, report, resolv, rest, ripemd128, ripemd160,
    S3, SASL, SASL::NTLM, SASL::XGoogleToken, sha1,
    simulation::annealing, simulation::montecarlo, smtpd, soundex,
    spf, stooop, stringprep, stringprep::data, struct,
    struct::disjointset, struct::graph, struct::matrix,
    struct::pool, struct::prioqueue, struct::record, struct::set,
    struct::skiplist, struct::tree, sum, switched, tclDES, tclDESjr,
    term, term::interact::menu, term::interact::pager,
    term::receive, term::receive::bind, term::send, textutil,
    textutil::adjust, textutil::expander, textutil::repeat,
    textutil::split, textutil::string, textutil::tabify,
    textutil::trim, tie, tie::std::array, tie::std::dsource,
    tie::std::file, tie::std::growfile, tie::std::log,
    tie::std::rarray, tiff, time, transfer::connect, transfer::copy,
    transfer::copy::queue, transfer::data::destination,
    transfer::data::source, transfer::receiver,
    transfer::transmitter, treeql, uevent, uevent::onidle, unicode,
    unicode::data, uri, uri::urn, uuencode, uuid, xsxp, yaml,
    yencode

Legend  Change  Details Comments
        ------  ------- ---------
        Major   API:    ** incompatible ** API changes.

        Minor   EF :    Extended functionality, API.
                I  :    Major rewrite, but no API change

        Patch   B  :    Bug fixes.
                EX :    New examples.
                P  :    Performance enhancement.

        None    T  :    Testsuite changes.
                D  :    Documentation updates.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] Release 1.13 - RC1 is up.

[Andreas K. <aku...@sh...>]

I have put a release candidate, RC 1, for tcllib 1.13 up on SourceForge.
Please see
	https://sourceforge.net/projects/tcllib/files/tcllib/1.13%20RC1/

Anybody having the time please retrieve this RC and test. If no major 
obstacles occur I plan to officially release 1.13 the upcoming Sunday, January 
23, 2011.

Known issue: The test math-fuzzy-ManyCompares-1.1 fails. This is purely a 
testsuite issue, as far as I am aware.

I ran the full testsuite on a linux-glibc2.5-ix86 box against Tcl 8.4, 8.5, 
and 8.6 branch heads, all as of yesterday 11pm PST.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] Release...

[Andreas K. <aku...@sh...>]

Ok, new year, new release.

Well, while not right now, I do hope to be done with making it by end of 
January.

This is my announcement that a release phase has started, tests will be run, 
changes aggregated for the README, etc. pp.

If any of you have bugfixes waiting in the wings, now would be a good time to 
get them in.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] Wcb and Mentry into tklib - definitely yes from my side...

[Johann O. <joh...@go...>]

Hi all,

I'd also like to back up Jeff with his opinion.
I would like to see mentry/wcb in tklib.

In the past I always download the source packages from Caba's homepage, just to be sure to get the most recent one's.
As things get better and better I tend to update tklib from time to time - knowing to have a stable and solid rock code base.

By the way: thank you all for your efforts and contributions!

Cheers,
  Johann

The same situation would be true for wcb/mentry

On 29.11.2010, at 19:01, Jeff Hobbs wrote:

> On 28/11/2010 7:03 AM, Csaba Nemethi wrote:
>> Several people (most recently Stuart Cassoff) using my Wcb (Widget
>> callback) and Mentry (Multi-entry) packages suggested me to submit these
>> pure Tcl extensions for inclusion in tklib.  Before doing this, I would
>> like to ask you, the subscribers of this list, whether you share the
>> opinion that it would make sense to see Wcb and Mentry in tklib.
>> 
>> In case of a positive answer I would perform the (minor) necessary
>> changes and then send the resulting tarballs to Andreas Kupries (who has
>> already been asked by Stuart and liked his suggestion).
> 
> I'm of two minds about this.
> 
> On one hand, I think that these packages certainly provide value and it 
> would be better to have the greatest visibility for them.  If that's in 
> tklib, then so be it.
> 
> OTOH, I wish that tklib, like tcllib, were not considered the only 
> entity for distribution of packages.  It would be nice if these had a 
> successful life of their own.  However, I feel that part is a little 
> crippled in the ecosystem still, so placing it in tklib might be best.
> 
> Jeff
> 
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] Wcb and Mentry into tklib?

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

Csaba Nemethi wrote:
>
> Several people (most recently Stuart Cassoff) using my Wcb (Widget
> callback) and Mentry (Multi-entry) packages suggested me to submit these
> pure Tcl extensions for inclusion in tklib.  Before doing this, I would
> like to ask you, the subscribers of this list, whether you share the
> opinion that it would make sense to see Wcb and Mentry in tklib.


There are advantages and disadvantages to being part of tklib.

One advantage of keeping things separate is that you're not
tied to tklib's release schedule: if you add new features
or have critical bugfixes, you can push out a new release
on your own timeframe.

Of course, you could add Wcb and Mentry to tklib *in addition*
to distributing them separately (as it looks like you've been
doing with tablelist); that would give the advantages of both,
with the only drawback that it's more work for you...


--JE

Re: [Tcllib-devel] Wcb and Mentry into tklib?

[Jeff H. <je...@ac...>]

On 28/11/2010 7:03 AM, Csaba Nemethi wrote:
> Several people (most recently Stuart Cassoff) using my Wcb (Widget
> callback) and Mentry (Multi-entry) packages suggested me to submit these
> pure Tcl extensions for inclusion in tklib.  Before doing this, I would
> like to ask you, the subscribers of this list, whether you share the
> opinion that it would make sense to see Wcb and Mentry in tklib.
>
> In case of a positive answer I would perform the (minor) necessary
> changes and then send the resulting tarballs to Andreas Kupries (who has
> already been asked by Stuart and liked his suggestion).

I'm of two minds about this.

On one hand, I think that these packages certainly provide value and it 
would be better to have the greatest visibility for them.  If that's in 
tklib, then so be it.

OTOH, I wish that tklib, like tcllib, were not considered the only 
entity for distribution of packages.  It would be nice if these had a 
successful life of their own.  However, I feel that part is a little 
crippled in the ecosystem still, so placing it in tklib might be best.

Jeff