tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Hi Andreas,

thank you for the sftp hint.
Unfortunately, my permissions do not seam to be sufficient:

Andreas Kupries schrieb:
> https://sourceforge.net/project/admin/features.php?group_id=12883
> Project Web

I get a web page (while logged in in sourceforge) saying:

Permission Denied

Access to this page is restricted (either to project members or to
project administrators) and you do not meet the requirements to access
this page. Please contact the administrator of this project for further
assistance.

> 	https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web

I tried: sftp oehhar,tc...@we...

Login worked.

But when uploading files:

sftp> put index.html
Uploading index.html to /home/groups/t/tc/tcllib/bwidget/BWman/index.html
Couldn't get handle: Permission denied
sftp> ls -l index.html
-rw-r--r-- 0 techentin tcllib 230 Aug 3 1999 index.html
sftp> del index.html
Invalid command.
sftp> rm index.html
Removing /home/groups/t/tc/tcllib/bwidget/BWman/index.html
Couldn't delete file: Permission denied

Following the file permissions, only user techentin has write access on
the files and folders.
Group access is missing on the rights.

I suppose this might be a general hint to the tcllib project.
Nearly all files are not group writeable which is ok if there is one
maintainer.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

I would not not create the modified BWidget "2.0" until you actually 
have changes to implement.  Don't strip out ttk support and call that 
2.0, as that seems pointless.  If noone else steps up to support it that 
is OK, but only create a new version if you plan to push it forward.

We can live with BWidget 1.9 and TWidget 2.0.

My $.02,

Jeff

On 05/08/2009 11:55 PM, Harald Oehlmann wrote:
> Hello Community,
>
> thank you all for your contributions.
>
> To resume:
>
> TWidget:
> - Packet name: TWidget
> - cvs: head of module BWidget of tcl-lib
> - first release version: 2.0
> - tcl/tk 8.5 or newer
> - supports ttk as much as possible
>
> BWidget
> - Package name: BWidget
> - cvs: branch "BWidget" of module BWidget of tcl-lib
> - next release version: 2.0
> - tcl/tk 8.2 or newer
> - no ttk support at all, will be removed
>
> The packages will use:
> if {![package vsatisfies [package provide Tcl] 8.5]} {return}
> to avoid loading in a non-suitable interpreter
>
> Why two package names:
> - to allow current BWidget to continue evolving and to allow a release
> of 2.0
> - Why version numbers 2.0 for both packages ?
> To terminate the common 1.x period, where both packages were still unified.
> - I do not think BWidget is dead when TWidget is out.
>
> Further actions:
> - create the item TWidget for the tracker (bugs/patch/feature request)
>    (have already read about, will find it I think)
> - create a file release area (no problem)
>
> Actions I do not know how to do (please help):
>
> - Update web page: http://tcllib.sourceforge.net/
>    - Currently, the BWidget docs are old and I would like to update them
>    - add TWidget and TWidget documentation
>    * should I perform this task or is there someone else for this task ?
>
> Thank you all,
> Harald

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

Harald Oehlmann wrote:

> Actions I do not know how to do (please help):
> 
> - Update web page: http://tcllib.sourceforge.net/
>   - Currently, the BWidget docs are old and I would like to update them
>   - add TWidget and TWidget documentation

https://sourceforge.net/project/admin/features.php?group_id=12883
Project Web
==>
	https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web

This has an example on how to upload files to a project's web area using sftp.
Similarly it should be possible to list the existing files.

>   * should I perform this task or is there someone else for this task ?

Andreas.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Hello Community,

thank you all for your contributions.

To resume:

TWidget:
- Packet name: TWidget
- cvs: head of module BWidget of tcl-lib
- first release version: 2.0
- tcl/tk 8.5 or newer
- supports ttk as much as possible

BWidget
- Package name: BWidget
- cvs: branch "BWidget" of module BWidget of tcl-lib
- next release version: 2.0
- tcl/tk 8.2 or newer
- no ttk support at all, will be removed

The packages will use:
if {![package vsatisfies [package provide Tcl] 8.5]} {return}
to avoid loading in a non-suitable interpreter

Why two package names:
- to allow current BWidget to continue evolving and to allow a release
of 2.0
- Why version numbers 2.0 for both packages ?
To terminate the common 1.x period, where both packages were still unified.
- I do not think BWidget is dead when TWidget is out.

Further actions:
- create the item TWidget for the tracker (bugs/patch/feature request)
  (have already read about, will find it I think)
- create a file release area (no problem)

Actions I do not know how to do (please help):

- Update web page: http://tcllib.sourceforge.net/
  - Currently, the BWidget docs are old and I would like to update them
  - add TWidget and TWidget documentation
  * should I perform this task or is there someone else for this task ?

Thank you all,
Harald

Re: [Tcllib-devel] Graphops - Documentation

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

Michał Antoniewski wrote:
> Hello.
>  
> Next version of documentation is availiable.

Looks ok, modulo the structuring I talked about in the review for rev 42.
(This is the review for rev 43).

> I couldn't find a wiki link to K-Center problem (there was only 
> http://en.wikipedia.org/wiki/1-center_problem), so I used another 
> reference http://www.csc.kth.se/~viggo/wwwcompendium/node128.html, is 
> that ok or rather only wiki references?

That is ok.

> The same is with min diameter spanning tree problem.

Andreas.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

Donald G Porter wrote:
> Jeff Hobbs wrote:
>>> Concerning compatibility: I agree it is hard to keep compatible with old 
>>> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I 
>>> don't realize anymore they only exist since Tcl 8.5. I really think we 
>>> should move forward - after all bug fixing on Tk 8.4 has also stopped. 
>>> People who keep using 8.4, can also keep using BWidget 1.9.
> 
> If you drop support for an older Tcl or Tk, be sure to use filtering
> in the index script so that if your new BWidget release gets installed
> within reach of one of those older Tcl or Tk libraries, they continue
> to get the older BWidget version they can use, and not the new one that
> will fail.

