Re: after ids (Helmut Giese)

>Donal K. Fellows wrote
>While I could always see how to do it with single sets of timers, I
>could never work out how to do it reliably with multiple event
>sequences on different scales (e.g. a 13ms interval and a 1s interval)
>where the event processing takes an appreciable time w.r.t. the
>shorter intervals. Which happens for sure when using, say, Tk; redraws
>are quite expensive. With each pending timer event assigned an
>absolute time at which it becomes eligible for execution, it's pretty
>simple to handle. But without it...

Could well be, that I am way off of what is discussed here, but what I
understood seems rather easy to realize (at least on PC hardware).
Here's the idea:
Any reasonably recent PC hardware has a free running 64 bit timer
(sometimes called the Multi Media Timer) - since Pentium 1 IIRC.
There are 2 system calls:
- Query this timer's frequency (QueryPerformanceFrequency) and
- get its current count (QueryPerformanceCounter).

On startup Tcl would ask for the frequency and would once calculate the
number of timer ticks to a millisecond.
Now someone comes along and wants to be notified after 10 msec. Ok,
Tcl gets the current timer value, adds the appropriate value for 10 ms and
puts the timeout value into a list.
1 msec later someone else comes around and asks for a delay of 3 msec.
Tcl does the same and (this would be a micro-optimisation) orders the list, so
that the new event is placed _before_ the one from step 1.

At any moment when Tcl wants to check if any timer event has expired, it walks

Re: after ids

Donal K. Fellows wrote:
> OK, how do you work out how long until the next event fires without an
> absolute time source? For added bonus points, do so with arbitrary
> real-time delays between processing points and without extra threads.

Donal,

Many people here are unquestionably arguing from ignorance, but
I do suspect after some conversations with Alexandre Ferrieux
that they are onto something with wanting a distinction between
absolute and relative times.

