tcllib-devel — Discussion of development for tcllib

[Tcllib-devel] Support for pictures (screenshots) in man pages?

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

Hello,

I am thinking of writing a tutorial for Plotchart. Because
Plotchart is all about the graphical presentation of data,
I was wondering how I can include screenshots in that
document. I would use the doctools to mark up the text
of course, hence my question.

Regards,

Arjen

Re: [Tcllib-devel] YAML load/dump library

[KATO K. <k.k...@gm...>]

> Thanks for this library. It looks good for a first pass.
> You do have some very odd coding constructs that should be corrected before release.
Sorry, and Thanks.
This library is my first lump of program in Tcl.
So, there are many foolish logics in sourcecode, maybe. :(

> I think this is good for 0.1 commit, then fix after.
Supposing it is adopted, I will welcome.

> but it looks like a rough conversion from another language (Perl?),
That's right.
The original library written in PHP.
How to deal with container/structures differs considerably.




Some amount of correction was made according to indication.
http://knivez.homelinux.org/~spro/tcl/yapt-0.1.1.tar.gz

> * Use foreach instead of for constructs for lists
> * Brace all expressions
All "twirl-variables" on foreach-idiom to be braced.
But "for constructs for lists", I don't understand these concrete places.
Can I trouble you to show me there.

> * Some 'concat's look like string appending is meant
> * Use 'eq' instead of string equal in exprs
> * Use 'string match' instead of -length in some cases
corrected


> * Is 'isAliasNode' an incorrect conversion from Perl RE?
now, "Alias Node" is no implemented in the library.
So I comment outed the procedures.(and some not used)


> * Use 'string is bool' over lsearch of type - if valid.
It seems to be the treatment which is partly different.

Tcl:([string is true/false $token])
 1 == {1 true yes or on}
 0 == {0 false no off}
YAML:
 1 == {true on + yes y}
 0 == {false off - no n}

However, I am seldom scrupulous about this point... :)

Re: [Tcllib-devel] YAML load/dump library

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

KATO Kanryu wrote:
> I impremented a load/dump library for YAML.
> 
> There are functional limitations with this module.
> load:
>  - Node Anchors  &anchor *anchor
>  - multi line flow sequences/mappings
>  - Multi-line Flow Scalars
>  - Single/Double Quoted Scalars
> dump:
>  - multi rank structures(list/dict)
> 
> http://knivez.homelinux.org/~spro/tcl/yapt-0.1.tar.gz

Thanks for this library.  It looks good for a first pass.  You do have 
some very odd coding constructs that should be corrected before release. 
  I think this is good for 0.1 commit, then fix after.  No offense 
intended, but it looks like a rough conversion from another language 
(Perl?), that isn't taking advantage of some of Tcl's advanced features. 
  Some of the idiomatic changes needed:

* Use foreach instead of for constructs for lists
* Brace all expressions
* Some 'concat's look like string appending is meant
* Use 'eq' instead of string equal in exprs
* Use 'string match' instead of -length in some cases
* Is 'isAliasNode' an incorrect conversion from Perl RE?
* Use 'string is bool' over lsearch of type - if valid.

Regards,

Jeff

[Tcllib-devel] YAML load/dump library

[KATO K. <k.k...@gm...>]

I impremented a load/dump library for YAML.

There are functional limitations with this module.
load:
 - Node Anchors  &anchor *anchor
 - multi line flow sequences/mappings
 - Multi-line Flow Scalars
 - Single/Double Quoted Scalars
dump:
 - multi rank structures(list/dict)

http://knivez.homelinux.org/~spro/tcl/yapt-0.1.tar.gz

Comments?

[Tcllib-devel] YAML load/dump Library

[KATO K. <k.k...@gm...>]

I impremented a load/dump library for YAML.

There are functional limitations with this module.
load:
  - Node Anchors  &anchor *anchor
  - multi line flow sequences/mappings
  - Multi-line Flow Scalars
  - Single/Double Quoted Scalars
dump:
  - multi rank structures(list/dict)

http://knivez.homelinux.org/~spro/tcl/yapt-0.1.tar.gz

Comments?

[Tcllib-devel] Tcl/Tk accepted in Google Summer of Code 2008

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

To all.

The Tcl/Tk community application to be a mentor organization and
participate in the Google Summer of Code 2008 has been accepted.

The full list of organizations is available at:
	http://code.google.com/soc/2008/

and Tcl/Tk's info:
	http://code.google.com/soc/2008/tcl/about.html

Now we have to drum up students interested in the ideas.

