Home > Archive > Tcl > February 2005 > how do I do this ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how do I do this ?
|
|
|
| I want to run two programs ( one foreground, and one background) that can
read / change the same variable ( a [list] ) . THe background program
will keep the list updated, while the forground redisplays it when a
change is detected.
Can I do that using namespace ?
| |
| Googie 2005-02-24, 8:59 pm |
| Mitch wrote:
> I want to run two programs ( one foreground, and one background) that
> can
> read / change the same variable ( a [list] ) .
What do you mean by 'program'? Is it Tcl Script or standalone
executable application?
--
Pozdrawiam (Greetings)!
Googie
| |
|
| sorry to be so vague..
I want to run a Tcl script ,
that will run another tcl script in the background to keep a
buffer ( the [list] ) updated.
....M'
Googie wrote:
> Mitch wrote:
>
>
>
>
> What do you mean by 'program'? Is it Tcl Script or standalone
> executable application?
>
| |
| bbeacham@desanasystems.com 2005-02-24, 8:59 pm |
| Since you have 2 seperate process running you will need some type of
inter-process communication mechanism. When I do this I have one
program write to a file and the other program reads the file. If there
is a change then take action.
Another method is to open a pipe between the 2 programs, or use the
comm package in TCLLIB.
Also, I have stopped calling my TCL programs "scripts". I have noticed
that many people (managment types and even some engineers) think of
scripts as being trivial programs.
| |
|
| I need one program to update the variable in another one, can I use namespace to share
that varname ?
( and ditto about the "script" word, never to be used in mixed company! )
....M
bbeacham@desanasystems.com wrote:
> Since you have 2 seperate process running you will need some type of
> inter-process communication mechanism. When I do this I have one
> program write to a file and the other program reads the file. If there
> is a change then take action.
>
> Another method is to open a pipe between the 2 programs, or use the
> comm package in TCLLIB.
>
> Also, I have stopped calling my TCL programs "scripts". I have noticed
> that many people (managment types and even some engineers) think of
> scripts as being trivial programs.
>
| |
| Roy Terry 2005-02-24, 8:59 pm |
| "Mitch" <uqrudev@houston.rr.com> wrote in message
news:TEqTd.43017$cW2.40808@fe2.texas.rr.com...
> I need one program to update the variable in another one, can I use
namespace to share
> that varname ?
> ( and ditto about the "script" word, never to be used in mixed
company! )
>
> ...M
Nope. Separate Tcl programs cannot share variables.
If you truely need separate programs I suggest you make them communicate by
2 way pipes or sockets. Both methods are relatively easy in Tcl.
But perhaps you can solve your issue with 1 program. Folks here
will help if you explain in more detail. For example, what is the
"background"
program doing while it's not updating the list?
Roy
>
> bbeacham@desanasystems.com wrote:
>
| |
|
| I'll gladly elaborate.
My program displays and edits the data from a multichannel data set.
think of it
as a line graph of a sound wave.
(Actually between 15 to 50 channels simultaneously)
Each channel of data is stored as a textfile of integers, one value per line
typical files are 900,000 lines long, but could be much larger.
(now multiply that 900,000 scans by 15 channels, that is my basic data set !)
The User can use provided controls to zoom and "browse" up and down the graphs,
which are displayed as "line" objects on canvas widgets. A typical canvas would be
perhaps 900x75 (xy) in size.
I currently load up the whole banana, I load all the data in all the channels
into a tcl [list] which consists of a list of sublists, each sublist containing all the
data for one channel. (a list of lists) .
Then based on User input, I grab the part of the list that needs to be displayed and
redraw the linegraph on the canvas.
When I first wrote the program , the data sets were much smaller and all went well.
But now , the program has gotten popular , been distributed on 3 continents (oil field)
and now getting used on HUGE data sets that I never expected or tested for.
The result is that it A) eats up ALOT of RAM and B) the big [list] is clumsy.
Changing its contents (like after an edit) take a considerable time. As does getting an
lrange of data to display.
I am trying to find an alternative way to move quickly through the
data for zoom and browse operations.
My primary goal is to speed up the display and minimize RAM.
....Mitch
Roy Terry wrote:
> "Mitch" <uqrudev@houston.rr.com> wrote in message
> news:TEqTd.43017$cW2.40808@fe2.texas.rr.com...
>
>
> namespace to share
>
>
> company! )
>
>
> Nope. Separate Tcl programs cannot share variables.
>
> If you truely need separate programs I suggest you make them communicate by
> 2 way pipes or sockets. Both methods are relatively easy in Tcl.
>
> But perhaps you can solve your issue with 1 program. Folks here
> will help if you explain in more detail. For example, what is the
> "background"
> program doing while it's not updating the list?
>
> Roy
>
>
>
| |
|
|
| Dennis LaBelle 2005-02-24, 8:59 pm |
| Mitch wrote:
> I'll gladly elaborate.
>
> My program displays and edits the data from a multichannel data set.
>
> think of it
> as a line graph of a sound wave.
> (Actually between 15 to 50 channels simultaneously)
>
> Each channel of data is stored as a textfile of integers, one value
> per line
> typical files are 900,000 lines long, but could be much larger.
> (now multiply that 900,000 scans by 15 channels, that is my basic data set
> !)
>
> The User can use provided controls to zoom and "browse" up and down
> the graphs,
> which are displayed as "line" objects on canvas widgets. A typical
> canvas would be
> perhaps 900x75 (xy) in size.
>
> I currently load up the whole banana, I load all the data in all the
> channels
> into a tcl [list] which consists of a list of sublists, each sublist
> containing all the data for one channel. (a list of lists) .
> Then based on User input, I grab the part of the list that needs to
> be displayed and
> redraw the linegraph on the canvas.
>
> When I first wrote the program , the data sets were much smaller and all
> went well.
> But now , the program has gotten popular , been distributed on 3
> continents (oil field) and now getting used on HUGE data sets that I never
> expected or tested for.
>
> The result is that it A) eats up ALOT of RAM and B) the big [list]
> is clumsy.
> Changing its contents (like after an edit) take a considerable time. As
> does getting an lrange of data to display.
>
> I am trying to find an alternative way to move quickly through the
> data for zoom and browse operations.
>
>
> My primary goal is to speed up the display and minimize RAM.
>
> ...Mitch
>
If you are interested in speeding up your application, you should really
download and use the BLT exentension for TCL/TK.
This extension provides several additional widgets for TK, including a very
nice graph widget which has all that good zooming stuff built into it.
Additionally, you can load your data into BLT's vector object instead of a
list. This will allow you to store your data into memory using a binary
format.
You should also be able to remove a lot of TCL code whose functionality can
be replaced by the BLT graph widget.
| |
|
| hmmmmm, major code change, but sounds very interesting, I'll take a look.
.....M'
Dennis LaBelle wrote:
> Mitch wrote:
>
>
>
> If you are interested in speeding up your application, you should really
> download and use the BLT exentension for TCL/TK.
>
> This extension provides several additional widgets for TK, including a very
> nice graph widget which has all that good zooming stuff built into it.
> Additionally, you can load your data into BLT's vector object instead of a
> list. This will allow you to store your data into memory using a binary
> format.
>
> You should also be able to remove a lot of TCL code whose functionality can
> be replaced by the BLT graph widget.
>
| |
| Cameron Laird 2005-02-24, 8:59 pm |
| In article <1109276148.350090.52050@l41g2000cwc.googlegroups.com>,
<bbeacham@desanasystems.com> wrote:
>Since you have 2 seperate process running you will need some type of
>inter-process communication mechanism. When I do this I have one
>program write to a file and the other program reads the file. If there
>is a change then take action.
>
>Another method is to open a pipe between the 2 programs, or use the
>comm package in TCLLIB.
| |
|
| see previous post from me that starts on first line with :
"I'll gladly elaborate."
All suggestions are appreciated.
The BLT toolkit is starting to look like it would replace a couple hundred
hours of my time spent building my own graphing support ( already invested ),
nothing like a re-engineered wheel !
....M'
Cameron Laird wrote:
> In article <1109276148.350090.52050@l41g2000cwc.googlegroups.com>,
> <bbeacham@desanasystems.com> wrote:
>
>
> .
> .
> .
> I'm unconvinced, though, that Mitch *really* wants two separate
> processes. His ultimate goal might actually allow for some sort
> of in-process "co-operative multiscripting".
>
> Or, in yet another direction, he might like thread-enabled Tcl.
>
> Without more details from him, we don't know.
| |
| Dennis LaBelle 2005-02-26, 3:59 am |
| Lines: 79
User-Agent: KNode/0.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-ID: <Z4STd.29682$vK5.21336@twister.nyroc.rr.com>
Date: Sat, 26 Feb 2005 03:32:09 GMT
NNTP-Posting-Host: 24.195.140.39
X-Complaints-To: abuse@rr.com
X-Trace: twister.nyroc.rr.com 1109388729 24.195.140.39 (Fri, 25 Feb 2005 22:32:09 EST)
NNTP-Posting-Date: Fri, 25 Feb 2005 22:32:09 EST
Organization: Road Runner
Xref: number1.nntp.dca.giganews.com comp.lang.tcl:243398
Mitch wrote:
> yup , that's me.
> I wish I has realized how this thing was going to explode before I
> developed 100's of
> computer assisted functions, over 3 years of development. If I re-did it
> from the ground
> up I could really make it kick-a$$. But that's not a very cost effective
> option now. The customer likes it, but not enthustic about a paying for a
> complete rewrite.
>
> ANd yes, I "did" do some review of the metakit venue and spent a few hours
> writing a "proof of concept" procedure to emulate what I needed to do, but
> because of a detail (see *note below), my data changes often and has to be
> reloaded into the metakit matrix from a textfile frequently.
>
> The access time to get to the metakit handled data internally from my Tcl
> programs was a __great__ improvement, but it got eaten up by the time
> spent making updates to the metakit data, when external programs changed
> the data.
>
> ( although I don't know what to call it... but in my mind, I was
> looking for a was a
> way to tie a memory buffer to the diskfile. SO if I changed data in the
> buffer, some low overhead background process would update the file. I
> never had much luck with that idea )
>
> *Note from above:
> Some of the transforms I perform on the data matrix as a result of user
> editing or requested math functions require some major number crunching,
> most of those functions are
> handled by external programs that I "exec" from TclTK. Those program are
> written in fortran, C (ugh! ptewy!), or Pascal (nostalgic) and process the
> math functions on the huge datasets much faster than tcl.
>
> As always,
> I still have big ears for new suggestions, and rethinking old ones.
>
I hope you are also taking a good look at BLT's vector data type and the
transformations that it can perform on the data contained within a vector.
It may provide enough functionality to replace some of the number crunching
programs you now have to [exec].
If you don't have any need for permanent storage of the displayed data, you
may wish to consider eliminating the use of disk files by funneling the
data directly to your TCL/TK application through a TCP socket. If you have
the source code for the FORTRAN and Pascal number crunchers, you could
create an application that:
1) Collects your 15 channels of data
2) Performs the necessary data transformations
3) Transfers the data to your TCL/TK display program using a TCP socket.
This would eliminate the time-consuming overhead of writing and reading to a
physical disk file. You could also use a TCP socket to send a command to
your FORTRAN/Pascal program. This command would instruct the FORTRAN/Pascal
program on the type of data transformation you wish to make.
ALTERNATIVELY, you could build your own version of WISH that contains your
FORTRAN and Pascal code. This enhanced WISH could then be used to do
everything you need:
1) Collect the 15 channels of data
2) Perform the necessary data transformations
3) Load the data into a BLT vector
4) Display the data using a BLT graph widget.
All without writing any data to a slow physical device (i.e., hard drive).
I hope this gives you a few more ideas.
NOTICE: End of free advice....Shameless self-promotion follows:
Now, if you would like to consult, for a fee, with a Chemical Engineer and
Computer Scientist with 12 years of TCL/TK experience (among other software
and engineering skills) you may want to contact me via e-mail. A seasoned
veteran could help you get where you want to go a lot faster.
| |
|
| have you been looking over my shoulder ?
since yesterday I have , looked at BLT for graphing the "view" instead of using the
Tk method ( canvas create line...), I also am reviewing the "worker programs" (not all
written my me), to see if I can set them up to take a pipe. And ... I have started to
get more comfortable with the concept of a total program rewrite,at least I am not
screeming into my pillow quite as often ....
And as I write this post , I am also diagraming on paper the user communication
requiremnts of my display, I have to be able to maintain info (mostly retrieved from mouse
bindings) to quickly know information like which channel of data the user wants to act
upon and at what range of scan numbers in the data are to be affected.
Are you related to The Amazing Kreskin ?
Dennis LaBelle wrote:
> Mitch wrote:
>
>
>
>
> I hope you are also taking a good look at BLT's vector data type and the
> transformations that it can perform on the data contained within a vector.
> It may provide enough functionality to replace some of the number crunching
> programs you now have to [exec].
>
> If you don't have any need for permanent storage of the displayed data, you
> may wish to consider eliminating the use of disk files by funneling the
> data directly to your TCL/TK application through a TCP socket. If you have
> the source code for the FORTRAN and Pascal number crunchers, you could
> create an application that:
> 1) Collects your 15 channels of data
> 2) Performs the necessary data transformations
> 3) Transfers the data to your TCL/TK display program using a TCP socket.
> This would eliminate the time-consuming overhead of writing and reading to a
> physical disk file. You could also use a TCP socket to send a command to
> your FORTRAN/Pascal program. This command would instruct the FORTRAN/Pascal
> program on the type of data transformation you wish to make.
>
> ALTERNATIVELY, you could build your own version of WISH that contains your
> FORTRAN and Pascal code. This enhanced WISH could then be used to do
> everything you need:
> 1) Collect the 15 channels of data
> 2) Perform the necessary data transformations
> 3) Load the data into a BLT vector
> 4) Display the data using a BLT graph widget.
> All without writing any data to a slow physical device (i.e., hard drive).
>
> I hope this gives you a few more ideas.
>
>
> NOTICE: End of free advice....Shameless self-promotion follows:
>
> Now, if you would like to consult, for a fee, with a Chemical Engineer and
> Computer Scientist with 12 years of TCL/TK experience (among other software
> and engineering skills) you may want to contact me via e-mail. A seasoned
> veteran could help you get where you want to go a lot faster.
>
>
>
>
| |
| Cameron Laird 2005-02-26, 3:59 pm |
| In article <e40Ud.52094$cW2.31006@fe2.texas.rr.com>,
Mitch <uqrudev@houston.rr.com> wrote:
>have you been looking over my shoulder ?
>
> since yesterday I have , looked at BLT for graphing the "view"
>instead of using the
>Tk method ( canvas create line...), I also am reviewing the "worker
>programs" (not all
>written my me), to see if I can set them up to take a pipe. And ... I
>have started to
>get more comfortable with the concept of a total program rewrite,at
>least I am not
>screeming into my pillow quite as often ....
>
> And as I write this post , I am also diagraming on paper the user
>communication
>requiremnts of my display, I have to be able to maintain info (mostly
>retrieved from mouse
>bindings) to quickly know information like which channel of data the
>user wants to act
>upon and at what range of scan numbers in the data are to be affected.
>
>Are you related to The Amazing Kreskin ?
|
|
|
|
|