Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl Programming Language" by Ashok Nadkarni, Tasks can take an independent procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large) fibonacci numbers 3-5 times faster than if done sequentially when run on
a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced or
if placed in an appropriate module folder loaded via package require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
On 5/18/22 00:33, et4 wrote:
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the
powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl
Programming Language" by Ashok Nadkarni, Tasks can take an independent
procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large)
fibonacci numbers 3-5 times faster than if done sequentially when run
on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced
or if placed in an appropriate module folder loaded via package require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
Please consider submitting this to be a part of TclLib.
On 5/18/2022 3:04 PM, Gerald Lester wrote:I am not inclined to watch videos like this, I am afraid, but I do like the idea of this package and I want to explore it.
On 5/18/22 00:33, et4 wrote:
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the
powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl
Programming Language" by Ashok Nadkarni, Tasks can take an independent
procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large)
fibonacci numbers 3-5 times faster than if done sequentially when run
on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced
or if placed in an appropriate module folder loaded via package require. >>
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
Please consider submitting this to be a part of TclLib.
Thanks for the feedback. Not sure what that would entail. And it's
available from github; I specified no-license.
It conforms to the tcl module definition, meaning a single file that can
be sourced. So, I'm not sure what benefit would be derived from it being
in the tcllib.
But thanks for suggesting it. Perhaps after I get some feedback. Of my 4
yt videos on it, I think I have perhaps 2 views that aren't me and 1 of
those is from my daughter who swears she watched the whole video but
can't tell me anything about it :)
On Thursday, May 19, 2022 at 4:40:28 AM UTC+2, et4 wrote:
On 5/18/2022 3:04 PM, Gerald Lester wrote:I am not inclined to watch videos like this, I am afraid, but I do like the idea of this package and I want to explore it.
On 5/18/22 00:33, et4 wrote:Thanks for the feedback. Not sure what that would entail. And it's
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the
powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl
Programming Language" by Ashok Nadkarni, Tasks can take an independent >>>> procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be >>>> called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might >>>> be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large)
fibonacci numbers 3-5 times faster than if done sequentially when run
on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced
or if placed in an appropriate module folder loaded via package require. >>>>
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
Please consider submitting this to be a part of TclLib.
available from github; I specified no-license.
It conforms to the tcl module definition, meaning a single file that can
be sourced. So, I'm not sure what benefit would be derived from it being
in the tcllib.
But thanks for suggesting it. Perhaps after I get some feedback. Of my 4
yt videos on it, I think I have perhaps 2 views that aren't me and 1 of
those is from my daughter who swears she watched the whole video but
can't tell me anything about it :)
One advantage of having it Tcllib is that it is part of a large collection of packages so people can more easily find it.
Regards,
Arjen
On 5/19/2022 1:23 AM, Arjen Markus wrote:
On Thursday, May 19, 2022 at 4:40:28 AM UTC+2, et4 wrote:
On 5/18/2022 3:04 PM, Gerald Lester wrote:I am not inclined to watch videos like this, I am afraid, but I do
On 5/18/22 00:33, et4 wrote:Thanks for the feedback. Not sure what that would entail. And it's
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the >>>>> powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl >>>>> Programming Language" by Ashok Nadkarni, Tasks can take an independent >>>>> procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be >>>>> called several times.
The Tasks proc-like arglist approach considerably reduces the need to >>>>> learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might >>>>> be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below >>>>> example a Tproc can compute the number of digits of 5 (rather large) >>>>> fibonacci numbers 3-5 times faster than if done sequentially when run >>>>> on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced >>>>> or if placed in an appropriate module folder loaded via package
require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one >>>>> into concurrent programming to better utilize these new machines.
Please consider submitting this to be a part of TclLib.
available from github; I specified no-license.
It conforms to the tcl module definition, meaning a single file that can >>> be sourced. So, I'm not sure what benefit would be derived from it being >>> in the tcllib.
But thanks for suggesting it. Perhaps after I get some feedback. Of my 4 >>> yt videos on it, I think I have perhaps 2 views that aren't me and 1 of
those is from my daughter who swears she watched the whole video but
can't tell me anything about it :)
like the idea of this package and I want to explore it.
One advantage of having it Tcllib is that it is part of a large
collection of packages so people can more easily find it.
Regards,
Arjen
Yeah, I'm definitely not the youtube star in my family, which would be
my daughter who sings and has 500 followers :)
I would then recommend reading the wiki page, especially the intro which
is quite short.
I had 2 goals when I started. I wanted to concentrate on using arglists
vs. sending in scripts. And I wanted to code in a more sequential style
than using event callbacks. I had looked into Ashok's promises, and I
wanted to take a shot at my own abstraction.
Since tcl threads don't directly share memory, they are closer to
processes, and even processes use arglists (argc/argv). However, tsv is
much more convenient and faster than other process to process
communication and memory sharing (plus it's system independent).
So, my task metaphor, is similar to processes but can use tsv. Unlike
the thread package, which needs to be an all things to everyone kind of package, tasks are meant to do the 50-90% of the things you might want
with simplicity, and well, there's always threads and tpool if tasks
can't do it. I believe tasks are about as simple as I could make it.
So, a task sits in a loop getting arglists from a queue, doing something
with them, and returns a result. This can thus look like a server, e.g.
an http request, but also looks like a procedure call. Using Ashok's
method for sharing the queue, which I'd never had been able to code
myself, tasks could now work as a team.
The second goal was to be able to take any compute-hog procedure (and
all it's called procedures) and get them loaded into a thread so the GUI
in the mainthread would remain responsive. Using Ashok's proc
reconstruct as a starting point lets me easily import procs into a
thread. Of course, there's some thread support for that, but I really
didn't quite understand tpool and ttrace.
And since someone had the insight into providing a timeout in
thread::cond one can use that while waiting for a job/arglist to arrive
to service events as well. Yes, it's a polling mechanism, but when done inside your own thread, it's no biggy. This lets me have a responsive
gui in each thread. It also lets me respond to thread::send from the
outside. And that's especially useful for debugging, and so there's a
console like task (may as well be in its own thread) that lifted some of
the actual windows console code that does command and variable tab
expansion.
Initially I was going to support a wait for all jobs to complete AND a
wait for one or a set of jobs, but I realized this was when an event was easier, and so I only have a wait for all. However, I can also do a
write trace on a result variable for when I want to respond with events
as each job finishes.
But by NOT supporting more than a wait for all, I avoid all the job id's
etc that are used in tpool. One of the examples demonstrates using a
trace. And the code sets that up for you by just specifying a -N for the number of tasks. Also nice in tcl is that one can use the same name for
a procedure and a variable with no conflicts. So, tasks use the same
name for the trace callback proc and the array that gets the results if
you do a wait for all. This avoids needing calls like tpool::get as well.
Anyway, this was just some covid coding fun. But I wanted to share it,
and so the wiki page and this announcement.
On 5/19/22 11:54, et4 wrote:
On 5/19/2022 1:23 AM, Arjen Markus wrote:
On Thursday, May 19, 2022 at 4:40:28 AM UTC+2, et4 wrote:
On 5/18/2022 3:04 PM, Gerald Lester wrote:I am not inclined to watch videos like this, I am afraid, but I do
On 5/18/22 00:33, et4 wrote:Thanks for the feedback. Not sure what that would entail. And it's
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the >>>>>> powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl >>>>>> Programming Language" by Ashok Nadkarni, Tasks can take an
independent
procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need
to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to >>>>>> learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks
might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below >>>>>> example a Tproc can compute the number of digits of 5 (rather large) >>>>>> fibonacci numbers 3-5 times faster than if done sequentially when run >>>>>> on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be sourced >>>>>> or if placed in an appropriate module folder loaded via package
require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one >>>>>> into concurrent programming to better utilize these new machines.
Please consider submitting this to be a part of TclLib.
available from github; I specified no-license.
It conforms to the tcl module definition, meaning a single file that
can
be sourced. So, I'm not sure what benefit would be derived from it
being
in the tcllib.
But thanks for suggesting it. Perhaps after I get some feedback. Of
my 4
yt videos on it, I think I have perhaps 2 views that aren't me and 1 of >>>> those is from my daughter who swears she watched the whole video but
can't tell me anything about it :)
like the idea of this package and I want to explore it.
One advantage of having it Tcllib is that it is part of a large
collection of packages so people can more easily find it.
Regards,
Arjen
Yeah, I'm definitely not the youtube star in my family, which would be
my daughter who sings and has 500 followers :)
I would then recommend reading the wiki page, especially the intro
which is quite short.
I had 2 goals when I started. I wanted to concentrate on using
arglists vs. sending in scripts. And I wanted to code in a more
sequential style than using event callbacks. I had looked into Ashok's
promises, and I wanted to take a shot at my own abstraction.
Since tcl threads don't directly share memory, they are closer to
processes, and even processes use arglists (argc/argv). However, tsv
is much more convenient and faster than other process to process
communication and memory sharing (plus it's system independent).
So, my task metaphor, is similar to processes but can use tsv. Unlike
the thread package, which needs to be an all things to everyone kind
of package, tasks are meant to do the 50-90% of the things you might
want with simplicity, and well, there's always threads and tpool if
tasks can't do it. I believe tasks are about as simple as I could make
it.
So, a task sits in a loop getting arglists from a queue, doing
something with them, and returns a result. This can thus look like a
server, e.g. an http request, but also looks like a procedure call.
Using Ashok's method for sharing the queue, which I'd never had been
able to code myself, tasks could now work as a team.
The second goal was to be able to take any compute-hog procedure (and
all it's called procedures) and get them loaded into a thread so the
GUI in the mainthread would remain responsive. Using Ashok's proc
reconstruct as a starting point lets me easily import procs into a
thread. Of course, there's some thread support for that, but I really
didn't quite understand tpool and ttrace.
And since someone had the insight into providing a timeout in
thread::cond one can use that while waiting for a job/arglist to
arrive to service events as well. Yes, it's a polling mechanism, but
when done inside your own thread, it's no biggy. This lets me have a
responsive gui in each thread. It also lets me respond to thread::send
from the outside. And that's especially useful for debugging, and so
there's a console like task (may as well be in its own thread) that
lifted some of the actual windows console code that does command and
variable tab expansion.
Initially I was going to support a wait for all jobs to complete AND a
wait for one or a set of jobs, but I realized this was when an event
was easier, and so I only have a wait for all. However, I can also do
a write trace on a result variable for when I want to respond with
events as each job finishes.
But by NOT supporting more than a wait for all, I avoid all the job
id's etc that are used in tpool. One of the examples demonstrates
using a trace. And the code sets that up for you by just specifying a
-N for the number of tasks. Also nice in tcl is that one can use the
same name for a procedure and a variable with no conflicts. So, tasks
use the same name for the trace callback proc and the array that gets
the results if you do a wait for all. This avoids needing calls like
tpool::get as well.
Anyway, this was just some covid coding fun. But I wanted to share it,
and so the wiki page and this announcement.
Both Arjen are very familiar with Tcl tasks -- I did read your wiki
page. I think the package is a good way for simple tasks and would be
more widely used as part of TclLib.
On 5/19/2022 2:50 PM, Gerald Lester wrote:
On 5/19/22 11:54, et4 wrote:
On 5/19/2022 1:23 AM, Arjen Markus wrote:
On Thursday, May 19, 2022 at 4:40:28 AM UTC+2, et4 wrote:
On 5/18/2022 3:04 PM, Gerald Lester wrote:I am not inclined to watch videos like this, I am afraid, but I do
On 5/18/22 00:33, et4 wrote:Thanks for the feedback. Not sure what that would entail. And it's
Announcing Tasks 1.12 an easy way to use Tcl threads.Please consider submitting this to be a part of TclLib.
Tasks are an approach to writing multi-threaded script code using >>>>>>> the
powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl >>>>>>> Programming Language" by Ashok Nadkarni, Tasks can take an
independent
procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need >>>>>>> to be
called several times.
The Tasks proc-like arglist approach considerably reduces the
need to
learn new concepts. If you've wanted to dive into the Tcl threads >>>>>>> package but haven't had the time to study the manual, then Tasks >>>>>>> might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below >>>>>>> example a Tproc can compute the number of digits of 5 (rather large) >>>>>>> fibonacci numbers 3-5 times faster than if done sequentially when >>>>>>> run
on a multi-core cpu:
...
with a single-file tcl module named tasks-1.12.tm that can be
sourced
or if placed in an appropriate module folder loaded via package
require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one >>>>>>> into concurrent programming to better utilize these new machines. >>>>>>
available from github; I specified no-license.
It conforms to the tcl module definition, meaning a single file
that can
be sourced. So, I'm not sure what benefit would be derived from it
being
in the tcllib.
But thanks for suggesting it. Perhaps after I get some feedback. Of
my 4
yt videos on it, I think I have perhaps 2 views that aren't me and
1 of
those is from my daughter who swears she watched the whole video but >>>>> can't tell me anything about it :)
like the idea of this package and I want to explore it.
One advantage of having it Tcllib is that it is part of a large
collection of packages so people can more easily find it.
Regards,
Arjen
Yeah, I'm definitely not the youtube star in my family, which would
be my daughter who sings and has 500 followers :)
I would then recommend reading the wiki page, especially the intro
which is quite short.
I had 2 goals when I started. I wanted to concentrate on using
arglists vs. sending in scripts. And I wanted to code in a more
sequential style than using event callbacks. I had looked into
Ashok's promises, and I wanted to take a shot at my own abstraction.
Since tcl threads don't directly share memory, they are closer to
processes, and even processes use arglists (argc/argv). However, tsv
is much more convenient and faster than other process to process
communication and memory sharing (plus it's system independent).
So, my task metaphor, is similar to processes but can use tsv. Unlike
the thread package, which needs to be an all things to everyone kind
of package, tasks are meant to do the 50-90% of the things you might
want with simplicity, and well, there's always threads and tpool if
tasks can't do it. I believe tasks are about as simple as I could
make it.
So, a task sits in a loop getting arglists from a queue, doing
something with them, and returns a result. This can thus look like a
server, e.g. an http request, but also looks like a procedure call.
Using Ashok's method for sharing the queue, which I'd never had been
able to code myself, tasks could now work as a team.
The second goal was to be able to take any compute-hog procedure (and
all it's called procedures) and get them loaded into a thread so the
GUI in the mainthread would remain responsive. Using Ashok's proc
reconstruct as a starting point lets me easily import procs into a
thread. Of course, there's some thread support for that, but I really
didn't quite understand tpool and ttrace.
And since someone had the insight into providing a timeout in
thread::cond one can use that while waiting for a job/arglist to
arrive to service events as well. Yes, it's a polling mechanism, but
when done inside your own thread, it's no biggy. This lets me have a
responsive gui in each thread. It also lets me respond to
thread::send from the outside. And that's especially useful for
debugging, and so there's a console like task (may as well be in its
own thread) that lifted some of the actual windows console code that
does command and variable tab expansion.
Initially I was going to support a wait for all jobs to complete AND
a wait for one or a set of jobs, but I realized this was when an
event was easier, and so I only have a wait for all. However, I can
also do a write trace on a result variable for when I want to respond
with events as each job finishes.
But by NOT supporting more than a wait for all, I avoid all the job
id's etc that are used in tpool. One of the examples demonstrates
using a trace. And the code sets that up for you by just specifying a
-N for the number of tasks. Also nice in tcl is that one can use the
same name for a procedure and a variable with no conflicts. So, tasks
use the same name for the trace callback proc and the array that gets
the results if you do a wait for all. This avoids needing calls like
tpool::get as well.
Anyway, this was just some covid coding fun. But I wanted to share
it, and so the wiki page and this announcement.
Both Arjen are very familiar with Tcl tasks -- I did read your wiki
page. I think the package is a good way for simple tasks and would be
more widely used as part of TclLib.
I have no objections to it being part of tcllib, however, I haven't a
clue how that would be accomplished.
Is it anything like a TIP? In 20 years I've got 2 TIPs approved (they're
in 8.7 finally) but I still don't know how to create a TIP myself. And
the one I really wanted never even got to the TIP stage.
But if anyone wants to grab the code and submit it, I have no
objections. I'm quite a novice at github, but I can grant any access to anyone if I'm told how.
If it's in tcllib, how is it maintained? Does it need a real manual? I'm getting a bit old in the tooth to be able to do much more (now in my 4th quarter century). I code only for fun, and have to limit the time in
front of my computers.
But I did just build a super cool new machine, an intel i7-12700k with
12 cores and 20 threads. With tasks, I can peg the machine till it
screams :)
Like this:
tcl::tm::path add d:/stuff
package require tasks 1.13
namespace import tasks::*
console show
Tproc peg {x} {
xwait $x ;# busy wait
putz "after $x inside $::t_name" red
} -tasks 20 -import_tasks -once [list {-set t_debug 2 ;# to console}]
set x 5000
tgroup peg -call $x
after [expr { $x + 4000 }] {tdump xxx} ;# still running ?
Oh my, it was so much easier when I started on punchcards in the 60's.
No software patents or licenses to worry about. I guess it's true, no
good deed goes unpunished.
Any advice?
On 5/20/2022 9:38 AM, et4 wrote:
Oh my, it was so much easier when I started on punchcards in the 60's.
No software patents or licenses to worry about. I guess it's true, no
good deed goes unpunished.
Any advice?
It's easy enough on github. Either add a LICENSE file in your work tree, commit and push to github. Or even easier, click on the Add File button
in the github code page, click Create File, on the create file page type LICENSE as the file name. A button "choose license template" will then automatically appear on the right side. Click that, choose an
appropriate license (one of the BSD ones is most common for Tcl
extensions), then at the bottom choose the radio button that says
"commit to master" or something like that (not the one to create a
branch), then click the commit button.
I had 2 goals when I started. I wanted to concentrate on using arglists
vs. sending in scripts. And I wanted to code in a more sequential style
than using event callbacks.
On 5/19/22 12:54 PM, et4 wrote:
I had 2 goals when I started. I wanted to concentrate on using
arglists vs. sending in scripts. And I wanted to code in a more
sequential style than using event callbacks.
Hello,
Interesting project. Can you expand on the distinction between arglist
and scripts?
If you want to wait for all jobs to be ready, you have to calltpool::wait in a loop. Something like this:
Maybe others are also like me.
Great question! It comes down to familiarity. The expert won't have any trouble with the distinction, but a beginner might find the Tasks implementation looks a bit more like what they are used to.
On 5/20/22 6:45 PM, et4 wrote:
Great question! It comes down to familiarity. The expert won't have
any trouble with the distinction, but a beginner might find the Tasks
implementation looks a bit more like what they are used to.
Hello,
Thank you for the detailed response. I thought you were somehow avoiding sending any scripts to the threads. It looks like you're simplifying
that process via your Tproc's and managing the rest with arglists.
BTW, perhaps you could package-enable it by adding a "package provide
Tasks" or something similar in your code.
One bragging point.
BTW, perhaps you could package-enable it by adding a "package provide
Tasks" or something similar in your code.
Interesting, Ashok does say you *need* a package provide in a module.
But I can package require it w/o that. Also, if when I do add one and
give it a different version than the file name, it errors out.
Interesting, Ashok does say you *need* a package provide in a module.
But I can package require it w/o that. Also, if when I do add one and
give it a different version than the file name, it errors out.
So, I guess I don't understand why it's needed. The only version one can specify must be encoded in the file name, so wouldn't it make sense for
the package command to assume that's what it is providing?
Anyway, it's easy enough to tack on to the end of the file, so I will do
it - thanks.
I'm glad you didn't hate my response, I usually hate them after I write
them. Too bad you can't edit them, like on the wiki. Ignore the below if
you want, but I can't resist describing the design of Tasks, and perhaps answer arglist vs. scripts better.
The only way I could get it to work is by doing:
source tasks-tasks-1.12.tm
namespace import tasks::*
Can I assume you didn't use tasks-tasks-1.12.tm as you state?
What did you actually try with a package require command?
The file name has to be exactly as in the download tasks-1.12.tm and in
my case has to be in the folder I specify:
tasks::Tproc foo {a} {
incr a
return $a
} -tasks 1 ;# default is 4 otherwise
% tcl::tm::path add .
% package require tasks-1.12.tm
can't find package tasks-1.12.tm
package ifneeded tasks 1.12 [string map [list @ $dir] {
source [file join {@} tasks-1.12.tm]
namespace import tasks::*
package provide tasks 1.12
}]
On 5/22/2022 7:56 PM, Dave wrote:
package ifneeded tasks 1.12 [string map [list @ $dir] {
source [file join {@} tasks-1.12.tm]
namespace import tasks::*
package provide tasks 1.12
}]
Do you have to be su for that to work? I get an error about $dir on both windows and linux. Or does that not work with modules?
On 5/21/2022 8:26 AM, saitology9@gmail.com wrote:It's unnecessary. And the way you did it, by including the version
BTW, perhaps you could package-enable it by adding a "package provide Tasks" or something similar in your code.
Anyway, it's easy enough to tack on to the end of the file, so I will do > it - thanks.
On 5/22/2022 7:56 PM, Dave wrote:
package ifneeded tasks 1.12 [string map [list @ $dir] {
source [file join {@} tasks-1.12.tm]
namespace import tasks::*
package provide tasks 1.12
}]
Do you have to be su for that to work? I get an error about $dir on both windows and linux. Or does that not work with modules?
On windows, none of paths work, since I only use tclkits.
On 22/05/2022 09:07, et4 wrote:
On 5/21/2022 8:26 AM, saitology9@gmail.com wrote:
BTW, perhaps you could package-enable it by adding a "package provide
Tasks" or something similar in your code.
Anyway, it's easy enough to tack on to the end of the file, so I willIt's unnecessary. And the way you did it, by including the version
do > it - thanks.
number, it became a maintenance burden. When the version number number changes, you now have to remember to update it in two places. I suggest
to remove it again. I never include a [package provide] command in my
modules and they work fine.
Schelte.
On 5/22/2022 11:09 PM, et4 wrote:
On 5/22/2022 7:56 PM, Dave wrote:
package ifneeded tasks 1.12 [string map [list @ $dir] {
source [file join {@} tasks-1.12.tm]
namespace import tasks::*
package provide tasks 1.12
}]
Do you have to be su for that to work? I get an error about $dir on both
windows and linux. Or does that not work with modules?
On windows, none of paths work, since I only use tclkits.
Part of your discussion seemed to be how to turn the .TM into a package.
I'm using 8.6.11 on win7x64 -- not a tclkit. Putting the .TM and the
above pkgIndex.tcl into ...\Tcl\lib\tasks successfully makes "tasks"
able to be loaded from "package require tasks", and the Tproc procedure successfully imported.
While .TM's may be more efficient, I prefer stuff to be in one place: \lib
Just thought I'd share what worked for me.
On 22/05/2022 09:07, et4 wrote:
On 5/21/2022 8:26 AM, saitology9@gmail.com wrote:
BTW, perhaps you could package-enable it by adding a "package provide
Tasks" or something similar in your code.
Anyway, it's easy enough to tack on to the end of the file, so I willIt's unnecessary. And the way you did it, by including the version
do > it - thanks.
number, it became a maintenance burden. When the version number number changes, you now have to remember to update it in two places. I suggest
to remove it again. I never include a [package provide] command in my
modules and they work fine.
Schelte.
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl Programming Language" by Ashok Nadkarni, Tasks can take an independent procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large) fibonacci numbers 3-5 times faster than if done sequentially when run on
a multi-core cpu:
(example derived from Ashok's Promises blog)
#----------------------------------------
source tasks-1.12.tm
namespace import tasks::*
Tproc fibsize {number} {
set fibnum [math::fibonacci $number]
string length $fibnum
} -tasks 5 [list {-package require math} ]
tgroup fibsize -run 100000 100100 100200 100300 100400
parray fibsize rvar,*
#----------------------------------------
Here, tgroup runs the 5 tasks (threads) concurrently and delivers the
results to the array fibsize. [parray] then outputs the results.
Tasks include several development tools including a handy 1 line Tk
console and optionally one Tk window per task. It can send the same
command to each singly or with patterns, to all or a specific group
using task names.
Note: a bug was discovered that can cause Tcl/Tk to crash in linux
systems when running Tk in several threads. According to the ticket, it
has been fixed, but I don't know which version the fix will be included
in. For now, the code does not output using Tk but rather does puts to stdout. If you want to try it anyway, search for "hack 2" and comment
out the incr statement. Its about line 51.
Since task globals are partitioned by an interpreter, they are like
namespace variables, and very easy to use. Included are list tools for
global scalars, arrays, and a widget tree browser. Multiple monitors are
a must.
Tasks are source-able pure tcl. The wiki page at
https://wiki.tcl-lang.org/page/Tasks
provides all the documentation, examples and YouTube links to videos
with intros and in-depth code walk-throughs to get you going with Tasks.
The source is at GitHub at
https://github.com/rocketship88/Tasks.git
with a single-file tcl module named tasks-1.12.tm that can be sourced or
if placed in an appropriate module folder loaded via package require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
Hi,
would it be possible to post an network client/server code using tasks ?
best regards
Michael
et4 wrote:
Announcing Tasks 1.12 an easy way to use Tcl threads.
Tasks are an approach to writing multi-threaded script code using the
powerful and dynamic Tcl/Tk programming language.
Based on techniques and code from the highly acclaimed book "The Tcl
Programming Language" by Ashok Nadkarni, Tasks can take an independent
procedure and transform it into a multi-threaded server. It is
especially useful for compute intensive math functions that need to be
called several times.
The Tasks proc-like arglist approach considerably reduces the need to
learn new concepts. If you've wanted to dive into the Tcl threads
package but haven't had the time to study the manual, then Tasks might
be just the ticket for you.
Tasks provide [Tproc] an extension to the proc command. In the below
example a Tproc can compute the number of digits of 5 (rather large)
fibonacci numbers 3-5 times faster than if done sequentially when run on
a multi-core cpu:
(example derived from Ashok's Promises blog)
#----------------------------------------
source tasks-1.12.tm
namespace import tasks::*
Tproc fibsize {number} {
set fibnum [math::fibonacci $number]
string length $fibnum
} -tasks 5 [list {-package require math} ]
tgroup fibsize -run 100000 100100 100200 100300 100400
parray fibsize rvar,*
#----------------------------------------
Here, tgroup runs the 5 tasks (threads) concurrently and delivers the
results to the array fibsize. [parray] then outputs the results.
Tasks include several development tools including a handy 1 line Tk
console and optionally one Tk window per task. It can send the same
command to each singly or with patterns, to all or a specific group
using task names.
Note: a bug was discovered that can cause Tcl/Tk to crash in linux
systems when running Tk in several threads. According to the ticket, it
has been fixed, but I don't know which version the fix will be included
in. For now, the code does not output using Tk but rather does puts to
stdout. If you want to try it anyway, search for "hack 2" and comment
out the incr statement. Its about line 51.
Since task globals are partitioned by an interpreter, they are like
namespace variables, and very easy to use. Included are list tools for
global scalars, arrays, and a widget tree browser. Multiple monitors are
a must.
Tasks are source-able pure tcl. The wiki page at
https://wiki.tcl-lang.org/page/Tasks
provides all the documentation, examples and YouTube links to videos
with intros and in-depth code walk-throughs to get you going with Tasks.
The source is at GitHub at
https://github.com/rocketship88/Tasks.git
with a single-file tcl module named tasks-1.12.tm that can be sourced or
if placed in an appropriate module folder loaded via package require.
Since CPU core counts are on the rise, Tcl Tasks can gently ease one
into concurrent programming to better utilize these new machines.
On 5/26/2022 12:10 PM, Michael Niehren wrote:
Hi,
would it be possible to post an network client/server code using tasks
?
best regards
Michael
I believe I mistook your request for a question. I've uploaded to the
wiki page a client/server network example:
https://wiki.tcl-lang.org/page/Tasks
It's the last example on the wiki page.
There are 2 code blocks, one for each side. I tested it on windows and
linux but the first line of the server needs to be changed to point to
the path/to/ folder on either system of the tasks module location. The
very latest is at github, see the link in the first post here.
It is an echo/string-reverse server adapted from Ashok's example in his
book. The client can send any number of lines and it will send them back
over the channel string reversed.
As configured, there's a 10 second timeout if the client side leaves the socket open w/o sending anything new. It is set for 10 server tasks, and
0 time for simulated work (configurable at the top).
Each connection sends a progressively longer string of xyz's. The client
will run 500k connections if left running for many hours. Might need to control-c clients to kill them on linux. On windows, it opens a console.
Run both sides from a wish, server first or client(s) will abort. Can
then run multiple clients from separate terminal windows on same machine
or other machines.
The client presents a small window with an error count, progress count,
and pause checkbox. Client checks return for expected results. The
server also runs the task monitor task. Lower the refresh to .5 for best results. The result(s) column has the connection info; the user column
has the size and 20 chars of data. It's sending rather large lines >150k each. Can also monitor with wire-shark.
et
Hi,
would it be possible to post an network client/server code using tasks ?
best regards
Michael
Hi et,
many thanks for you client/server code sample with tasks, that's what i was looking for. I will try it out to understand the usage.
Michael
et4 wrote:
On 5/26/2022 12:10 PM, Michael Niehren wrote:
> Hi,
>
> would it be possible to post an network client/server code using tasks >> > ?
>
> best regards
> Michael
>
I believe I mistook your request for a question. I've uploaded to the
wiki page a client/server network example:
https://wiki.tcl-lang.org/page/Tasks
It's the last example on the wiki page.
There are 2 code blocks, one for each side. I tested it on windows and
linux but the first line of the server needs to be changed to point to
the path/to/ folder on either system of the tasks module location. The
very latest is at github, see the link in the first post here.
It is an echo/string-reverse server adapted from Ashok's example in his
book. The client can send any number of lines and it will send them back
over the channel string reversed.
As configured, there's a 10 second timeout if the client side leaves the
socket open w/o sending anything new. It is set for 10 server tasks, and
0 time for simulated work (configurable at the top).
Each connection sends a progressively longer string of xyz's. The client
will run 500k connections if left running for many hours. Might need to
control-c clients to kill them on linux. On windows, it opens a console.
Run both sides from a wish, server first or client(s) will abort. Can
then run multiple clients from separate terminal windows on same machine
or other machines.
The client presents a small window with an error count, progress count,
and pause checkbox. Client checks return for expected results. The
server also runs the task monitor task. Lower the refresh to .5 for best
results. The result(s) column has the connection info; the user column
has the size and 20 chars of data. It's sending rather large lines >150k
each. Can also monitor with wire-shark.
et
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 463 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 156:58:42 |
| Calls: | 9,384 |
| Calls today: | 4 |
| Files: | 13,561 |
| Messages: | 6,095,919 |