Absolute time, as far as Tcl is concerned, is UTC with smoothing
(http://www.cl.cam.ac.uk/~mgk25/uts.txt). It advances monotonically
and (more or less) continuously, ticking at an uneven rate to
accommodate TAI-UTC differences and NTP corrections.  It *can*
be nonmonotonic or discontinuous in unusual circumstances, owing
to an act of God (a network outage causing too large an NTP jump
to recover by advancing or retarding clock frequency), an act
of the operator (adjusting system time by the wristwatch-and-
-eyeball method), or an Act of Congress (Daylight Saving Time,
on operating systems that use civil time as the reference).

Its reference on Unix-like systems is gettimeofday(); on Windows
systems its ultimate reference is the system clock returned
by GetSystemTimeAsFileTime, with additional precision provided
by interpolation using the performace counter.

Relative time is not something that Tcl currently recognises,
but perhaps should.  It is strictly monotonic and uniform;

Test case modularity

With the [chan pipe] patch and also with other, not-yet-TIPped stuff
of mine, I noticed that the checking of error messages in the test
suite is often made with strict string equality. This makes sense for
many messages which are likely frozen for eternity, but there is a
specific subpopulation which is more dynamic: messages enumerating
subcommands of an ensemble.

This means that every extension of an ensemble in the core needs
fixing test cases that are completely unrelated to the new subcommand:
tests expecting the message

    bad subcommand "foo": must be a, b, c, or d.

must be updated to check for

    bad subcommand "foo": must be a, b, c, d, or e.

Is there a good reason to do so ? Why not [regexp {^bad subcommand}] ?

-Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: GSoC ShlibMemLoad

> >> They all have only one actual function greet(). This function get pid
> >> of the process which calls it and tries to write it to stdout.
> >> libwrite_simple makes it in the easiest possible way: just uses one
> >> write sys call.
> >> libwrite_global makes it similarly, but a buffer is global now.
> >> libwrite_fun calls another function (fill_str to fill buffer with data)
> >> These three libraries seems to be working fine.
> >> The fourth library libprintf tries to make the same thing easier and
> >> use printf instead of write. Anyway, it does not work. I get a
> >> segmentation fault (the same happens when I substitute printf for any
> >> other functions from stdio.h like puts).
>
> >> I do not know what may be wrong but I will try to work on it. Maybe
> >> the problem is in function load_needed_objects(Obj_Entry *) which is
> >> called by elf_dlopen, but I still do not know why it works for the
> >> first three libraries. They use functions from unistd.h.
>
> >I can't say at the moment. It seems that you haven't committed all the
> >changes yet, so I have can't see what was done.
>
> >For example, it is not clear if you are using the OS dlsym() already, or
> >not.
>
> >Best guess I have right now, is that it might be that your non-working
> >library depends on some other library FOO instead of just libc. And while
> >libc symbols are present the FOO is not loaded (yet) and thus its symbols
> >are not present either?
>
> As far as I know printf function is in libc as well. I also tried to

Updating Tktest suite - GSoC project

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Failing test tcl 8.5.2 on Interix - confused

Hello all,
Some test fails in a x86_64 Interix 6.0 compile of tcl 8.5.2 release.

all.tcl: Total 24242  Passed 23170  Skipped 1055  Failed 17

Some of the test fails due to missing encodings.

While looking through the failed test there are some things I
don't understand:

--------------- get.test -------------------

test get-1.8 {Tcl_GetInt procedure} {testgetint longIs64bit} {
    list [catch {testgetint 18446744073709551614} msg] $msg
} {0 -2}
test get-1.9 {Tcl_GetInt procedure} {testgetint longIs64bit} {
    list [catch {testgetint +18446744073709551614} msg] $msg
} {0 -2}

-------------- test output ------------------

==== get-1.8 Tcl_GetInt procedure FAILED
==== Contents of test case:

    list [catch {testgetint 18446744073709551614} msg] $msg

---- Result was:
0 4294967294
---- Result should have been (exact matching):
0 -2
==== get-1.8 FAILED

==== get-1.9 Tcl_GetInt procedure FAILED
==== Contents of test case:

    list [catch {testgetint +18446744073709551614} msg] $msg

---- Result was:
0 4294967294
---- Result should have been (exact matching):
0 -2
==== get-1.9 FAILED

--------------------------------------------

It seems that 64=>32 bit conversion is not working
as expected.

Can anyone point me to where in the code I can check this?

Thanks
Jerker

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Future [exec] overhaul

On 7/2/08, Jeff Hobbs <jeffh@...> wrote:
> Donald G Porter wrote:
> > Jeff Hobbs wrote:
> >>    TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
> >>    http://tip.tcl.tk/304
> >
> > If this is already answered in the TIP, just point me back there.
> >
> > Hoping someone can summarize which items on the long list of
> > defects in [exec] get addressed by this, and which do not.
>
> I don't think it hits all the issues, but the "Additional Benefits"
> section does discuss some ramifications for [exec], as well as future
> work possibilities.  I don't think the TIP author should be accountable
> for covering things not dealt with (that would be a very, very long
> list).  ;)

Thanks Jeff.
Now since I have already thought about this, I may share a few ideas here :)
So I changed the subject.

In a future TIP I will propose a new, extended [exec] (all options are
still open as to the script API: [exec -extended], [exec -list],
[exec2], you name it...), with the following main targets:

 (1) Fix the impossibility to pass > < | etc. as isolated arguments.
This will be done by passing whole commands as sublists:

     exec2 {foo > <} | {bar | |}

 (2) Get rid of complicated legacy rules regarding the scope and
semantics of redirection. These include the csh-style >&, the
global-scope 2>, the special case 2>@1, and the recent -ignorestderr.
All this to be forgotten in favour of the clean, symmetric syntax of
the Bourne shell:

    [exec foo 2>@1] --> [exec2 foo 2>&1]
    [exec foo |& bar] --> [exec2 foo 2>&1 | bar]
    (impossible)       --> [exec2 foo 2>& $ch1 | bar 2>& $ch2]
    [exec foo 2>@ stderr] --> [exec2 foo]
    [exec -ignorestderr foo] --> [exec2 foo]