Don is talking about code like

	andreask@gila:~/lsf/tcllib/modules> cat amazon-s3/pkgIndex.tcl
	# pkgIndex.tcl --
	# Copyright (c) 2006 Darren New
	# This is for the Amazon S3 web service packages.

	if {![package vsatisfies [package provide Tcl] 8.5]} {return}

	package ifneeded xsxp 1.0 [list source [file join $dir xsxp.tcl]]
	package ifneeded S3 1.0.0 [list source [file join $dir S3.tcl]]

I.e. code which prevents the registration of the package if the Tcl core 
running the script is not up to snuff to support the package.

That way an older Tcl will not even see the newer package, and keep using the 
older one. Assuming that both are installed.


Andreas

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

Jeff Hobbs wrote:
>> Concerning compatibility: I agree it is hard to keep compatible with old 
>> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I 
>> don't realize anymore they only exist since Tcl 8.5. I really think we 
>> should move forward - after all bug fixing on Tk 8.4 has also stopped. 
>> People who keep using 8.4, can also keep using BWidget 1.9.

If you drop support for an older Tcl or Tk, be sure to use filtering
in the index script so that if your new BWidget release gets installed
within reach of one of those older Tcl or Tk libraries, they continue
to get the older BWidget version they can use, and not the new one that
will fail.

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

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

On 04/08/2009 11:31 PM, Harald Oehlmann wrote:
>> Note that if you do that, rename all the lower level APIs (_after_
>> branching) so that TWidget and BWidget can both be used in the same app.
>>  If that isn't necessary, then call it BWidget 2.0 and just force the
>> issue.
> 
> I would like to rename the package. I did not plan to enable the
> possibility to load BWidget and TWidget simultaneously, so no renaming
> of for example namespace "Widget".
> 
> The name difference is to allow that both packages exist simultaneously.

If you don't expect them to both be loaded simultaneously, then BWidget 
1.9 and 2.0 are just fine.  Especially if you don't rename the 
underlying namespaces.  Both of those can be on the system, since Tcl 
supports that perfectly fine, it will just be a matter of the end user 
saying:

package require BWidget 1|2

Now of course without the version number, it will find 2, but if that is 
actually widget-name-and-function compatible (theming issues aside), 
then that isn't an issue anyways.

Jeff

Re: [Tcllib-devel] Review rev 41 - Re: Graphops - Documentation

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

Michał Antoniewski wrote:
> Oh, forgot to note that there is new folder Documentation where you can 
> find graphops.man and html file created with dtp.

Any particular reason not modifying

	modules/struct/graphops.man

directly ?

Andreas.

Re: [Tcllib-devel] Review rev 41 - Re: Graphops - Documentation

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

Michał Antoniewski wrote:
> Hello.
>  
> First part of documentation availiable on SVN. Please review it and let 
> me know, what you think about it.
>  
> Is that Input/Output division allright visually? And generally does it 
> look ok?

The general idea of structuring the documentation of a command in this manner 
is good. The execution needs however some changes as it doesn't make use of the 
doctools markup commands we have available for this.

See my review (rev 41) below where I give examples.

Further, some links

http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_intro.html
doctools introduction

http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_cmdref.html
Markup command reference

http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_syntax.html
Syntax reference


 >   53:	
 >   54:	[call [cmd struct::graph:op::toAdjacencyList] [arg G] [opt [arg 
options]...]]
 >   55:	
 >   56:	Procedure creates for input graph [arg G], it's representation as 
[term "Adjacency List"].
 >   57:	
 >   58:	[para]
 >   59:	
 >   60:	[const Input:]
 >   61:	[arg G] - input graph.
 >   62:	[arg options] - possible options are: directed (for directed graphs - 
undirected is default).
 >   63:	and weights ( including weights at edges in Adjacency List).

Ok, here is the above using the structuring facilities we havein doctools markup.

As the [const] command is for the markup of contant strings in the API its use 
to highlight and structure the documentation is ... ill-advised.

I am now using a definition-list to generate the overall structure (Arguments, 
Options), and then the list types for arguments and options to structure them 
further.

The comments at the end of the lists are just my personal way of keeping track 
of deeply nested list structures.


	[list_begin definitions]

	[item Arguments]
	[list_begin arguments]
	[arg_def {graph object} G input]

	The graph to convert into an [term "Adjacency List"].

	[list_end][comment {-- arguments --}]

	[item Options]
	[list_begin options]
	[opt_def -directed]

	By default [arg G] is operated as if it were an [term {Undirected graph}].
	Using this option tells the command to handle [arg G] as the directed graph it is.

	[opt_def -weights]

	By default any weight information the graph [arg G] may have is ignored.
	Using this option tells the command to put weight information into the result.
	In that case it is expected that all arcs have a proper weight, and an error
	is thrown if that is not the case.

	[list_end][comment {-- options --}]
	[list_end][comment {-- definitions --}]

Note how I use '-directed' and '-weights', i.e. the actual exact names of the 
options in question, including the '-' prefix. Using inaccurate names is bad 
when it comes to documentation. Its purpose is to inform actual and potential 
users, not to misdirect them.

Note also my addition of error conditions (... proper weight ...), i.e. what 
checks are performed on the input by the command.





 >  301:	
 >  302:	[call [cmd struct::graph::op::BellmanFord] [arg G] [arg startnode]]
 >  303:	
 >  304:	Searching for shortests paths between chosen node and all other nodes 
in graph [arg G]. Based
 >  305:	on relaxation method. In comparison to [cmd 
struct::graph::op::dijkstra] it doesn't need assumption that all weights
 >  306:	on edges in input graph [arg G] have to be positive.
 >  307:	
 >  308:	[para]
 >  309:	
 >  310:	That generality sets the complexity of algorithm to - [term O(V*E)], 
where [term V] is the amount of vertices
 >  311:	and [term E] is amount of edges in graph [arg G].

amount -> number

 >  312:	
 >  313:	[para]
 >  314:	
 >  315:	[const Input:]
 >  316:	
 >  317:	[para]
 >  318:	[const G] - Directed, connected and edge weighted graph [arg G], 
