Project Sewer

Tcl Chatroom

As sewer is starting out in Tcl, I've included a link to the Tcl Chatroom for getting help in developing sewer.

Also on Usenet, the comp.lang.tcl newsgroup. One of the most exceedingly helpful & friendly newsgroups on all of Usenet.

posted by Matt @ 8:34 AM 0 comments

Progress at last

A friend was asking what blogs I own (I have 9) and so I was showing him them all. He took an interest in the sewer project, mostly due to the name. I showed it to him and he was pleased at the use of Tcl in the project. I explained what I needed and he created, in about 5 minutes, the basic framework for sewer. It has been checked in at bin/sewer.tcl.

What it does is it allows you to enter a command and dump the results to a window. Then you can filter the results with another command. Repeat. More to follow soon hopefully now that I know someone who knows Tcl.

Yippee!!!

posted by Matt @ 6:43 AM 0 comments

gedlist.sh

Create a list of inidivuals listed in a GEDCOM file. In conjunction with topoged.

awk '$3 ~ "INDI" { id = $2 } $1 == "1" && $2 == "NAME" { $1 = ""; $2=""; print id "|" $0 } '

posted by Matt @ 6:06 PM 0 comments

How can a GUI and pipes interact?

A GUI can be any part of the pipeline.

First the GUI can be a sink, accepting data from the pipeline. This is the most obvious exmaple of GUIs working with pipes. It is natural for the GUI to display the final result of the pipe. Command line programs like pg, more and less currently serve this role. A GUI pager could provide the same functionality or even increased functionality with vertical and horizontal scrolling.

Second, the GUI can be a filter by reading data from the pipe and then sending it on. The odometer.tcl is an example of this. It listens on STDIN, writes to STDOUT and displays the number of bytes passed in a window. Other examples might be a last line read displayer, a progress bar, or a GUI tee program that writes to a window instead of a file.

A GUI can also be a data source. The GUI pager mentioned above could have an option to "Send to Pipe". The user would then specify the pipe in some manner and the data contained in the pager would be forwarded to the pipe. An example might be that you wanted a word count (wc) of the file. Just press "Send to Pipe", enter "wc | " and a new window would be opened that had the results of wc.

A GUI can also be thought of as allowing the user to interact on the pipeline. With command line pipes, the user doesn'e have much chance to even observe the data, let alone change it. GUI filters and sinks will allow more control and flexibility for the user.

Also, instead of creating huge menu structures with options people don't need, GUI programs should allow for users to add menu options on the fly, or configure them as they like. The menu options will be tied to pipes. The user will only see the options they really need and use. The programs themselvs become smaller as the program only need provide a small bit of functionality while delegating tasks to other small and specialized tasks.

posted by Matt @ 8:40 PM 0 comments

odometer.tcl

Here is the first file: odometer.tcl

proc read_more {} {

    set new [read stdin 4096]

    if [string length $new] {

	incr ::bytecount [string length $new]

	puts -nonewline stdout $new

	#.t insert end $new

	#.t see end

    }

    if [eof stdin] { exit }

    after 1 read_more

}



pack [label .odometer -textvar bytecount]

set bytecount 0

read_more

posted by Matt @ 7:53 PM

Why tcl/tk?

After minutes spent in an exhaustive search, tcl/tk was chosen as the initial platform for sewer development. The reasons are simple:

• It is available and fairly well supported on most platforms.
  
• It is easy to read from STDIN and write to STDOUT
  
• The graphics are very easy compared to other languages like Java.
  
• It about time I learned it
  

But, since the idea is to provide a framework rather than a specific implementation, other languages could and most certainly will be used as the project progresses.

posted by Matt @ 3:10 PM 0 comments

What is sewer?

For the initial epiphany see REST stands for Representational State Transfer.

This project is to provide substance to the thought. To implement GUI components that communicate via standard pipes, that is the goal.

Why sewer? It was going to be gui-pipes, which sounds like gooey-pipes, which reminds me of a sewer. Maybe I shouldn't name things while remodeling the old homestead. So, sewer it is.

posted by Matt @ 3:02 PM 0 comments