(notice that I chose >& instead of >@ for two reasons: (1) to mark the
Bourne Shell heritage and (2) to avoid too easy copy/paste confusions
with old [exec])

 (3) Generalize on unix to fds above 2 as in Bourne shell and as shown
in the TIP under section "Directions for future work":

    (impossible) --> [exec2 foo 3>& $ch1 | bar 4<& $ch2]

 (4) Give a means to get the exit status at the end of an [exec2 ...
&]. One possibility is a simple, synchronous [waitpid], assuming that
by listening to one of its output descriptors one is able to have a
reasonable notification of when a [waitpid] would not block for too
long (which would be defeated by a [close stdout] in the child). A
more advanced option is to create a pseudo-channel who would fire a
fileevent readable on SIGCHLD. A third one would be a
Tcl_AsyncMark-based script-level signal handler (for SIGCHLD among
others).

Thanks for any comments on these ideas.

-Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Tip 312

Hi,

I have updated the description of the tip and provided a new patch for it.

The dangerous 'link' command is now used only in the test suite as 
'testlinkarray'.

Please tell me your objections. Otherwise please call a vote.

Regards

rene

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

TIP #321: Add a tk::busy Command

 TIP #321: ADD A TK::BUSY COMMAND 
==================================
 Version:      $Revision: 1.1 $
 Author:       Jos Decoster <jos.decoster_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Thursday, 26 June 2008
 URL:          http://purl.org/tcl/tip/321.html
 WebEdit:      http://purl.org/tcl/tip/edit/321
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 The *blt::busy* commands can be used to make Tk widget busy, with all 
 user interaction blocked and the cursor can be changed to e.g. a clock. 
 This TIP proposes to add this useful feature to Tk. 

 RATIONALE 
===========

 BLT has a lot of very useful commands: *bgexec*, *busy*, *vector*, 
 *graph* widget, *barchart* widget, ... But getting BLT to work with the 
 latest releases of Tcl and Tk becomes more and more difficult. Some of 
 the problems I experienced are: 

     * internal Tk structures are mirrored 

     * interaction with xft fails, so Tk has to be build without xft 
       support 

     * the build process is different from the one used in Tcl and Tk 

 Discussions on CLT and #tcl indicated that extracting functionality 
 from BLT and add it to Tcl and Tk might be a good way to make the blt 
 commands available for every Tcl programmer. 

 This TIP proposes a way to add the blt::busy command to Tk, based on 
 the code as found in BLT2.4z and the code as found in busy.kit. While 
 adding the code to Tk, it was rewritten to use the Tcl_Obj interface 
 and the new option interface. 

 The name of this new Tk command as currently implemented is *tk::busy*. 
 Adding it as an option to the *grab* command might cause confusion as 
 the *tk::busy* command has the opposite functionality of the *grab* 
 command. It blocks all user interaction rather than redirecting it to 
 one widget. Another alternative is adding it to the ensemble of *tk* 
 commands (*tk appname*, *tk scaling*, *tk inactive*, ...). 

 SPECIFICATION 
===============

 The *tk::busy* command is an ensemble with a special feature that any 
 unrecognized subcommand that starts with a period is treated as an 
 invokation of the *hold* subcommand upon the widget with that name. 

 HOLD SUBCOMMAND 