without any negative cycles ( presence of cycles with the negative sum
 >  319:	of weight means that there is no shortest path, since the total weight 
becomes lower each time the cycle is
 >  320:	traversed ). Negative weights on edges are allowed.
 >  321:	
 >  322:	[para]
 >  323:	
 >  324:	[const Output:]
 >  325:	
 >  326:	[para]
 >  327:	Dictionary containing for each node (key) distances to each other node 
in graph [arg G].

Using the basic template I demoed for line 63 and before ... In the Tcl style 
guide for C code output of a function is described as 'Result', and I believe 
that is a good name to use here as well.

	[list_begin definitions]

	[item Arguments]
	[list_begin arguments]
	...
	[list_end][comment {-- arguments --}]

**	[item Result]
**
**	A dictionary containing the distances from the [arg startnode] to all other 
nodes in the graph [arg G]. The node names are used as dictionary keys.
**
	[list_end][comment {-- definitions --}]


 >  329:	[para]
 >  330:	[emph Note:] If algorithm finds a negative cycle, it will return error 
message.

Good.

I won't copy the template to all the other commands now, I believe showing it 
twice (with different parts) is good enough for that.



 >  334:	[call [cmd struct::graph::op::Johnsons] [arg G] [opt [arg options]...]]
 >  335:	
 >  336:	Searching paths between all pairs of vertices in graph. For sparse graphs
 >  337:	asymptotically quicker than [cmd struct::graph::op::FloydWarshall] 
algorithm. Johnson's algorithm
 >  338:	uses [cmd struct::graph::op::BellmanFord] and [cmd 
struct::graph::op::dijkstra] as subprocedures.
 >  339:	[nl]

[nl] is depcrecated, we should always use [para].


 >  417:	
 >  418:	[emph Note:] It's 2-approximation algorithm.


We should maybe make a note in general what it means to be an N-approximation 
algorithm.


 >  453:	[call [cmd struct::graph::op::MaxCut] [arg G] [arg U] [arg V]]
 >  454:	
 >  455:	[term "Maximum cut problem"] is a problem finding a cut not smaller 
than any other cut. In
 >  456:	other words, we divide set of nodes for graph [arg G] into such 2 sets 
of nodes [term U] and [term V],
 >  457:	that the amount of edges connecting [term U] and [term V] is as high 
as possible.
 >  458:	
 >  459:	Algorithm is a 2-approximation, so for [term ALG] (solution returned 
by algorithm) and
 >  460:	[term OPT] (optimal solution), such inequality is true: [emph "OPT <= 
2 * ALG"].

Ah, and here we have such a remark ... We should possibly move this into a 
separate graph theory / term section at the end and make a reference to it here ...

	Algorithm is a [sectref {Background theory and terms} 2-approximation].
	                        ~ name of the section we ref  ~~ label used in the 
sentence.

 >  461:	
 >  462:	[para]
 >  463:	[const Input:]

 >  464:	[list_begin enum]
 >  465:	[enum] Graph [arg G].
 >  466:	[enum] [arg U] - variable storing first set of nodes (cut) given by 
solution.
 >  467:	[enum] [arg V] - variable storing second set of nodes (cut) given by 
solution.

See my template, 'argument' list.

 >  475:	[call [cmd struct::graph::op::UnweightedKCenter] [arg G] [arg k]]



 >  477:	[emph Definition:]
 >  478:	For any set [term S] ( which is subset of [term V] ) and node [term 
v], let the [term connect(v,S)] be the
 >  479:	cost of cheapest edge connecting [term v] with any node in [term S]. 
The goal is to find
 >  480:	such [term S], that [term "|S| = k"] and [term "max_v{connect(v,S)}"] 
is possibly small.

Structure with definition-list.




 >  544:	[call [cmd struct::graph::op::VerticesCover] [arg G]]
 >  545:	
 >  546:	[term "Vertices cover"] is a set o vertices such that each edge of the 
graph is incident to

typo ... of vertices ...




 >  556:	[call [cmd struct::graph::op::EdmondsKarp] [arg G] [arg s] [arg t]]
 >  557:	
 >  558:	The general idea of algorithm is finding the shortest augumenting 
paths in graph [arg G], as long
 >  559:	as they exist, and for each path updating the edge's weights along 
that path,
 >  560:	with maximum possible throughput. The final (maximum) flow is found
 >  561:	when there is no other augumenting path from source to sink.

This information about the implementation should be moved to the end of the 
block describing the command, as it is likely of less interest to users. At 
this point the important thing they wish to know is that it computes a max-flow.


 >  614:	
 >  615:	[call [cmd struct::graph::op::ShorestsPathsByBFS] [arg G] [arg s] [arg 
outputFormat]]

Typo ... Shorests -> Shortests?

 >  654:	[option outputFormat] - possible options are [option graph] and 
[option tree].

option -> arg. The [option graph] should is [const graph].


 >  883:	
 >  884:	[keywords graph dijkstra distance radius diameter eccentricity]
 >  885:	[keywords edge arc node vertex subgraph neighbour]
 >  886:	[keywords adjacent loop degree]
 >  887:	[keywords {cut vertex} {articulation point} {connected component}]
 >  888:	[keywords {strongly connected component} {adjacency matrix}]
 >  889:	[keywords {minimal spanning tree} bipartite bridge {cut edge} isthmus]

The above list of keywords and terms should be extended as well.


Andreas.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

I agree that perhaps 8.5 is now an acceptable base version.

On 05/08/2009 2:16 AM, Koen Danckaert wrote:
> Harald,
> 
> Another option is to simply add some files to the current BWidget 
> sources, to support ttk. For example, there is scrollframe.tcl, and you 
> could add a tscrollframe.tcl file which uses ttk widgets. This has the 
> advantage that tk bwidgets and ttk bwidgets can be used in the same 
> application, which would not be possible in your proposal. (And which is 
> not even possible in the current half-working approach, since there is a 
> single global BWidget::theme variable).
> 
> Of course, this is not possible if you want (or need) to rewrite the 
> complete framework (in widget.tcl). But in that case, maybe it would 
> even be better to start from scratch and make a new CWidget package... :-/
> 
> Concerning compatibility: I agree it is hard to keep compatible with old 
> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I 
> don't realize anymore they only exist since Tcl 8.5. I really think we 
> should move forward - after all bug fixing on Tk 8.4 has also stopped. 
> People who keep using 8.4, can also keep using BWidget 1.9.
> 
> Regards,
> Koen
> 
> 
> 
> Harald Oehlmann wrote:
>> Hi community,
>>
>> **I would apreciate, if a tcl-lib expert would answer the question at
>> the end of this e-mail**
>>
>> as announced in my email on this list:
>> Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget
>> Date: 2009-07-20
>>
>> it is planed to branch BWidget into two source trees:
>> - BWidget - use tk8.1 and later, no ttk code
>> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code
>>
>> Why two source trees ? It is a real split of scope.
>> BWidget is complicated enough. To support ttk and tk, many code will be
>> doubled. In addition, I don't want to drop tk8.1 compatibility, but many
>> things just would be more elegant and some work-arounds will go away.
>>
>> I am in doubt on the cvs level how to do this.
>>
>> Two alternatives:
>>
>> 1) use module bwidget and put TBWidget into a branch
>>
>> How to branch:
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
>> -r bwidget-1-9-0 tbwidget bwidget
>>
>> How to checkout:
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
>> checkout -r tbwidget -P bwidget
>>
>> Advantage: all history kept
>> Disadvantages:
>> - No head revision for tbwidget
>> - Have to specify -r tbwidget on all operations for tbwidget
>>
>> 2) Create a new module tbwidget
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import
>> tbwidget oehhar tbwidget
>>
>> Advantage: Own head revision for BWidget and TBWidget, much clearer
>> Disadvantage: file history lost for TBWidget
>>
>> 3) do something else ???
>> Other ideas ? Migrate to subversion where this is not an issue ;-)
>>
>> Properties of both solutions:
>> - No change for BWidget on the cvs level
>>
>> Thank you for any insights.
>>
>> Regards,
>> Harald

