• Combining event loop with reading file

    From Cecil Westerhof@21:1/5 to All on Mon Nov 22 15:51:25 2021
    One of the things from tcl I find nice is the event loop. There are
    several things I want to do every so often and it is very easy to put
    that in a single script. And when I want to add another that is a
    cinch.
    But I also open a process that generates every minute a line of
    output. This I have in another script. But it would be nicer if
    everything is in the same script.
    Is there a way that just like after executes a proc after a certain
    amount of time, a proc can be called when there is another line of
    output, so the other procs still can be executed when it is their
    time?

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Mon Nov 22 16:50:40 2021
    Am 22.11.2021 um 15:51 schrieb Cecil Westerhof:
    One of the things from tcl I find nice is the event loop. There are
    several things I want to do every so often and it is very easy to put
    that in a single script. And when I want to add another that is a
    cinch.
    But I also open a process that generates every minute a line of
    output. This I have in another script. But it would be nicer if
    everything is in the same script.
    Is there a way that just like after executes a proc after a certain
    amount of time, a proc can be called when there is another line of
    output, so the other procs still can be executed when it is their
    time?


    AFAIK, program open is event enabled.

    Sketch from brain:

    set h [open |...]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h readproc

    proc readproc {} {
    if {[catch { set line [read $::h] } Err]
    || [eof $::h]
    } {
    close $::h
    return
    }
    # ... process line
    }

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Mon Nov 22 16:58:38 2021
    * Harald Oehlmann <wortkarg2@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {

    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From briang@21:1/5 to Ralf Fassel on Mon Nov 22 13:56:30 2021
    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Tue Nov 23 09:31:32 2021
    Am 22.11.2021 um 22:56 schrieb briang:
    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator


    Wow, rocket science! To see the coroutine in action is really amazing!
    Thanks,
    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cecil Westerhof@21:1/5 to briang on Tue Nov 23 16:31:12 2021
    briang <bgriffinfortytwo@gmail.com> writes:

    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator

    It looks quit interesting, but I understand it only partly. Are there
    any good resources to learn about this?

    What needs external-reporter-generator to be?
    Do I see it correctly that I have to call background-reporter#1 with
    the needed parameters and then do a 'vwait forever'?

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From briang@21:1/5 to Cecil Westerhof on Tue Nov 23 08:15:19 2021
    On Tuesday, November 23, 2021 at 7:44:06 AM UTC-8, Cecil Westerhof wrote:
    briang <bgriffin...@gmail.com> writes:

    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator
    It looks quit interesting, but I understand it only partly. Are there
    any good resources to learn about this?

    Great questions Cecil!

    There have been several presentations at the US Tcl and Euro Tcl conferences over the years. You should be able to find the papers/presentations in the proceedings online. I cannot immediately recall the titles. I learned how to use them through
    practice, i.e., applying them wherever and whenever I could. Through trial and error I gained a lot of knowledge. :)


    What needs external-reporter-generator to be?

    This is a place holder for whatever external program/process is generating the periodic output. The coroutine will launch the program and then consume that program's output until the EOF, after which it will clean up and terminate itself (the coroutine.)

    Do I see it correctly that I have to call background-reporter#1 with
    the needed parameters and then do a 'vwait forever'?

    The initial [coroutine] call will evaluate the function and return when the function executes the first [yield] or [return] command. After that, the assumption is that there is an overall event wait loop running. This is the base assumption for all Tk
    programs, for example. Non-Tk tcl programs can operate that way as well. It is best if there is only 1 [vwait forever], instead of having point [vwait ...] sprinkled throughout the code.

    -Brian

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ted brown@21:1/5 to Cecil Westerhof on Tue Nov 23 10:53:49 2021
    On 11/22/2021 6:51 AM, Cecil Westerhof wrote:

    But I also open a process that generates every minute a line of
    output. This I have in another script. But it would be nicer if
    everything is in the same script.


    If your goal is simply to reduce the number of script *files* by having
    all your code in the same file, and you are comfortable using separate processes, you can easily combine several "scripts" into a single file
    using different command lines to select which script you want, using

    ::argv

    You might also use

    [info nameofexecutable]

    to avoid hard-coding the tclsh or wish path when you [exec] the other script(s). And you might also use

    ::argv0

    to retrieve the name of the script.

    If you want to avoid separate processes as well, you could use a
    separate thread instead of separate processes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cecil Westerhof@21:1/5 to briang on Tue Nov 23 19:45:38 2021
    briang <bgriffinfortytwo@gmail.com> writes:

    On Tuesday, November 23, 2021 at 7:44:06 AM UTC-8, Cecil Westerhof wrote:
    briang <bgriffin...@gmail.com> writes:

    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator
    It looks quit interesting, but I understand it only partly. Are there
    any good resources to learn about this?

    Great questions Cecil!

    There have been several presentations at the US Tcl and Euro Tcl
    conferences over the years. You should be able to find the papers/presentations in the proceedings online. I cannot immediately
    recall the titles. I learned how to use them through practice, i.e.,
    applying them wherever and whenever I could. Through trial and error I
    gained a lot of knowledge. :)

    I did find a few YouTube Tcl conferences videos about coroutines, but
    nothing that helped me. :'-(


    When I have it working I probably should post something.


    What needs external-reporter-generator to be?

    This is a place holder for whatever external program/process is
    generating the periodic output. The coroutine will launch the program
    and then consume that program's output until the EOF, after which it
    will clean up and terminate itself (the coroutine.)

    I probably do misunderstand something, but is the process behind
    filepointer h not generating the output?

    And here the placeholder (at the end of the page) is not used:
    https://wiki.tcl-lang.org/page/Coronet


    Do I see it correctly that I have to call background-reporter#1 with
    the needed parameters and then do a 'vwait forever'?

    The initial [coroutine] call will evaluate the function and return when
    the function executes the first [yield] or [return] command. After that,
    the assumption is that there is an overall event wait loop running. This
    is the base assumption for all Tk programs, for example. Non-Tk tcl
    programs can operate that way as well. It is best if there is only 1
    [vwait forever], instead of having point [vwait ...] sprinkled
    throughout the code.

    I use a (single) vwait in a systemd process where I want to log
    several different things. That part work great. Just want to integrate
    the consume of a process with it.

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From briang@21:1/5 to Cecil Westerhof on Tue Nov 23 12:53:54 2021
    On Tuesday, November 23, 2021 at 10:59:05 AM UTC-8, Cecil Westerhof wrote:
    briang <bgriffin...@gmail.com> writes:

    On Tuesday, November 23, 2021 at 7:44:06 AM UTC-8, Cecil Westerhof wrote:
    briang <bgriffin...@gmail.com> writes:

    On Monday, November 22, 2021 at 7:58:43 AM UTC-8, Ralf Fassel wrote:
    * Harald Oehlmann <wort...@yahoo.de>
    | Sketch from brain:

    | set h [open |...]
    | fconfigure $h -blocking 0 -buffering line
    | fileevent readable $h readproc

    | proc readproc {} {
    Better yet w/o globals and hardcoded file descriptors:

    fileevent readable $h [list readproc $h]
    proc readproc {fd} {
    read $fd
    eof $fd
    ...
    }

    R'

    Don't need any proc either:

    coroutine background-reporter#1 apply {{cmd args} {
    set h [open "| $cmd $args"]
    fconfigure $h -blocking 0 -buffering line
    fileevent readable $h [info coroutine]
    while { ! [eof $h]} {
    yield
    read $h line
    puts $line
    }
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    }} external-reporter-generator
    It looks quit interesting, but I understand it only partly. Are there
    any good resources to learn about this?

    Great questions Cecil!

    There have been several presentations at the US Tcl and Euro Tcl conferences over the years. You should be able to find the papers/presentations in the proceedings online. I cannot immediately
    recall the titles. I learned how to use them through practice, i.e., applying them wherever and whenever I could. Through trial and error I gained a lot of knowledge. :)
    I did find a few YouTube Tcl conferences videos about coroutines, but
    nothing that helped me. :'-(

    This is what I found so far. Note: the term "coro" is often used in discussions, so I used that in my search.

    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2008/proceedings/nre/coroSlides.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2008/proceedings/nre/tailSlides.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/SeanWood/Agent-Based-Modeling-with-Coroutines.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2012/SeanWoods/Lifecycle-of-Objects.pdf
    https://ssl.webpack.de/www.eurotcl.tcl3d.org/presentations/EuroTcl2019-Macleod-ExpectCoroutines.pdf
    https://youtu.be/WGYl0LiPv80 https://www.magicsplat.com/blog/coro-iterate/index.html

    https://wiki.tcl-lang.org/page/Tcl+Conferences




    When I have it working I probably should post something.
    What needs external-reporter-generator to be?

    This is a place holder for whatever external program/process is
    generating the periodic output. The coroutine will launch the program
    and then consume that program's output until the EOF, after which it
    will clean up and terminate itself (the coroutine.)
    I probably do misunderstand something, but is the process behind
    filepointer h not generating the output?

    Yes, that is correct. The [open] call in prior examples used "|...". I simply named the "..." as "$cmd $args", and the example call passes the argument "external-reporter-generator" as the cmd argument.


    And here the placeholder (at the end of the page) is not used: https://wiki.tcl-lang.org/page/Coronet

    In the Coronet example, the apply function has no argument: apply {{} {...
    In my example, the apply has 2 arguments: apply {{cmd args} {...


    Do I see it correctly that I have to call background-reporter#1 with
    the needed parameters and then do a 'vwait forever'?

    The initial [coroutine] call will evaluate the function and return when
    the function executes the first [yield] or [return] command. After that, the assumption is that there is an overall event wait loop running. This
    is the base assumption for all Tk programs, for example. Non-Tk tcl programs can operate that way as well. It is best if there is only 1
    [vwait forever], instead of having point [vwait ...] sprinkled
    throughout the code.
    I use a (single) vwait in a systemd process where I want to log
    several different things. That part work great. Just want to integrate
    the consume of a process with it.

    Well, without actual code, it's hard for me to understand the intended behavior and the flow.

    -Brian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ted brown@21:1/5 to Cecil Westerhof on Tue Nov 23 14:22:09 2021
    On 11/23/2021 10:45 AM, Cecil Westerhof wrote:


    I did find a few YouTube Tcl conferences videos about coroutines, but
    nothing that helped me. :'-(


    For all things tcl, I highly recommend Ashok's Tcl book:

    https://www.magicsplat.com/ttpl/index.html

    It has everything on co-routines, threads, events, etc. and it is up to
    date.

    I bought the pdf version, great for searching and copy/paste of the
    examples.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cecil Westerhof@21:1/5 to briang on Wed Nov 24 16:23:59 2021
    briang <bgriffinfortytwo@gmail.com> writes:

    It looks quit interesting, but I understand it only partly. Are there
    any good resources to learn about this?

    Great questions Cecil!

    There have been several presentations at the US Tcl and Euro Tcl
    conferences over the years. You should be able to find the
    papers/presentations in the proceedings online. I cannot immediately
    recall the titles. I learned how to use them through practice, i.e.,
    applying them wherever and whenever I could. Through trial and error I
    gained a lot of knowledge. :)
    I did find a few YouTube Tcl conferences videos about coroutines, but
    nothing that helped me. :'-(

    This is what I found so far. Note: the term "coro" is often used in discussions, so I used that in my search.

    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2008/proceedings/nre/coroSlides.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2008/proceedings/nre/tailSlides.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/SeanWood/Agent-Based-Modeling-with-Coroutines.pdf
    http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2012/SeanWoods/Lifecycle-of-Objects.pdf
    https://ssl.webpack.de/www.eurotcl.tcl3d.org/presentations/EuroTcl2019-Macleod-ExpectCoroutines.pdf
    https://youtu.be/WGYl0LiPv80 https://www.magicsplat.com/blog/coro-iterate/index.html

    https://wiki.tcl-lang.org/page/Tcl+Conferences

    I am going to look into those. Thanks.


    When I have it working I probably should post something.
    What needs external-reporter-generator to be?

    This is a place holder for whatever external program/process is
    generating the periodic output. The coroutine will launch the program
    and then consume that program's output until the EOF, after which it
    will clean up and terminate itself (the coroutine.)
    I probably do misunderstand something, but is the process behind
    filepointer h not generating the output?

    Yes, that is correct. The [open] call in prior examples used "|...". I
    simply named the "..." as "$cmd $args", and the example call passes the argument "external-reporter-generator" as the cmd argument.

    Ah, I am starting to understand what happens.


    And here the placeholder (at the end of the page) is not used:
    https://wiki.tcl-lang.org/page/Coronet

    In the Coronet example, the apply function has no argument: apply {{} {... In my example, the apply has 2 arguments: apply {{cmd args} {...

    When you know it, it is so obvious.


    Do I see it correctly that I have to call background-reporter#1 with
    the needed parameters and then do a 'vwait forever'?

    The initial [coroutine] call will evaluate the function and return when
    the function executes the first [yield] or [return] command. After that, >> > the assumption is that there is an overall event wait loop running. This >> > is the base assumption for all Tk programs, for example. Non-Tk tcl
    programs can operate that way as well. It is best if there is only 1
    [vwait forever], instead of having point [vwait ...] sprinkled
    throughout the code.
    I use a (single) vwait in a systemd process where I want to log
    several different things. That part work great. Just want to integrate
    the consume of a process with it.

    Well, without actual code, it's hard for me to understand the
    intended behavior and the flow.

    I think I get it now, but this is what is happening now.
    I have a program that ends with the following:
    init
    after [getWaitNextDayTicks] checkDatabaseIntegrity
    after [getWaitMinutesTicks ${intervalCheckpoint}] doCheckpoint
    after [getWaitMinutesTicks ${intervalCPU}] storeCPUTemp
    after [getWaitMinutesTicks ${intervalInternet}] storeInternetConnection
    after [getWaitMinutesTicks ${intervalSwap}] storeSwap
    startEventLoop
    # Not really necessary because the eventloop never terminates
    # But I find this more clear and it is robuster against change
    deinit

    In the end of the proc's there is the same call as what called the
    proc. The getWait… procs are part of my library.
    Once a day the database integrity is checked.
    Every hour a checkpoint is done on the database and the swap usage is
    stored.
    And every minute I store the CPU temperature and the quality of the
    internet connection.
    Because the way tclsh works it is a cinch to add the functionality for
    storing every quarter the internet speed.

    Because reading from a file pointer was until now blocking, I did
    storing of vmstat information in a different script. But I think I
    will be able to add that to this script now.


    Thanks.

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cecil Westerhof@21:1/5 to Cecil Westerhof on Wed Nov 24 16:54:53 2021
    Cecil Westerhof <Cecil@decebal.nl> writes:

    One of the things from tcl I find nice is the event loop. There are
    several things I want to do every so often and it is very easy to put
    that in a single script. And when I want to add another that is a
    cinch.
    But I also open a process that generates every minute a line of
    output. This I have in another script. But it would be nicer if
    everything is in the same script.
    Is there a way that just like after executes a proc after a certain
    amount of time, a proc can be called when there is another line of
    output, so the other procs still can be executed when it is their
    time?

    With the help of Brian I got it working. It was not that difficult.
    :-D

    I have the following code:
    #!/usr/bin/env tclsh


    package require dcblUtilities

    namespace import \
    ::dcblUtilities::getWaitSecondsTicks \
    ::dcblUtilities::showMessage \
    ::dcblUtilities::startEventLoop


    set intervalMessage 12


    proc giveMessage {} {
    showMessage "Another one" True
    after [getWaitSecondsTicks ${::intervalMessage}] giveMessage
    }

    proc startVmstatLogging {} {
    showMessage "Entering vmstat logging" True
    coroutine background-reporter#1 apply {{} {
    showMessage "Opening" True
    set h [open "|vmstat -n -S M -t 60 5" RDONLY]
    # The first three lines need to be skipped
    # First two are header, third is average
    for {set i 0} {${i} < 3} {incr i} {
    gets $h
    }
    fconfigure $h -blocking 0 -buffering line
    fileevent $h readable [info coroutine]
    while { ! [eof $h]} {
    yield
    gets $h line
    showMessage [string range $line 0 25] True
    }
    showMessage "Closing" True
    if {[catch {close $h} err]} {
    puts stderr $err
    }
    startVmstatLogging
    }}
    showMessage "Leaving vmstat logging" True
    }


    startVmstatLogging
    after [getWaitSecondsTicks ${intervalMessage}] giveMessage
    startEventLoop
    # Not really necessary because the eventloop never terminates
    # But I find this more clear and it is robuster against change
    deinit

    And when I run that I get:
    16:42:03: Entering vmstat logging
    16:42:03: Opening
    16:42:03: Leaving vmstat logging
    16:42:12: Another one
    16:42:24: Another one
    16:42:36: Another one
    16:42:48: Another one
    16:43:00: Another one
    16:43:03: 1 0 2207 2650 1178
    16:43:12: Another one
    16:43:24: Another one
    16:43:36: Another one
    16:43:48: Another one
    16:44:00: Another one
    16:44:03: 0 0 2207 2641 1178
    16:44:12: Another one
    16:44:24: Another one
    16:44:36: Another one
    16:44:48: Another one
    16:45:00: Another one
    16:45:03: 1 0 2207 2644 1179
    16:45:12: Another one
    16:45:24: Another one
    16:45:36: Another one
    16:45:48: Another one
    16:46:00: Another one
    16:46:03: 2 0 2207 2626 1179
    16:46:03:
    16:46:03: Closing
    16:46:03: Entering vmstat logging
    16:46:03: Opening
    16:46:03: Leaving vmstat logging
    16:46:12: Another one
    16:46:24: Another one
    16:46:36: Another one
    16:46:48: Another one
    16:47:00: Another one
    16:47:03: 2 0 2207 2597 1179
    16:47:12: Another one
    16:47:24: Another one
    16:47:36: Another one
    16:47:48: Another one
    16:48:00: Another one
    16:48:03: 2 0 2207 2592 1180
    16:48:12: Another one

    --
    Cecil Westerhof
    Senior Software Engineer
    LinkedIn: http://www.linkedin.com/in/cecilwesterhof

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)