Students may start applying for particular projects next Monday, March
24th, the details are written out in the first link.

If anybody has connections to universities or other compsci student
groups that might be interested, please point them in the direction of
our ideas list and encourage an application.

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

Re: [Tcllib-devel] tcllib test suite doing much better

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

>
> I just ran the latest tcllib cvs head with the latest tcl cvs head
> and I only see 3 errors. These are ones I've been seeing for a few
> weeks and I don't really understand. Anyone have any idea what might
> cause these three errors but no others?

stringprep ...

> ==== stringprep-2.3 stringprep: prohibited bidi FAILED
> ==== nameprep-5 Case folding U+2121 U+33C6 U+1D7BB FAILED
> ==== saslprep-1.7 Error - bidirectional check FAILED

These error signify known bugs in the stringprep packages, according to what
Pat Thoyts told me.
We should label them as such in the testsuite.

Side note: I have a bug on my plate that the critcl accelerators still
produce a large amount of testsuite errors, so I guess that you ran the
testsuite without to be nearly error-free.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

[Tcllib-devel] tcllib test suite doing much better

[Virden, L. W. <lv...@ca...>]

I just ran the latest tcllib cvs head with the latest tcl cvs head
and I only see 3 errors. These are ones I've been seeing for a few
weeks and I don't really understand. Anyone have any idea what might
cause these three errors but no others?

Platform: SPARC SunOS 2.9 with Sun C compiler.
both tcl and tcllib configured:
 ../configure  --prefix=/projects/sprs_lwv/tcl85 --enable-shared --enable-symbols --enable-stubs --enable-64bit

==== stringprep-2.3 stringprep: prohibited bidi FAILED
==== Contents of test case:

    catch {::stringprep::stringprep nameprep "\u0627\u0031"} result
    set result

---- Result was:
can't read "first_ral": no such variable
---- Result should have been (exact matching):
invalid_bidi
==== stringprep-2.3 FAILED

---- nameprep-5 start

==== nameprep-5 Case folding U+2121 U+33C6 U+1D7BB FAILED
==== Contents of test case:

        list [catch {::stringprep::stringprep nameprep  [encoding convertfrom ut
f-8 $input]} res] $res
    
---- Result was:
1 prohibited_character
---- Result should have been (exact matching):
0 telc?kg?
==== nameprep-5 FAILED

---- saslprep-1.7 start

==== saslprep-1.7 Error - bidirectional check FAILED
==== Contents of test case:

        list [catch {::stringprep::stringprep saslprep $input} res] $res
    