Re: [Tcllib-devel] Graphops - Documentation (fwd)

[Michał A. <ant...@gm...>]

Hello.

Next version of documentation is availiable.

I couldn't find a wiki link to K-Center problem (there was only
http://en.wikipedia.org/wiki/1-center_problem), so I used another reference
http://www.csc.kth.se/~viggo/wwwcompendium/node128.html, is that ok or
rather only wiki references?

The same is with min diameter spanning tree problem.



Best Regards,
Michał Antoniewski

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Koen,

Thank you contributing.

The one Widget::_theme variable may be replaced by widget names or other
mechanism, this is IMHO no issue. The issue is IMHO just the raising
complexity to support tk and ttk by one set of code.

Making a new CWidget (O-T-BWidget) packet is anyway a todo to support oo
and ttk. But this is not the aim at the moment.

Koen Danckaert schrieb:
> Another option is to simply add some files to the current BWidget
> sources, to support ttk. For example, there is scrollframe.tcl, and you
> could add a tscrollframe.tcl file which uses ttk widgets. This has the
> advantage that tk bwidgets and ttk bwidgets can be used in the same
> application, which would not be possible in your proposal. (And which is
> not even possible in the current half-working approach, since there is a
> single global BWidget::theme variable).
> 
> Of course, this is not possible if you want (or need) to rewrite the
> complete framework (in widget.tcl). But in that case, maybe it would
> even be better to start from scratch and make a new CWidget package... :-/

> Harald Oehlmann wrote:
>> it is planed to branch BWidget into two source trees:
>> - BWidget - use tk8.1 and later, no ttk code
>> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code
>>
>> Why two source trees ? It is a real split of scope.
>> BWidget is complicated enough. To support ttk and tk, many code will be
>> doubled. In addition, I don't want to drop tk8.1 compatibility, but many
>> things just would be more elegant and some work-arounds will go away.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Koen D. <ko...@re...>]

Harald,

Another option is to simply add some files to the current BWidget sources, to support ttk. For example, there is scrollframe.tcl, and you could add a tscrollframe.tcl file which uses ttk widgets. This has the advantage that tk bwidgets and ttk bwidgets can be used in the same application, which would not be possible in your proposal. (And which is not even possible in the current half-working approach, since there is a single global BWidget::theme variable).

Of course, this is not possible if you want (or need) to rewrite the complete framework (in widget.tcl). But in that case, maybe it would even be better to start from scratch and make a new CWidget package... :-/

Concerning compatibility: I agree it is hard to keep compatible with old Tk releases. I'm really used to operators such as {*}, eq, ne,... and I don't realize anymore they only exist since Tcl 8.5. I really think we should move forward - after all bug fixing on Tk 8.4 has also stopped. People who keep using 8.4, can also keep using BWidget 1.9.

Regards,
Koen



Harald Oehlmann wrote:
> Hi community,
> 
> **I would apreciate, if a tcl-lib expert would answer the question at
> the end of this e-mail**
> 
> as announced in my email on this list:
> Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget
> Date: 2009-07-20
> 
> it is planed to branch BWidget into two source trees:
> - BWidget - use tk8.1 and later, no ttk code
> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code
> 
> Why two source trees ? It is a real split of scope.
> BWidget is complicated enough. To support ttk and tk, many code will be
> doubled. In addition, I don't want to drop tk8.1 compatibility, but many
> things just would be more elegant and some work-arounds will go away.
> 
> I am in doubt on the cvs level how to do this.
> 
> Two alternatives:
> 
> 1) use module bwidget and put TBWidget into a branch
> 
> How to branch:
> 
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
> -r bwidget-1-9-0 tbwidget bwidget
> 
> How to checkout:
> 
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
> checkout -r tbwidget -P bwidget
> 
> Advantage: all history kept
> Disadvantages:
> - No head revision for tbwidget
> - Have to specify -r tbwidget on all operations for tbwidget
> 
> 2) Create a new module tbwidget
> 
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import
> tbwidget oehhar tbwidget
> 
> Advantage: Own head revision for BWidget and TBWidget, much clearer
> Disadvantage: file history lost for TBWidget
> 
> 3) do something else ???
> Other ideas ? Migrate to subversion where this is not an issue ;-)
> 
> Properties of both solutions:
> - No change for BWidget on the cvs level
> 
> Thank you for any insights.
> 
> Regards,
> Harald
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
> 
> 

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

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