-----------------

       *tk::busy* /window/ ?/option value/? 

       *tk::busy hold* /window/ ?/option value/? 

 Makes the widget window (and its descendants in the Tk window 
 hierarchy) busy. /Window/ must be a valid path name of a Tk widget. The 
 busy window is mapped the next time idle tasks are processed, and the 
 widget and its descendants will be blocked from user interactions. All 
 events in the widget window and its descendants are ignored. Normally 
 update should be called immediately afterward to insure that the hold 
 operation is in effect before the application starts its processing. 
 The following configuration options are valid: 

       *-cursor* /cursorName/  

 Specifies the cursor to be displayed when the widget is made busy. 
 CursorName can be in any form accepted by Tk_GetCursor. The default 
 cursor is watch. 

 FORGET SUBCOMMAND 
-------------------

       *tk::busy forget* /window/ 

 Releases resources allocated by the *tk::busy* command for /window/, 
 including the busy window. User events will again be received again by 
 window. Resources are also released when window is destroyed. /Window/ 
 must be the name of a widget specified in the *hold* operation, 
 otherwise an error is reported. 

 RELEASE SUBCOMMAND 
--------------------

       *tk::busy release* /window/ 

 Restores user interactions to the widget /window/ again. This differs 
 from the *forget* operation in that the busy window is not destroyed, 
 but simply unmapped. /Window/ must be the name of a widget specified in 
 a *hold* operation, otherwise an error is reported. 

 ISBUSY SUBCOMMAND 
-------------------

       *tk::busy isbusy* ?/pattern/? 

 Returns the pathnames of all widgets that are currently busy. If a 
 /pattern/ is given, the path names of busy widgets matching /pattern/ 
 are returned. 

 NAMES SUBCOMMAND 
------------------

       *tk::busy names* ?/pattern/? 

 Returns the pathnames of all widgets that have previously been made 
 busy (i.e. a busy window is allocated and associated with the widget). 
 It makes no difference if the window is currently busy or not. If a 
 /pattern/ is given, the path names of busy widgets matching /pattern/ 
 are returned. 

 STATUS SUBCOMMAND 
-------------------

       *tk::busy status* /window/ 

 Returns the busy status of a widget /window/. If /window/ presently can 
 not receive user interactions, 1 is returned, otherwise 0. 

 CONFIGURE SUBCOMMAND 
----------------------

       *tk::busy configure* /window/ ?/option/? ?/value .../? 

 Queries or modifies the *tk::busy* command configuration options for 
 /window/. /Window/ must be the path name of a widget previously made 
 busy by the *hold* operation. If no options are specified, a list 
 describing all of the available options for window (see 
 Tk_ConfigureInfo for information on the format of this list) is 
 returned. If /option/ is specified with no /value/, then the command 
 returns a list describing the one named option (this list will be 
 identical to the corresponding sublist of the value returned if no 
 option is specified). If one or more /option-value/ pairs are 
 specified, then the command modifies the given widget option(s) to have 
 the given value(s); in this case the command returns the empty string. 
 Option may have any of the values accepted by the hold operation. 

 Please note that the option database is referenced through window. For 
 example, if the widget .frame is to be made busy, the busy cursor can 
 be specified for it by either option command: 

           option add *frame.busyCursor gumby
           option add *Frame.BusyCursor gumby

 CGET SUBCOMMAND 
-----------------

       *tk::busy cget* /window option/ 

 Queries the *tk::busy* command configuration options for /window/. 
 /Window/ must be the path name of a widget previously made busy by the 
 *hold* operation. The command returns the present value of the 
 specified /option/. /Option/ may have any of the values accepted by the 
 *hold* operation. 

 REFERENCE IMPLEMENTATION 