---- Result was:
1 {can't read "first_ral": no such variable}
---- Result should have been (exact matching):
1 invalid_bidi
==== saslprep-1.7 FAILED
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

[Tcllib-devel] tcllib test case failures?

[Virden, L. W. <lv...@ca...>]

Is anyone else seeing cvs head tcllib test case failures when run
against the current tcl 8.5 cvs head?

I'm on a sparc solaris 9 system, sun C compiler, and building everything with  
these options:

--prefix=/projects/sprs_lwv/tcl85 --enable-shared --enable-symbols --enable-stubs --enable-64bit 

I'm seeing 114 errors - most of which are from the tie module, but some
of which seem to be related to some unicode problems, and some other
miscellaneous problems.
I submitted bug reports on the problems.
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

[Tcllib-devel] anyone know of any tclchecker package checker generation programs?

[Virden, L. W. <lv...@ca...>]

the Tcl Dev Kit has a great program called tclchecker, which statically
looks for syntax problems, etc.

However, calls to many packages - such as those from tcllib - don't get
checked because the appropriate files haven't been provided.

Is anyone aware of any work being done to generate these "checker" files
so that tclchecker can do more with calls to struct, etc.?
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [Tcllib-devel] Proposing new module

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

Lars Hellström wrote:

>20 dec 2007 kl. 16.29 skrev Arjen Markus:
>
>  
>
>>Hi all,
>>
>>I have been thinking about adding a module to Tcllib with the 
>>preliminary
>>name "simulation" (or "modeling" or "computing" or "simulating" or ...)
>>The intent:
>>- Support for Monte Carlo simulations
>>- Discrete Event modelling
>>- Constraint Logic Programming
>>- etc.
>>
>>Any thoughts?
>>    
>>
>
>It seems like a somewhat disparate collection of computation models.
>
>Do you want to collect them because you think there would be a common 
>core that all of the above would simply be applications of? If so, what 
>would that consist of?
>  
>
Not so much a common core in the sense of code that can be shared, but
more a common set-up: each computational methodology would 
require/benefit from
a framework of sorts, rather than just a collection of useful procedures.

>  
>
>>A good idea or not? What is a good name for it?
>>    
>>
>
>It might be easier to find names for the parts than for this whole.
>  
>
Sure, though at least two people (among whom myself) think "simulation"
is a nice name.

Regards,

Arjen

Re: [Tcllib-devel] Proposing new module

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

20 dec 2007 kl. 16.29 skrev Arjen Markus:

> Hi all,
>
> I have been thinking about adding a module to Tcllib with the=20
> preliminary
> name "simulation" (or "modeling" or "computing" or "simulating" or =
...)
> The intent:
> - Support for Monte Carlo simulations
> - Discrete Event modelling
> - Constraint Logic Programming
> - etc.
>
> Any thoughts?

It seems like a somewhat disparate collection of computation models.

Do you want to collect them because you think there would be a common=20
core that all of the above would simply be applications of? If so, what=20=

would that consist of?

> A good idea or not? What is a good name for it?

It might be easier to find names for the parts than for this whole.

Lars Hellstr=F6m=

Re: [Tcllib-devel] Proposing new module

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

Cameron Laird wrote:

>On Thu, Dec 20, 2007 at 04:29:21PM +0100, Arjen Markus wrote:
>			.
>			.
>			.
>  
>
>>I have been thinking about adding a module to Tcllib with the preliminary
>>name "simulation" (or "modeling" or "computing" or "simulating" or ...)
>>The intent:
>>- Support for Monte Carlo simulations
>>- Discrete Event modelling
>>- Constraint Logic Programming
>>- etc.
>>
>>Any thoughts? A good idea or not? What is a good name for it?
>>    
>>
>			.
>			.
>			.
>Of these alternatives, "simulation" strikes me as the best choice.
>
>Yes, I'd certainly like for such a thing to become real.
>  
>
Good, I was inclined to "simulation" myself too. I have the humble 
beginnings
of a framework for Monte Carlo simulations now and I intend to add it to the
repository shortly, under this new module "simulation".

Regards,

Arjen

Re: [Tcllib-devel] Proposing new module

[Cameron L. <Ca...@ph...>]

On Thu, Dec 20, 2007 at 04:29:21PM +0100, Arjen Markus wrote:
			.
			.
			.
> I have been thinking about adding a module to Tcllib with the preliminary
> name "simulation" (or "modeling" or "computing" or "simulating" or ...)
> The intent:
> - Support for Monte Carlo simulations
> - Discrete Event modelling
> - Constraint Logic Programming
> - etc.
> 
> Any thoughts? A good idea or not? What is a good name for it?
			.
			.
			.
Of these alternatives, "simulation" strikes me as the best choice.

Yes, I'd certainly like for such a thing to become real.

[Tcllib-devel] Proposing new module

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

Hi all,

I have been thinking about adding a module to Tcllib with the preliminary
name "simulation" (or "modeling" or "computing" or "simulating" or ...)
The intent:
- Support for Monte Carlo simulations
- Discrete Event modelling
- Constraint Logic Programming
- etc.

Any thoughts? A good idea or not? What is a good name for it?

Regards,

Arjen

Re: [Tcllib-devel] Tcllib - Reopened discussion on whatpackagestoput into it.

[David W. <dav...@gm...>]

> > Once upon a time, being able to get packages one at a time was a win,
> > I think, and it still is.  However, I think these days the tolerance
> > for a relatively large standard library is higher than it once was,
> > and it would be a good thing to have a nativetcllib or ctcllib or
>
> Ah, are you now talking about packages in written in C here ?

If you're going to have something separate for C-dependent code,
perhaps going all out and letting in C based code would be nice too.

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Re: [Tcllib-devel] Tcllib - Reopened discussion on whatpackagestoput into it.

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

> Once upon a time, being able to get packages one at a time was a win,
> I think, and it still is.  However, I think these days the tolerance
> for a relatively large standard library is higher than it once was,
> and it would be a good thing to have a nativetcllib or ctcllib or

Ah, are you now talking about packages in written in C here ?

> whatever as a central place where QA'd, documented packages that can
> run cross platform (where applicable) can have a central place to
> live.  I wouldn't add anything too huge or obscure, but that's really
> a judgement call situation rather than something where you can make
> hard and fast rules.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packagestoput into it.

[David W. <dav...@gm...>]

Once upon a time, being able to get packages one at a time was a win,
I think, and it still is.  However, I think these days the tolerance
for a relatively large standard library is higher than it once was,
and it would be a good thing to have a nativetcllib or ctcllib or
whatever as a central place where QA'd, documented packages that can
run cross platform (where applicable) can have a central place to
live.  I wouldn't add anything too huge or obscure, but that's really
a judgement call situation rather than something where you can make
hard and fast rules.

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packagestoput into it.

[Virden, L. W. <lv...@ca...>]

=20

-----Original Message-----

[12:35]	<RockShox>	tcllib should be a small core of very general
utilities
with no dependencies
[12:35]	<RockShox>	i dont even like depending on other things in
tcllib


So RockShox's proposal is as soon as there is a dependence on something
other than tcl that a module should be removed from tcllib and
distributed separately?

Remember - from a central repository's point of view, there's little
benefit in the concept of tcllib. From the point of view of all the
people unable or unwilling to use the central repository, the tcllib
distribution and management mechanism is important.




[12:39]	kbk	Aaron - I don't mind tcllib modules depending on each
other;
they all come from the same place.
[12:39]	<RockShox>	well some people dont want to install the entire
thing

That's not a problem - they just install the pieces that depend on one
another. I mean, if they were writing the code all from scratch, they
would write most, if not all, the pieces (and maybe more).

[12:39]	patthoyts	its good to keep the dependencies to a minimum
though

Certainly I wouldn't advocate using a module for no good reason.
However, the essence of reuse is to not duplicate effort - keep things
in a way that you only have to debug once, change in one place, document
in one place, etc.  So one should avoid recoding rather than avoid
reuse... And "keep the dependencies to a minimum" sounds, to me, like
someone saying "avoid reuse".



[12:40]	<RockShox>	they want to grab a module that does what they
need
[12:40]	<RockShox>	and be done

But that isn't the way life works.  One doesn't just grab a DVD player
and be done - they also have to have DVDs. And if they are wanting to
record, then they have to grab the RIGHT dvd device AND the right format
blank DVD. If one is going to bake a cake, you not only need to grab a
recipe, but each of the ingredients, possibly some utensils, an oven,
etc.

To do a job requires a set of tools.  Grabbing tcllib grabs a set of
tools that oft times interact together to get the job done.  TEAPOT has
the capability of not only grabbing a particular package, but any
related packages, so that one can use things without worrying about
extra "runs to the store" to find the right pieces. And that's the best
way for a central repository to work - see if the user already has the
necessary dependant pieces and if not, to get the other things.

[12:40]	<RockShox>	in fact having a good repositor would probably
obviate
the need for tcllib entireley


Actually, only for those people who are able to access an internet and
who are merely looking for pieces. For developers, having a central
project like tcllib for managing the software, problem reports, etc. is
useful.


[12:44]	<RockShox>	response to my last comment?
[12:45]	dkf_	tcllib's not just distribution
[12:45]	dkf_	it's also a repository and bug tracking
[12:45]	aku	tcllib is mainly a distribution method, but not totally.
It
started out as a way to collect smaller stuff witohut having to set up
many websites.
[12:45]	dkf_	having to do loads of teeny weeny SF projects would suck


Yes. Another benefit is having a group of people who can, as needed,
share time in managing the code. Having one place where one is managing
things is far easier than having to manage code spread across a dozen
different web sites. And having tcllib as one download means that
someone who does want to use several pieces can hope that the pieces
that come "out of the box" have a bit of a chance of working together
(since the tcllib test suite is typically run at least once before a
release goes out the door).


[12:45]	<RockShox>	if you built a bigger better repository
[12:46]	aku	to amortize the overhead of that among them
[12:46]	<RockShox>	i hate to say it but other scripting languages
dont have
a standard library beyond what is distributed with the core


Which languages are you thinking about? Some of them - like Perl and
Python - have groups of code that they include in the core. Perl goes
farther and has CPAN, where there is not only modules, but meta
collections ... The equivalent of tcllib. I don't know enough about Ruby
to know what they are doing - whether they have matured to the point of
trying to provide community support to reuse.

--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages toput into it.

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

[12:33]	<RockShox>	aku: i withdraw my suggestion re tcllib
[12:33]	aku	Too much hassle ?
[12:33]	<RockShox>	i was thinking about it in the wrong manner
[12:34]	aku	?
[12:34]	<RockShox>	i was looking to tcllib for a distribution mechanism. but
i think it would be better to build a central repository to hold all
packages, than try and fit everything into one "library"
[12:34]	aku	Ah.
[12:35]	<RockShox>	tcllib should be a small core of very general utilities
with no dependencies
[12:35]	<RockShox>	i dont even like depending on other things in tcllib
[12:35]	<RockShox>	maybe we need a more clearly defined goal for tcllib
[12:35]	aku	I see. That I have no problem with. somewhere we have to start
standing on the shoulders of others.
[12:36]	aku	goal - if it had one I have forgotten
[12:36]	<RockShox>	more clearly defined than nothing
[12:37]	Gerry	If I have seen less far than others, it is because giants were
standing on my shoulders
[12:38]	aku	re withdrawal - Are you planning to send this info to
tcllib-devel as well ? If no, please reconsider, i.e. keep the others in the
loop too.
[12:39]	<RockShox>	well hey just because i withdraw my support doesnt mean
the discussion is over
[12:39]	<RockShox>	i cant just close it like that
[12:39]	kbk	Aaron - I don't mind tcllib modules depending on each other;
they all come from the same place.
[12:39]	<RockShox>	well some people dont want to install the entire thing
[12:39]	patthoyts	its good to keep the dependencies to a minimum though
[12:40]	<RockShox>	they want to grab a module that does what they need
[12:40]	<RockShox>	and be done
[12:40]	kbk	And I don't mind *conditional* dependency on things outside
tcllib - "if you have package foo, we'll use it; if not, we'll still try to
work without it"
[12:40]	patthoyts	basically the way its used is everyone plucks what they
need from it as individual modules.
[12:40]	<RockShox>	in fact having a good repositor would probably obviate
the need for tcllib entireley
[12:40]	<RockShox>	its basically just a distribution method
[12:40]	kbk	I *do* concede that cross-package dependencies mean that tcllib
could use better dependency management.
[12:41]	patthoyts	thats how it is now. ButI could see milage in having
support for say protocols requiring udp for instance
[12:44]	<RockShox>	response to my last comment?
[12:45]	dkf_	tcllib's not just distribution
[12:45]	dkf_	it's also a repository and bug tracking
[12:45]	aku	tcllib is mainly a distribution method, but not totally. It
started out as a way to collect smaller stuff witohut having to set up many
websites.
[12:45]	dkf_	having to do loads of teeny weeny SF projects would suck
[12:45]	<RockShox>	if you built a bigger better repository
[12:46]	aku	to amortize the overhead of that among them
[12:46]	<RockShox>	i hate to say it but other scripting languages dont have
a standard library beyond what is distributed with the core
[12:46]	aku	Now it is becoming big enough to be seen as becoming to large
...
[12:47]	dkf_	some things might have been better as separate CVS modules or
even separate projects
[12:47]	dkf_	most of those are yours, aku
[12:47]	aku	:P
[12:48]	kbk	Hmmm, I'd say that most Perl users don't distinguish between the
Perl core and CPAN.  But I don't know if CPAN would count as a "standard
library"
[12:48]	aku	Twas easier to plunk them into the Tcllib infrastructure ...
[12:48]	<RockShox>	maybe a subset should be picked for a standard batteries
included core distro (not AS) and the rest disbanded and put on some other
repository
[12:48]	suchenwi	Teapot.
[12:48]	dkf_	kbk: more of a central lending library?
[12:48]	<RockShox>	NOT teapot
[12:49]	suchenwi	Why NOT?
[12:50]	kbk	Lending library?  More like the mix of rubbish and treasures
stored helter-skelter in Aunt Millie's attic.
[12:50]	<RockShox>	its not open source and it depends on the AS build
processes and it only has what they want to put in it
[12:50]	<Damonc>	suchenwi:  it's proprietary.
[12:50]	suchenwi	Indeed.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122


> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Andreas
> Kupries
> Sent: Tuesday, November 13, 2007 11:36 AM
> To: Michael Schlenker; Donald G Porter
> Cc: Tcllib Devel
> Subject: Re: [Tcllib-devel] Tcllib - Reopened discussion on what
> packages toput into it.
>
>
>
> > > The question is a bit on the abstract side.  For sake of
> > > concreteness, what is the short list of packages currently
> > > being excluded from tcllib that would be allowed into tcllib
> > > with the policy change?
> > Most XML based stuff. (jabberlib, xmlrpc, and others).
>
> So dependency there is either TclXML/DOM/XSLT or tDOM ?
>
> Which of these have their own websites already, maybe even SF projects ?
>
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages to put into it.

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

Andreas Kupries wrote:
>>  To mitigate that, perhaps a refinement would be that
>> a package can go into tcllib only if all its dependencies are
>> distributed as part of ActiveTcl?

> I could live with that, however, could others accept this dependency on a
> distribution by a commercial entity, even if it is free like ActiveTcl ?

Ok, that's silly, but we can deal with silliness.

A package can go into tcllib if its dependencies include only packages
that are distributed with Tcl, packages that are distributed with
tcllib, or packages on this list {...}.

(Where coincidentally, the list is the remaining packages in ActiveTcl).

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

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages to put into it.

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

> > The question is a bit on the abstract side.  For sake of
> > concreteness, what is the short list of packages currently
> > being excluded from tcllib that would be allowed into tcllib
> > with the policy change?
> Most XML based stuff. (jabberlib, xmlrpc, and others).

So dependency there is either TclXML/DOM/XSLT or tDOM ?

Which of these have their own websites already, maybe even SF projects ?

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages toput into it.

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

> > Is it true that currently a package can go into tcllib only if all of
> its dependencies are either distributed with Tcl (msgcat, http,
> registry, etc.) or are also part of tcllib?
>
> > If that's not correct, what is a counter-example?

> >From a quick grep of tcllib/modules/*/*.tcl, I see approx. 128 unique
> package requires in tcllib. Many are for other tcllib modules, with some
> exceptions that I notice being Thread, Tk, Trf, Trfcrypt, some critcl
> stuff, tls, ceptcl. The Tk references are in snit's main1, 1_83, and
> 2.tcl files.
> The Trf/Trfcrypt references have, at least in the past,
> been conditional requires that use Tcl code if the Trf code isn't
> present, which I seem to recall is the case for the critcl stuff as
> well. The ceptcl code is in dns and ntp/time and is conditionally
> included.

Correct. All in a 'catch'.

> The tls references are in ldap, mime/smtp (conditionally included),
> sasl/gtoken, and smtpd (conditionally included).
>
> I'm not certain about the rest.

It looks to be as Don said, depends on Tcllib packages or packages coming
with the core, anything else is either caught/conditional, or in the
examples.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages to put into it.

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

> Andreas Kupries wrote:
> > Current state
> > 	Tcl-only packages which depen only on tcl, or other
> Tcl-only packages of
> > this type.
>
> Is it true that currently a package can go into tcllib only
> if all of its dependencies are either distributed with Tcl
> (msgcat, http, registry, etc.) or are also part of tcllib?

The way I phrased it it could depend on a Tcl-only package not in Tcllib.
However the way you explain it is most likely more true when I think about
it.

> If that's not correct, what is a counter-example?
>
> > Proposed by Aaron:
> > 	Relax the restrictions to allow dependency on non-optional
> C packages.
>
> The question is a bit on the abstract side.  For sake of
> concreteness, what is the short list of packages currently
> being excluded from tcllib that would be allowed into tcllib
> with the policy change?

Calling Rockshox, phone for you ...

He mentioned some on the chat however the names I remember, like 'TclSDL',
have already their own SF project (http://wiki.tcl.tk/14414,
http://simpledevlib.sourceforge.net).


> I think I like the idea.  Some folks seem concerned about
> shipping a distribution where some small fraction of the included
> packages won't work out of the box for some small fraction of
> downloaders.  To mitigate that, perhaps a refinement would be that
> a package can go into tcllib only if all its dependencies are
> distributed as part of ActiveTcl?

I could live with that, however, could others accept this dependency on a
distribution by a commercial entity, even if it is free like ActiveTcl ?
Remember, there are redistribution restrictions on it.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Tcllib - Reopened discussion on what packages to put into it.

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

Donald G Porter schrieb:
> Andreas Kupries wrote:
>> Current state
>> 	Tcl-only packages which depen only on tcl, or other Tcl-only packages of
>> this type.
> 
> Is it true that currently a package can go into tcllib only
> if all of its dependencies are either distributed with Tcl
> (msgcat, http, registry, etc.) or are also part of tcllib?
Its correct that all 'mandatory' dependencies must be in Tcllib or Tcl
itself. But its not fully true (e.g. the package term has a dependency
on stty on unix). If there is a tcl implementation soft dependencies on
accelerators are possible.

>> Proposed by Aaron:
>> 	Relax the restrictions to allow dependency on non-optional C packages.
> 
> The question is a bit on the abstract side.  For sake of
> concreteness, what is the short list of packages currently
> being excluded from tcllib that would be allowed into tcllib
> with the policy change?
Most XML based stuff. (jabberlib, xmlrpc, and others).

Michael