On 03/08/2009 5:59 AM, Harald Oehlmann wrote:
> it is planed to branch BWidget into two source trees:
> - BWidget - use tk8.1 and later, no ttk code
> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code

FWIW, I would just call it TWidget.  Not sure about dropping 8.4+tile at 
this point - any reason not to still support that rather common combination?

> 1) use module bwidget and put TBWidget into a branch
> 
> How to branch:
> 
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
> -r bwidget-1-9-0 tbwidget bwidget
> 
> How to checkout:
> 
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
> checkout -r tbwidget -P bwidget
> 
> Advantage: all history kept
> Disadvantages:
> - No head revision for tbwidget
> - Have to specify -r tbwidget on all operations for tbwidget

I would instead recommend that TWidget become the head of the bwidget 
repository, with BWidget 1.9 becoming the 1-9-0 branch.  I don't see any 
major work will be done on that, so essentially what we are doing is 
creating BWidget 2.0, and just calling it TWidget to reduce confusion.

Note that if you do that, rename all the lower level APIs (_after_ 
branching) so that TWidget and BWidget can both be used in the same app. 
  If that isn't necessary, then call it BWidget 2.0 and just force the 
issue.

Jeff

Re: [Tcllib-devel] Review rev 41 - Re: Graphops - Documentation

[Michał A. <ant...@gm...>]

Oh, forgot to note that there is new folder Documentation where you can find
graphops.man and html file created with dtp.


Best Regards,
Michał Antoniewski

Re: [Tcllib-devel] Review rev 41 - Re: Graphops - Documentation

[Michał A. <ant...@gm...>]

Hello.

First part of documentation availiable on SVN. Please review it and let me
know, what you think about it.

Is that Input/Output division allright visually? And generally does it look
ok?




Best Regards,
Michał Antoniewski

[Tcllib-devel] Review rev 41 - Re: Graphops - Documentation

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

 > 1360:			if { ($paths == {}) || (![dict exists $paths $t]) } break

In case of '$paths == {}' being true the ![dict exists $paths $t] should be 
true as well. And conversely, if [dict exists $paths $t], then paths != {} too.

Meaning that the '![dict exists $paths $t]' condition should be all that is needed.


 > 1649:			if { ($paths == {}) || (![dict exists $paths $t]) } break

Ditto.

 > 2141:			if { $paths == {} } break
 > 2142:			if { ![dict exists $paths $t] } break

Ditto.


 > 2480:	proc ::struct::graph::op::findExcess {G node b} {
 > 2481:	
 > 2482:		set incoming 0
 > 2483:		set outcoming 0
 > 2484:		
 > 2485:		foreach key [dict keys $b] {
 > 2486:			
 > 2487:			lassign $key u v
 > 2488:			if { $u eq $node } {
 > 2489:				set outcoming [ expr { $outcoming + [dict get $b $key] } ]
 > 2490:			}
 > 2491:			if { $v eq $node } {
 > 2492:				set incoming [ expr { $incoming + [dict get $b $key] } ]
 > 2493:			}		
 > 2494:		}

Just noted
	http://docs.activestate.com/activetcl/8.5/tcl/TclCmd/dict.htm#M16

dict keys allows a glob pattern to select specific keys. Using that ability a 
slightly different set of loops is possible. Two loops, and the conditional is 
hidden in the 'dict keys' commands, and done at C-level.

		foreach key [dict keys $b [list $node *]] {
			set outcoming [ expr { $outcoming + [dict get $b $key] } ]
		}

		foreach key [dict keys $b [list * $node]] {
			set incoming [ expr { $incoming + [dict get $b $key] } ]
		}

My apologies, I did not notice that before. We might have other loops which can 
benefit from this.

 > 2498:	
 > 2499:	#Travelling Salesman Problem - Heuristic of local searching
 > 2500:	#2 - approximation Algorithm
 > 2501: 
#-------------------------------------------------------------------------------------
 > 2502:	#
 > 2503:	
 > 2504:	proc ::struct::graph::op::TSPLocalSearching {G C} {
 > 2505:		
 > 2506:		foreach arc $C {
 > 2507:			if { ![$G arc exists $arc] } {
 > 2508:				return -code error "Given cycle has arcs not included in graph G."
 > 2509:			}
 > 2510:		}


C = cycle in G ? Should possibly also check that adjacent arcs share a node, 
and the destination node of the last arc matches the sourcen ode of the first 
(== ensure that it is a cycle). Is it also required to be a cycle through all 
nodes ?

G is complete graph I guess?

 > 2567:						#we consider only arcs that are not adjacent
 > 2568:						if { !($iu eq $ju) && !($iu eq $jv) && !($iv eq $ju) && !($iv eq 
$jv) } {

	!($x eq $y) <==> ($x ne $y)


 > 2569:					
 > 2570:							#set the current cycle
 > 2571:							set CPrim [copyGraph $CGraph]
 > 2572:						
 > 2573:							#transform the current cycle:
 > 2574:							#1.
 > 2575:							$CPrim arc delete $i
 > 2576:							$CPrim arc delete $j
 > 2577:						
 > 2578:						
 > 2579:							set param 0

	param means 'no new edges' ?

 > 2601:						
 > 2602:							$CPrim arc setunweighted 1
 > 2603:						
 > 2604:							#check if it's still a cycle or if any arcs were added instead 
those erased
 > 2605:							if { !([struct::graph::op::distance $CPrim $iu $ju] > 0 ) || 
$param } {

Move param check to front, allow skipping of expensive 'distance' op.

 > 2606:						
 > 2607:								#deleting new edges if they were added before in current iteration
 > 2608:								if { !$param } {
 > 2609:									$CPrim arc delete [list $iu $ju]
 > 2610:								}						
 > 2611:							
 > 2612:								if { !$param } {
 > 2613:									$CPrim arc delete [list $iv $jv]
 > 2614:								}

These two blocks can be merged into one I would say, based on the fact that 
they have the same condition. Or should they have different conditions ?


 > 2632:						
 > 2633:							#count current value of cycle
 > 2634:							set cycleWeight [countCycleWeight $CPrim]


This we might be able to perform incrementally in the future, by keeping track 
of the erase/add operations and the changes they cause to the total weight.

 > 2676:	proc ::struct::graph::op::copyGraph {G} {

This procedure might be applicable to other algorithms. I haven't
checked backed however. There were so many graph copy ops I lost track
of which had been identical, all the slight differences.


Andreas.

Re: [Tcllib-devel] Graphops - Documentation (fwd)

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

Michał Antoniewski wrote:
> I've got one more question about documentation.
>  
> As during implementation, there were created some subprocedures (for 
> main algorithms) that can be found useful as individual graph 
> operations, I would like to verify which of them should be put in 
> documentation :
>  
> a) Algorithms:
> - Greedy Max Matching - subprocedure for Christofides but 
> still individual algorithm, so I think can be included.
> - Greedy Max Independent Set (Weighted also) - the same as above.
> - BFS and BFS pathfinding - I think both BFS procedures will be useful 
> addition.

Yes to all.

>  
> b) some other graph operations:
> - create squared graph - possibly useful graph operation.
> - create Complete Graph - for input graph G, adds missing edges and 
> returns complete graph. 
> - copy Graph - subprocedure for copying graphs as there are a lot of 
> such uses in implementation. Possibly useful operation for users too.
> Generally subprocedures under "b)" are less likely to add in graphops 
> than "a)" and "c)", but I'm asking to make sure.

Yes to all. Copying graph definitely occurs often, and all not quite able to 
use the (de)serialize methods because of changes to attributes, and/or arc 
names, and the like.

> c) Subprocedures considering flow problems. Also useful as individual 
> procedures:
> - create Residual Graph
> - create Augmenting Network
> - create Level Graph

Yes.

Andreas.

Re: [Tcllib-devel] Graphops - Documentation (fwd)

[Michał A. <ant...@gm...>]

I've got one more question about documentation.

As during implementation, there were created some subprocedures (for main
algorithms) that can be found useful as individual graph operations, I would
like to verify which of them should be put in documentation :

a) Algorithms:
- Greedy Max Matching - subprocedure for Christofides but still individual
algorithm, so I think can be included.
- Greedy Max Independent Set (Weighted also) - the same as above. - BFS and
BFS pathfinding - I think both BFS procedures will be useful addition.

b) some other graph operations:
- create squared graph - possibly useful graph operation.
- create Complete Graph - for input graph G, adds missing edges and returns
complete graph.
 - copy Graph - subprocedure for copying graphs as there are a lot of such