==========================

 See SourceForge patch #1997907 
 [<URL:http://sf.net/tracker/?func=detail&aid=1997907&group_id=12997&atid=312997>]. 

 COMPATIBILITY 
===============

 Because the command as proposed above has the same interface and 
 behavior as the *blt::busy* command, replacing *blt::busy* with 
 *tk::busy* is all that's needed to switch to the Tk version of the busy 
 command. 

 ALTERNATIVES 
==============

 The busy command is available as starkit from 
 <URL:http://tcl.tk/starkits/busy.kit> 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Tcl/Tk 8.5.3 RELEASED

Tcl/Tk 8.5.3 Release Announcement
June 30, 2008

The Tcl Core Team is pleased to announce the 8.5.3 releases of the Tcl
dynamic language and the Tk toolkit.  This is the third patch release
of Tcl/Tk 8.5.  More details can be found below.  We would like to
express our gratitude to all those who submit bug reports and patches.
This information is invaluable in enabling us to identify and eliminate
problems in the core.

Where to get the new releases:
------------------------------

Tcl/Tk 8.5.3 sources are freely available as open source from the
Tcl Developer Xchange web site at:

         http://www.tcl.tk/software/tcltk/8.5.html

This web page also contains additional information about the releases,
including new features and notes about installing and compiling the
releases.  Sources are always available from the Tcl SourceForge
project's file distribution area:

         http://sourceforge.net/project/showfiles.php?group_id=10894

Binaries for most major platforms are available from:

         http://www.activestate.com/Tcl

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

         http://www.tcl.tk/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

Summary of Changes since Tcl/Tk 8.5.2:
--------------------------------------

The following were the main changes in Tcl/Tk 8.5.3.  A complete list
can be found in the changes file at the root of the source tree.  The
more complete ChangeLog is also included with each source release.  This
is a patch release, so it primarily included bug fixes and corrections
to erratic behavior.  Below are only the most notable changes.

   * Corrected unreliable [fcopy] callbacks and enabled bidirectional fcopy.

   * Support Tcl Module packages in a Safe Base interp.

   * Fixed [slave bgerror] to operate in slave, not master.

   * Fixed crash when a ttk::label gets width or height of zero.

   * Fixed crash in [chan postevent].

   * Fixed crash in [dict append].

   * Fixed crash in [glob -dir {} a].

   * Fixed crash in Tk_ParseArgv().

   * Fixed crash in a global [grab].

   * Fixed [tell] overflow on large files.

   * Fixed missing <Enter> events on canvas items.

   * Made Tk more robust when Tcl and Xlib disagree about system encoding.

   * Improved Solaris support for DTrace and 64 bit.

   * Fixed floating point rounding on Solaris/x86.

--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager
--

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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

TIP 304 CFV

Hello,

Apologies if I'm not entitled to a CFV as a non-TCT-member. You can
bite me in that case.
Still, I believe it is roughly the proper time for a vote on TIP 304,
aiming for 8.6a2 if accepted.
Brief summary/history:

TIP #304:
A Standalone [pipe] Primitive for Advanced Child IPC
http://www.tcl.tk/cgi-bin/tct/tip/304.html

It is basically stealing TclX's [pipe], bringing it to stock Tcl as [chan pipe].
This allows, among other things, to redirect separately stdout and
stderr from a child and use both programmatically, like [bgexec] does.
It also silences most of the need behind "TIP #301: Split
Bidirectional Channels For Half-Close", since it allows to close the
stdin of a child and still listen to its last words.

Reference implementation as [Patch 1978495]:
https://sourceforge.net/tracker/index.php?func=detail&aid=1978495&group_id=10894&atid=310894

The implementation is no rocket science. It is a minimal stylistic/API
readjustment of TclX's, which has withstood fire for years.
Notably, it leverages existing pipe machinery with its
obsolete-but-working worker threads and events under Windows. We have
a plan to iron this out eventually, but it is strictly orthogonal to
304 (as it will ease plain [open |] too and fix the awful
TerminateThread issues like in [Bug 1958930]).

As for the (small) history of this submission:
- Function naming following the consensus (Jeff+Donal+Joe 
- Public API (stubbed) as per Donal's advice
- Expanded doc a bit as suggested by Joe.

Thanks in advance to whoever wants to (and may) turn this into a
formal CFV with a deadline in [clock seconds] format 

-Alex

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php