uses in implementation. Possibly useful operation for users too.
Generally subprocedures under "b)" are less likely to add in graphops than
"a)" and "c)", but I'm asking to make sure.

c) Subprocedures considering flow problems. Also useful as individual
procedures:
- create Residual Graph
- create Augmenting Network
- create Level Graph


Best Regards,
Michał Antoniewski

[Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Hi community,

**I would apreciate, if a tcl-lib expert would answer the question at
the end of this e-mail**

as announced in my email on this list:
Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget
Date: 2009-07-20

it is planed to branch BWidget into two source trees:
- BWidget - use tk8.1 and later, no ttk code
- TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code

Why two source trees ? It is a real split of scope.
BWidget is complicated enough. To support ttk and tk, many code will be
doubled. In addition, I don't want to drop tk8.1 compatibility, but many
things just would be more elegant and some work-arounds will go away.

I am in doubt on the cvs level how to do this.

Two alternatives:

1) use module bwidget and put TBWidget into a branch

How to branch:

cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
-r bwidget-1-9-0 tbwidget bwidget

How to checkout:

cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
checkout -r tbwidget -P bwidget

Advantage: all history kept
Disadvantages:
- No head revision for tbwidget
- Have to specify -r tbwidget on all operations for tbwidget

2) Create a new module tbwidget

cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import
tbwidget oehhar tbwidget

Advantage: Own head revision for BWidget and TBWidget, much clearer
Disadvantage: file history lost for TBWidget

3) do something else ???
Other ideas ? Migrate to subversion where this is not an issue ;-)

Properties of both solutions:
- No change for BWidget on the cvs level

Thank you for any insights.

Regards,
Harald

Re: [Tcllib-devel] Graphops - Documentation (fwd)

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

> Hello.
 
> All local searching is done - just got one problem how to arrange
> one step of algorithm. If it takes too much time, I will describe it
> to you, maybe you will come up with some better solution.

I'll have a look.

> I have started with documentation work. So, some questions about it:

> - as it was described in developer file, I'm going to edit 'man'
>   file, from which is created html file during installation. Is
>   there anything else to do?

No, not really.

> - should there be any documentation file summarizing whole project?

What do you envision as its content ?

> - the documentation for graphops contains short descriptions on what
>   procedure does and how to use it. How about info concerning
>   complexities and generally some graph theory info about particular
>   algorithm? Or we assume that user knows, what he is looking for
>   when he wants to use e.g.  Christofides Algorithm?

The basic descriptions are a must. Having complexities would be good
as well. For theory we should have at least references to wikipedia or
other websites. If we have enough time left we can certainly add more.

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

[Tcllib-devel] Graphops - Documentation

[Michał A. <ant...@gm...>]

Hello.

All local searching is done - just got one problem how to arrange one step
of algorithm. If it takes too much time, I will describe it to you, maybe
you will come up with some better solution.

I have started with documentation work. So, some questions about it:
- as it was described in developer file, I'm going to edit 'man' file, from
which is created html file during installation. Is there anything else to
do?
- should there be any documentation file summarizing whole project?
- the documentation for graphops contains short descriptions on what
procedure does and how to use it. How about info concerning complexities and
generally some graph theory info about particular algorithm? Or we assume
that user knows, what he is looking for when he wants to use e.g.
Christofides Algorithm?


Best Regards,
Michał Antoniewski

[Tcllib-devel] graphops - Review rev 40

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

Not much to say

> 2062:	#Dinic algorithm for finding maximum flow in flow network
> 2063:	#-------------------------------------------------------------------------------------
> 2064:	#
> 2065:	#Reference: http://en.wikipedia.org/wiki/Dinic's_algorithm
> 2066:	#
> 2067:	proc ::struct::graph::op::MaximumFlowByDinic {G s t blockingFlowAlg} {
> 2068:		
> 2069:		if { !($blockingFlowAlg eq "dinic" || $blockingFlowAlg eq "mkm") } {
> 2070:			return -code error "Uncorrect name of blocking flow algorithm. Choose \"mkm\" for Malhotra, Kumar and Maheshwari algorithm and \"dinic\" for Dinic algorithm."
> 2071:		}
> 2072:		
> 2073:		foreach arc [$G arcs] {
> 2074:			set u [$G arc source $arc]
> 2075:			set v [$G arc target $arc]
> 2076:			
> 2077:			dict set f [list $u $v] 0
> 2078:			dict set f [list $v $u] 0
> 2079:		}
> 2080:		
> 2081:		while {1} {
> 2082:			set residualG [createResidualGraph $G $f]

One new graph is currently created per loop, and never released. Memory leak.

> 2134:			set paths [ShortestsPathsByBFS $LevelGraph $s paths]
> 2135:		
> 2136:			if { $paths == 0 } break
> 2137:			if { ![dict exists $paths $t] } break



> 2346:		#deleting arcs with 0 throughputs for proper pathfinding
> 2347:		foreach arc [$Gf arcs] {
> 2348:			if { [$Gf arc get $arc throughput] == 0 } {
> 2349:				$Gf arc delete $arc
> 2350:			}
> 2351:		}

The loop can be written as

		$Gf arc delete {*}[$Gf arcs -key throughput -value 0]

Per http://docs.activestate.com/activetcl/8.5/tcllib/struct/graph.html#37 
(arcs)
and http://docs.activestate.com/activetcl/8.5/tcllib/struct/graph.html#13 (arc 
delete)

	-key key
	    Limit the list of arcs that are returned to those arcs
	    that have an associated key key.

	-value value
	    This restriction can only be used in combination with
	    -key. It limits the list of arcs that are returned to
	    those arcs whose associated key key has the value value.

The {*} syntax expands the result of the [...] to make each word a
separate argument in the command it was used in, here 'arc delete'.

This type of reduction may apply in other places as well, although
this is the first time I noticed it. We can fix this up when
integrating the project results into Tcllib proper.

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

[Tcllib-devel] Review rev 39

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

XOpsSetup

 > 1999: proc WrongAttributes {args} {
 > 2000:         set message "The input network doesn't have all attributes set 
correctly... Please, check again attributes: "
 > 2001:         foreach a $args {
 > 2002:                 if { !([lindex $args end] == $a) } {
 > 2003:                         set message "$message\"$a\" and "
 > 2004:                 } else {
 > 2005:                         set message "$message\"$a\""

This form should be written as

	append message "\"$a\""

See also line 2003.

 > 2006:                 }
 > 2007:         }

The whole loop can be written as

	append message\"[join $args "\" and \""]\"

Assuming that [llength $args] > 0, always. If not we just have to make this 
'append' command conditional.

	join {a b c} ,
=>	"a,b,c"

 > 2008:
 > 2009:         return "$message for input graph."
 > 2010: }
 > 2011: andreask@gila:~/workbench/gsoc>


graphops.tcl

 > 2070:	#Dinic algorithm for finding blocking flow
 > 2071: 
#-------------------------------------------------------------------------------------
 > 2072:	#
 > 2073:	#Algorithm for given network G with source s and sink t, finds a blocking
 > 2074:	#flow, which can be used to obtain a maximum flow for that network G.
 > 2075:	#
 > 2076:	#Some steps that algorithm takes:

 > 2077:	#1. constructing the level graph from network G
 > 2078:	#2. until there are edges in level graph:

I guess 'no edges', that would match code.

 > 2079:	#	3. find the path between s and t nodes in level graph
 > 2080:	#	4. for each edge in path update current throughputs at those edges 
and...
 > 2081:	#	5. ...deleting nodes from which there are no residual edges
 > 2082:	#6. return the dictionary containing the blocking flow
 > 2083:	
 > 2084:	proc ::struct::graph::op::BlockingFlowByDinic {G s t} {
 > 2085:		set iteration 1

 > 2094:		#1.
 > 2095:		set LevelGraph [createLevelGraph $G s]

Leak. The graph is not deleted when we are done.

 > 2096:		
 > 2097:		#2. the main loop
 > 2098:		while { [llength [$LevelGraph arcs]] > 0 } {
 > 2099:		
 > 2102:			#3.
 > 2103:			set paths [ShortestsPathsByBFS $LevelGraph $s paths]
 > 2104:		
 > 2105:			if { ![dict exists $paths $t] } break
 > 2106:			set path [dict get $paths $t]
 > 2107:			lappend path $t
 > 2108:		
 > 2109:			if { $path == 0 } break

This is never true, because of line 2107. If the check is about 'no
paths', that should have been handled by line 2105, so this condition
is possibly superfluous.


 > 2139:				#deleting the node, if it hasn't any outgoing arcs
 > 2140:				if { ![llength [$LevelGraph nodes -out $u]] || ![llength 
[$LevelGraph nodes -in $u]] } {
 > 2141:					if { $u != $s } {

Check u != s first, avoids the more expensive 'nodes -out/-in' commands when it 
can.


 > 2155:	#Malhotra, Kumar and Maheshwari Algorithm for finding blocking flow
 > 2156: 
#-------------------------------------------------------------------------------------
 > 2157:	#
 > 2158:	#Algorithm for given network G with source s and sink t, finds a blocking
 > 2159:	#flow, which can be used to obtain a maximum flow for that network G.
 > 2160:	#
 > 2161:	#For given node v, Let c(v) be the min{ a, b }, where a is the sum of 
all incoming
 > 2162:	#throughputs and b is the sum of all outcoming throughputs from the 
node v.
 > 2163:	#
 > 2164:	#Some steps that algorithm takes:
 > 2165:	#1. constructing the level graph from network G
 > 2166:	#2. until there are edges in level graph:

edges ? no edges ?

 > 2167:	#   3. finding the node with the minimum c(v)
 > 2168:	#   4. sending c(v) units of throughput by incoming arcs of v
 > 2169:	#	5. sending c(v) units of throughput by outcoming arcs of v
 > 2170:	#	6. 4 and 5 steps can cause exceed or deficiency of throughputs at 
nodes, so we

exceed => excess

 > 2171:	#	send exceeds forward choosing arcs greedily and...
 > 2172:	#	7. ...the same with deficiencies but we send those behind.

behind => backward.

 > 2173:	#	8. delete the v node from level graph
 > 2174:	#	9. upgrade the c values for all nodes
 > 2175:	#
 > 2176:	#10. if no other edges left in level graph, return b - found blocking flow
 > 2177:	#
 > 2178:	proc ::struct::graph::op::BlockingFlowByMKM {G s t} {
 > 2179:	


 > 2200:			foreach node [dict keys $c] {
 > 2201:				set cv [dict get $c $node]

Can also be written as

			dict for $c {node cv} {

per http://docs.activestate.com/activetcl/8.5/tcl/TclCmd/dict.htm#M12

 > 2264:			#7.
 > 2265:			for { set i [ expr { [dict get $distances $minCv_node] - 1} ] } { $i 
 > 0 } { decr i } {

Why not 'incr i -1' ?

 > 2279:			#9. correctingg the in/out throughputs for each node after
 > 2280:			#deleting one of the nodes in network

 > 2281:			set c [countThroughputsAtNodes $LevelGraph $s $t]

We might be able to avoid this if we can correct the per-node throughputs 
immediately, as part of the loops above. That is for the future however, as it 
would also make the code above more complex as well.

 > 2282:				
 > 2283:			#if node has no availiable outcoming or incoming throughput
 > 2284:			#delete that node from the graph
 > 2285:			foreach key [dict keys $c] {
 > 2286:				if { [dict get $c $key] == 0 } {

			dict for $c {key val} {
				 if { $val == 0 } {
 > 2293:		set b [dict filter $b script {flow flowvalue} {expr {$flowvalue != 0}}]
 > 2294:		#10.

LevelGraph is not destroyed, memory leak


 > 2295:		return $b
 > 2296:	}
 > 2297:	
 > 2325:	
 > 2326:	#Subprocedure for blocking flow finding by MKM algorithm
 > 2327:	#
 > 2328:	#It computes for graph G and each of his nodes the throughput value -
 > 2329:	#for node v: from the sum of availiable throughputs from incoming arcs and
 > 2330:	#the sum of availiable throughputs from outcoming arcs chooses lesser 
and sets
 > 2331:	#as the throughput of the node.
 > 2332:	#
 > 2333:	#Throughputs of nodes are returned in the dictionary.
 > 2334:	#
 > 2335:	proc ::struct::graph::op::countThroughputsAtNodes {G s t} {
 > 2336:	
 > 2337:		foreach v [$G nodes] {
 > 2338:			
 > 2339:			set outcoming [$G arcs -out $v]
 > 2340:			set incoming [$G arcs -in $v]
 > 2341:			
 > 2342:			set outsum 0
 > 2343:			set insum 0
 > 2344:			
 > 2345:			foreach o $outcoming i $incoming {
 > 2346:						
 > 2347:				if { !([llength $o] == 0) } {

	[llength $o] > 0

 > 2348:					set outsum [ expr { $outsum + [$G arc get $o throughput] } ]
 > 2349:				}
 > 2350:				
 > 2351:				if { !([llength $i] == 0) } {
 > 2352:					set insum [ expr { $insum + [$G arc get $i throughput] } ]
 > 2353:				}
 > 2354:				
 > 2355:				set value [Min $outsum $insum]
 > 2356:			}
 > 2357:			
 > 2358:			if { ($v ne $t) && ($v ne $s) } {

This condition means that the whole computation above was wasted. Better to 
move this to line 2338 and invert, i.e. let the loop 'continue' for v either s 
or t.

 > 2359:				dict set c $v $value
 > 2360:			}
 > 2361:		}
 > 2362:			
 > 2363:		return $c
 > 2364:	}
 > 2365:	
 > 2417:	
 > 2418:	#Subprocedure for blocking-flow finding algorithm by MKM
 > 2419:	#
 > 2420:	#It checks for graph G if node given at input has a exceed
 > 2421:	#or deficiency of throughput.
 > 2422:	#
 > 2423:	#For exceed the positive value of exceed is returned, for deficiency
 > 2424:	#procedure returns negative value. If the incoming throughput
 > 2425:	#is the same as outcoming, procedure returns 0.
 > 2426:	#
 > 2427:	proc ::struct::graph::op::findExcess {G node b} {
 > 2428:	
 > 2429:		set incoming 0
 > 2430:		set outcoming 0
 > 2431:		
 > 2432:		foreach key [dict keys $b] {

		lassign $key u v ?

 > 2433:			if { [lindex $key 0] eq $node } {
 > 2434:				set outcoming [ expr { $outcoming + [dict get $b $key] } ]
 > 2435:			}
 > 2436:			if { [lindex $key 1] eq $node } {
 > 2437:				set incoming [ expr { $incoming + [dict get $b $key] } ]
 > 2438:			}		
 > 2439:		}
 > 2440:		
 > 2441:		if { $incoming == $outcoming } {
 > 2442:			return 0
 > 2443:		}
 > 2444:		
 > 2445:		if { $incoming > $outcoming } {
 > 2446:			return [ expr { $incoming - $outcoming } ]
 > 2447:		} else {
 > 2448:			return [ expr { (-1) * ($outcoming - $incoming) } ]

	Or
			return [ expr { $outcoming - $incoming } ]


 > 2449:		}
 > 2450:		
 > 2451:	}

 > 3458:	
 > 3459:	proc ::struct::graph::op::decr { int { n 1 } } {

Might be easier to write

	incr i -1

at the call site.


 > 3460:	     if { [ catch {
 > 3461:		uplevel incr $int -$n
 > 3462:	     } err ] } {
 > 3463:		return -code error "decr: $err"
 > 3464:	     }
 > 3465:	     return [ uplevel set $int ]
 > 3466:	 }




Andreas.