gmane.comp.lang.tcl.core

Re: Coroutines in HEAD

miguel sofer — 2008-08-28T23:37:56

Nope - if someone wanted to make things work according to that scenario, my coroutines will not support her. It would be "Overly Cool" but it does not seem likely to happen anytime soon. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Alexandre Ferrieux — 2008-08-28T23:28:23

Oh, so you want to pack a full coro's context (including an army of globals) into serialized form and make it migrate to the random thread chosen, instead of just waking up the proper thread after a simple lookup ? Either you're kidding or I'm missing something elephant-size... -Alex ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Alexandre Ferrieux — 2008-08-28T23:23:26

Indeed. See: http://groups.google.com/group/comp.lang.tcl/tree/browse_frm/thread/7244a14c3a82b090/cd94a2dff6910b36?hl=en&rnum=1&q=in+head&_done=%2Fgroup%2Fcomp.lang.tcl%2Fbrowse_frm%2Fthread%2F7244a14c3a82b090%2F2361d9dc487bd8d9%3Fhl%3Den%26lnk%3Dgst%26q%3Din%2Bhead%26#doc_4244d504a9b42828 Yeah, I'm impatient to know what. That is true but does not shed light on the *need* for [suspend/resume] instead of [coroutine]: Classical event-driven style imposes non-contiguous code, while both [coroutine] and your approach allow for straightforward style -- this doesn't break the tie. So, if you have no personal interest in serialized continuations *and* just want the linear style that [coroutine] already provides, what's the point ? -Alex ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

miguel sofer — 2008-08-28T23:11:01

Scenario: webserver on a multicore cpu, one-coroutine-per-session. Ie, maintain session state in the coro's local vars (as opposed to hitting a database or something equivalent). The way it is today, you may run as many threads as you have cores (or a bit more), and allocate user sessions to the threads on creation in order to balance the load. But once created, a session has to be resumed in the same thread each time a new request comes in. If the coros could be resumed in any thread, you could balance your load dynamically - each time a request comes in. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tcl-Core mailing list Tcl-Core< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: Coroutines in HEAD

Lars Hellström — 2008-08-28T23:04:41

Alexandre Ferrieux skrev: Oh, I've been busy with improving the proof-of-concept implementation (just used it to implement an oracle for a nondeterministic graph-colouring algorithm, but it's too late to put that on the Wiki tonight). Essentially, that is "keeping a GUI alive during a long-running computation". Suppose for example that you want to show some kind of animation. A very basic approach for doing this is foreach frame $animation { show_frame $frame after $frame_period } but this doesn't work in Tcl/Tk, since we never run the event loop. It can however be made to work if the [after] is replaced by an [after]-[vwait] combination: set ::tick 0 foreach frame $animation { show_frame $frame after $frame_period {incr ::tick} vwait ::tick } Not only is the display updated, but furthermore the GUI is alive. There is however a serious limitation with this approach -- it only lets you run one such animation at a time, because [vwait]s nest; if you start a second such command when in the [vwait] of the first, then the first animation freezes until the second has run to end. With my design, and provided a suitable TCL_SUSPEND handler is installed in [bgerror], the above could have been coded as foreach frame $animation { show_frame $frame suspend after $frame_period } without blocking, and keeping the GUI alive. This would work as follows: the TCL_SUSPEND handler looks at what was the first argument of [suspend], and interprets it as a sort of subcommand. In this case it is "after", so the continuation should simply be resumed after a specified length of time. Practically this would amount to the handler doing after [lindex $continuation 1] [list resume $continuation] ([lindex $continuation 1] being the $frame_period from above). That much can be done with the NRE [coroutine] too -- however it turned out that the basic [suspend] and [resume] primitives I came up with to solve the above problem could also do a lot more than this. And the basic problem of running multiple animations simultaneously can of course be handled with only Tcl/Tk 8.5 features, as is the case with anything that [coroutine] lets you do AFAICT, but this may require you to restructure your code in a rather unintelligible way. I have no idea why that should be cool -- Miguel had however mentioned it as something the NRE [coroutine]s cannot do, so I thought it worth pointing out that you get it for free with [suspend]/[resume]. Maybe he can elaborate on the usefulness of this however. Lars Hellström ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Alexandre Ferrieux — 2008-08-28T22:12:46

Lars, I'd really appreciate your answer to this. Regards, -Alex On 8/27/08, Alexandre Ferrieux public.gmane.org> wrote: ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

miguel sofer — 2008-08-28T11:21:36

Not so, NRE does not separate the per-coroutine execution environment when [yield] is called. Those execEnvs are born separate, that's the main job of the [coroutine] command. The generated command for the coroutine just swaps the coroutine's execEnv into the interp (swapping a couple of pointers), registers a callback to swap back the original exexcEnv on return, and runs. Later [yield] saves the relevant pointers into a CoroutineData struct and returns, letting the callback restore the caller's environment. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tcl-Core mailing list Tcl-Core< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: Coroutines in HEAD

Lars Hellström — 2008-08-28T11:07:30

Neil Madden skrev: Did that come out backwards? The NRE coroutines doesn't seem to be first-class objects, but I can imagine coroutines elsewhere as a rule being first-class. First point sounds plausible. Please elaborate the second point (perhaps off-list, if you think it is too off-topic). Ultimately, we may always fall back to what is written on the tape of our Turing machine. :-) More practically, also the NRE has to separate the per-coroutine state from the general interpreter state, and IMHO that is where you might encounter nontrivial issues. The rest should just be the hard work of serializing a well-defined data structure. It's certainly possible to live with, but I can't help finding the need for this temporary command rather ugly. Then again, I find most APIs that create objects to keep track of pure data ugly too. The difference is that threads and interps (at least if you're running the event loop) have an internal state that can mutate while you're not looking. Coroutines are (I hope) immutable when they're not running. Remember that we have Tcl_Objs, and can stash data in the internal representation. The string rep wouldn't normally be generated, it is sufficient that it can be. That said, it is probably not possible to make [suspend] as fast as [yield], but it is also more general. There was a detail missing from my sketch: the continuation must record what command the resumption is to begin with; sorry about that. A proof-of-concept implementation of [suspend] and [resume] can be found at http://wiki.tcl.tk/21538. Lars Hellström ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Joe English — 2008-08-28T20:40:24

Lars Hellstrom wrote: As noted earlier, active coroutines have state; therefore their string rep must be a handle, not a value. And since the main thing you can do with an active coroutine is call it, using a Tcl command name for the handle seems eminently sensible to me. --Joe English jenglish-BD/dr091N2xF6kxbq+BtvQ< at >public.gmane.org ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

please vote tip 312

Rene Zaumseil — 2008-08-28T18:59:11

Hello, please call a vote for tip 312. Reference implementation could go in 8.6 and 8.5. Thank you rene ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Neil Madden — 2008-08-28T13:42:23

First-class as in you can pass them to/from commands etc. You can do that with coroutines -- just pass the command name. Generator functions, as I understand it, have no per-instance command or object, so you can't pass them around. Instead, the creation and use of an instance is all captured within some iteration-like construct. These are rather fuzzy terms though (e.g. Python's generators are first-class). An escape continuation can only be used to escape back up the stack, like an exception. You can't use them to jump back to a point further down the stack that has already unwound. Looking at your proposal in more detail, I can see that [resume] is more than this. However, it's still not clear how you would implement e.g. call/cc in this proposal. (See the history of my wiki page for an example of call/cc implemented with coroutines). Well, a programming language interpreter usually goes beyond what is considered by a Turing machine -- I/O for one example. That is (a) a lot of hard work, and (b) to be at all efficient is probably going to involve serialising a lot of implementation details. In purely aesthetic terms, I too would like to have a pure value representation. In practical terms, I can live with the opaque command. What state of a thread is mutated when it is not running? Threads and coroutines are really quite similar. I don't see any evidence for this claim. Coroutines are extremely general, as demonstrated in the Lua paper that Miguel has linked to before. I still find it difficult to follow this and relate it to an eventual implementation of Tcl in these terms. A proof of concept would be something like the event-loop example given for coroutines, showing how a normal set of Tcl procs can be suspended and resumed to perform a concrete task. I mean, if we are allowed to transform the code completely, then we may as well put everything in CPS form.

Re: Coroutines in HEAD

miguel sofer — 2008-08-28T11:34:16

Much flattered :) But ... what I may yet do before hell freezes over is running the same kind of coroutines in a slightly different way: they now run in [uplevel #0], I think I know how to let them "remember" the complete call stack at creation so that [upvar] and [uplevel] keep functioning even if the coroutine's creator has already returned. That is, so that the complete environment at creation time is captured - a real closure. What I do *not* know (yet?) how to do properly is to marry that approach with correct functioning of [info level], [info frame] and error stacks. Access to the resumer's environment via [uplevel] and [upvar] would still be barred, or else require some new mechanism if the need is felt. Note that today's coroutine make it look (for [info frame] and error stacks) as if whoever resumed a coroutine actually called the coroutine's body from the beginning. What should it look like for a continuation (let us call them that)? IOW, I am more worried about the proper semantics than the implementation, which is a SMOP (famous last words). ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Tcl/Tk 8.6 feature freeze and b1 release schedule

Donald G Porter — 2008-08-27T21:00:59

My aim is to get Tcl/Tk 8.6b1 released in source code form in time for an 8.6b1-based ActiveTcl to be distributed at the conference. After discussing with the Activators, I've set the target release date as Friday, October 10, 2008. If there are TIPs or new-features-yet-to-be-TIPped that someone wants to argue need to be part of Tcl/Tk 8.6 and those features cannot be completed by October 10, now is the time to make the case that we should delay feature freeze. What should we wait for, and why, and how long? Unless someone speaks up on that point, I'll proceed on the Oct. 10 release plan for Tcl/Tk 8.6b1, and everyone with TIPs that they do think can be done by then should proceed getting them done by then. Please use TIP 311 to indicate your plans. Thanks all.

Re: Coroutines in HEAD

Lars Hellström — 2008-08-27T14:01:30

miguel sofer skrev: Wrong -- each level of Tcl_Eval* around the [suspend] contributes another element to the continuation (kept in interp's objResultPtr, which is a list). When a command's /resumeProc/ determines that "my internal state is that I had just called X", then it should complete its resumption by calling Tcl_ResumeObjEx(interp, objPtr, flags, resumeIdx-1, resumeData) to have also that command resume itself (which will then Tcl_ResumeObjEx whatever it had called, recursively up to the [suspend]). If the command X is a procedure, then (AFAICT) the /proc/ of it is TclObjInterpProc, so is suppose the /resumeProc/ would be some TclObjInterpResumeProc. In proc nest1 {} { A suspend B } proc nest2 {} {nest1} proc nest3 {cont} { C resume $cont D } catch {nest2} res opt here E nest3 $res the single letter commands are evaluated in the order: A, E, C, B, D. A and B both agree (when consulting [info level] or [info frame]) they're being called from [nest1], which in turn is called from [nest2]. They don't agree about [nest3], which is seen on the call stack by B but not by A. That would be the value specified in the [resume]. In the above case (no value specified) it defaults to the empty string (as with [return]). This value is placed there by the resumeProc of the [suspend] command, which finds it in resumeData[0]. [snip] No, one shouldn't serialize ::, or any other namespace for that matter; command redefinitions should take effect. Consider proc A {} { B C B } If C redefines B, then the second B in A does something different than the first did. It shouldn't make a difference whether C redefines B by an explicit [proc], by [yield]ing for a while and letting some other part of the program do the redefinition, or by [suspend]ing itself while some other part of the program redefines B. However, it is similarly true that redefinitions of A while inside C should not change the effective body of that A being evaluated. From this follows that the /resumeData/ for a [proc] will probably need to contain the definition of that proc which was in force when it was called (which, BTW, need not be the same as was in force at the time of [suspend]), perhaps in the form of a lambda. More generally, it is a problem of this scheme that a command being resumed need not be the same as the command that was suspended; the original command might have been renamed, or completely deleted, and something quite different might have been put in its place. Still, I think the sensible thing to do is to call the /resumeProc/ of the command of the right name which exists at the time of resumption, and then have this /resumeProc/ throw an error if the /resumeData/ entry does not make sense for it. This would allow replacing a proc by another proc (same /resumeProc/, and all other details of current definition are ignored), and also resuming a command which by some higher level item (higher /resumeIdx/ value) was first destroyed at suspend-time and then recreated at resume-time. This is thus a "sharp tool, you may cut yourself" situation, but the worst that can happen is that you get an error. It requires consistent methods of encoding /resumeData/ elements, yes. For a proc, there's quite a lot of state that would need to be preserved -- body, local variables and their values (should be possible to roll up as a dict), current position in body (perhaps character offset is sufficient for this?), [upvar]ing of variables, [trace]s on variables, and probably plenty of other obscure details I'm unfamiliar with -- but I see no reason why it shouldn't be doable. (Whether it is ultimately *worth* doing, especially now that NRE has been done, is another matter. See below.) When it comes to extension-defined commands, I actually think things would often be fairly straightforward, with rather few instances where "serializing pointers" should seem like the natural way forward. Take the TclX [scanfile] command, for an example. Besides argument parsing, it does most of its work in the ScanFile function. That contains exactly two Tcl_EvalObj calls, so there are only two places in which this command might need to be resumed; all other state is in the local variables. Most of these are simple integers or strings: Tcl_DString lineBuf, uniLineBuf; int result, matchedAtLeastOne; scanData_t data; int matchStat; (although several are bundled into a scanData_t struct: typedef struct { int storedLine; scanContext_t *contextPtr; Tcl_Channel channel; char *line; Tcl_UniChar *uniLine; int uniLineLen; off_t offset; long bytesRead; long lineNum; matchDef_t *matchPtr; } scanData_t; ), and a few (/contextPtr/ and /channel/) can be looked up from the arguments [scanfile] was called with. The only thing which is not immediately serializable is the /matchPtr/, which points to the current item in a linked list. This can however be encoded as the index into this list, so [scanfile] could easily record its internal state in a dict, and thereby avoid introducing a custom Tcl_ObjType. It's a bit of work, but not incomparable to the work of rewriting [scanfile] to take advantage of NRE. That's not something I'm interested in. Is it even feasible to try to make the distinction? (I.e., determine whether we are to error out because of being non-functional?) [snip] Well... Back in 2005 when I started thinking about [suspend]/[resume], I think the general opinion (at least in the discussion which prompted the whole thing) was that something like NRE could not be done with reasonable expense either. ;-) [snip] Yes, Neil has demonstrated (http://wiki.tcl.tk/21532) how to basically do the motivating [suspend vwait] using coroutines, so the elementary functionality is covered by both; I stand partly corrected on that point. Intervention, duplication, and continuation modification are however features of [suspend]/[resume] that remain unattained by NRE. [snip] Realistically: I don't expect to actually implement these things -- I know I wouldn't be able to produce all the LOC it would take. What I primarily expect to come out of this is instead a sharpening of NRE: if the [suspend]/[resume] primitives can be shown to do X, or handle situation Y in a nice way, then there is an incentive for NRE to manage that too (even if in a completely different way). A little competition can spur significant improvements, even if that competition is only against a cardboard cut-out. That [suspend] and [resume] as sketched here should make it into the core is not so likely, but they remain as a possibility, should it in the future be felt that the "no recursion" condition to be [yield]able is too onerous or incomprehensible. Yes. I believe this was stated already in my original posting. Not block, but throw an error, since it would be an error to try to suspend something which is not resumable (just like NRE has it be an error to [yield] where there has been recursion -- there could be a difference as to where this error is first thrown, though: not in the [suspend], but when TCL_SUSPEND hits the unresumable command). I wrote about having Tcl_Eval* check that commands returning TCL_SUSPEND also have a /resumeProc/, did I not? Lars Hellström ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tcl-Core mailing list Tcl-Core< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: Coroutines in HEAD

Alexandre Ferrieux — 2008-08-27T09:20:42

Hello, On Sun, Aug 24, 2008 at 10:02 PM, Lars Hellström public.gmane.org> wrote: Lars, aside from the discussion on the How, I'd like a bit more on the Why. Specifically, I fail to map your "basic premise" example onto a realistic engineering need. Also, from time to time people hint at the fact that passing a continuation or coroutine across the thread/interp boundary would be Overly Cool, but again I'd like a few examples of what real problems this would solve. Notice that here I'm not concentrating on the coroutine/continuation difference. One motivation is that I predict that the free-floating (as in "unordered") refcounted "stack" frames will be teleported from Miguel's mind to silicon in no time (considering the timescale of the 8.5 release ;-). So basically I assume that today's anchoring of coroutine-sequels to the toplevel won't last long enough to be called a limitation of the model ! -Alex ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Donal K. Fellows — 2008-08-27T06:16:05

[...] Actually, it won't (assuming [catch] is NRE-aware). The transaction subcommand is part of the scripted layer of TDBC. (It's built on lower-level stuff that handles starting and finishing the transaction, but they aren't reentrant anyway.) Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Neil Madden — 2008-08-27T01:12:06

On 24 Aug 2008, at 21:02, Lars Hellström wrote: It's an interesting idea whether the Tcl main program should itself be a coroutine. That would give a possibly useful semantics to [yield] called from outside of any explicit coroutine -- it would yield to the event loop (i.e. much like an [update], but capable of returning a value). The use of coroutines shown in http://wiki.tcl.tk/ 21532 depends on the "main" procedure being a coroutine, so you can suspend/resume the entire program. This allows for very much continuation-like behaviour to be achieved. In practice, I leaving it as-is works better. Similar, yes, although generators are not usually first-class objects. The scheme you have described sounds like an implementation of "escape continuations" -- i.e. continuations which act like exceptions. Such continuations are strictly less powerful than either full continuations or coroutines, IIRC. The opaque handle nature of coroutines is, I think, acceptable in this case. A coroutine encapsulates rather a complex chunk of interpreter state, so a string representation would be tricky to concoct (but perhaps not impossible). That state also changes every time the coroutine is invoked. The fact that coroutines automatically clean-up the command when they are "exhausted" also seems to reduce any difficulties with an opaque naming scheme. Creating uniquely- named coroutines in a special namespace (such as on the wiki page I linked above) will be mostly good enough. The case it misses is where a coroutine is created and then discarded before it has been allowed to run to completion. In this case an explicit clean-up would be needed. While I agree with the sentiment that it would be nice to have Tcl_Obj based representation of coroutines or some form of continuation, I think in practice it would be a lot of work for perhaps not a huge amount of gain. Opaque works for threads and interps; I think it will suffice for coroutines too. Without a more thorough understanding of how suspend/resume are to work, I can't assess whether that really works or not (and thus whether suspend/resume offer more than escape continuations). I would guess it is at least much slower than the coroutine equivalent, having to save/restore command invocations from string reps. Note that this is already possible with the event loop -- e.g., a vwait inside the transaction can cause the same effect. Don't Do That! How does a Tcl proc get to restore itself on a [resume]? I don't really follow how [resume] works at all, to be honest.

TIP #325: System Tray Access

David N. Welton — 2008-08-25T18:12:47

TIP #325: SYSTEM TRAY ACCESS ============================== Version: $Revision: 1.1 $ Author: David N. Welton State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Monday, 25 August 2008 URL: http://purl.org/tcl/tip/325.html WebEdit: http://purl.org/tcl/tip/edit/325 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== Modern operating systems have a "system tray", where programs may place an icon to indicate program status. This TIP proposes that Tk should adopt some existing code in order to permit cross platform access to this functionality. EXISTING CODE =============== * Windows: winico * Linux: tktray * Mac: ??? Existing code is sufficient, and utilizes an acceptable license in order to repurpose it for a systray command. INTERFACE =========== To be determined by the TCT, but along the lines of what tktray provides: *tktray::icon* /pathName/ ?/options/? Create a new icon for the system tray. The application managing the system tray is notified about the new icon. It normally results in the icon being added to the tray. If there is no system tray at the icon creation time, the icon will be invisible. When a new system tray appears, the icon will be added to it. Options: -class: WM_CLASS attribute for the icon window. Tray manager may use class name to remember icon position or other attributes. -image: image to show in the system tray. The value must be the name of a photo image. Transparency data of the photo are used to set the window's shape. The icon will be automatically redrawn or resized appropriately on any image modifications. -visible: boolean value indicating whether the icon must be visible. The system tray manager continues to manage the icon whether it is visible or not. Thus when invisible icon becomes visible, its position on the system tray is likely to remain the same. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Tcl/Tk 8.6a2 RELEASED

Donald G Porter — 2008-08-25T15:28:35

Tcl/Tk 8.6a2 Release Announcement August 25, 2008 The Tcl Core Team is pleased to announce the 8.6a2 releases of the Tcl dynamic language and the Tk toolkit. This is the second alpha release of Tcl/Tk 8.6. 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.6a2 sources are freely available as open source from the Tcl Developer Xchange web site at: http://www.tcl.tk/software/tcltk/8.6.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.6a1: -------------------------------------- The following were the main changes in Tcl/Tk 8.6a2. 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 release is the second alpha release of 8.6. The alpha moniker means that it is in feature addition mode. All bug fixes (and some more) up to and including 8.5.4 changes are included in 8.6a2. The following list focuses on new features added so far in 8.6. This release is a development release, and should only be considered for deployment use after considerable testing. * [TIP 304] New command [chan pipe]. * New Non-Recursive Evaluation implementation decouples the Tcl evaluation stack from the C evaluation stack. * New experimental commands in ::tcl::unsupported : [tailcall], [atProcExit], [coroutine] and [yield]. * Stack overflow protection in regexp engine. * Tcl_Finalize() no longer implicitly called on DLL_PROCESS_DETACH. * Stopped providing workarounds for broken Itcl use of [namespace code]. Use recent enough Itcl releases that take care of themselves. *** POTENTIAL INCOMPATIBILITY *** * Revised public Tcl routines passing (Tcl_ObjType *), (Tcl_Timer *), and (Tcl_Filesystem *) arguments to use "const" to indicate read-only pointers. *** POTENTIAL INCOMPATIBILITY *** * Fixed broken handling of ***= regexps. * Fixed crash in [namespace inscope {}]. * [namespace import]ed command now fire execution traces. * More consistent "wrong # args" messages. * Revised number formatting in Tk scroll interface so that values no longer look like integers. -- Tcl Core Team and Maintainers Don Porter, Tcl Core Release Manager

Re: Pre-CFV: TIP#320

Donal K. Fellows — 2008-08-25T11:01:32

Correct. You've got introspection through [self] and [info], so you can look at the object's class structure and work out what's going on in great depth. Among the things you could establish is whether any class other than the current one declares those variables. I think that doing that is deeply wrong-headed. :-) It denies the sharing of variables (people might want to do that), it is ineffective (nobody needs to declare anything anyway; it just makes things easier to use and faster), and anyway in Tcl it is interpreters that are the true units of information hiding. The whole "private variable" malarkey just feels misguided to me. Just list the variables used in the documentation of the class. Then it's up to subclasses to stay out of the way. :-) Sure there's a potential danger when a superclass is altered. But in my experience doing Java development, this sort of thing is really not a big problem. Or rather, when it is a problem, it's a sign that you're inheriting when you should be delegating. This whole "stake a claim" idea makes me very uneasy, both at the level of principles and at the level of practical (efficient) implementation. Good thing it's out of the scope of the TIP. :-) Donal. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Coroutines in HEAD

Lars Hellström — 2008-08-24T20:02:59

To continue where I left off... C API (Not my strong side, but one that has to be addressed.) Since the idea is mostly to give new meaning to things that can already happen, there isn't /that/ much that has to be added on the C side, but one major thing is the prototype for the function that is called when a command is resumed; let's call this a resumeProc: typedef int Tcl_ObjResumeProc( ClientData clientData, Tcl_Interp *interp, int objc, Tcl_Obj *const objv[], int resumeIdx, Tcl_Obj *const resumeData[] ); The idea here is that the resumeData should be the objv from applying Tcl_ListObjGetElements to the result caught with the TCL_SUSPEND, and resumeIdx is the index into this array of the element which is relevant for this command; the resumeProc will eventually call the resumeProc of the command it received TCL_SUSPEND from with the same resumeData but resumeIdx-1. For practical convenience, it is probably also useful to have a library function for calling the resumeProc of a particular command, so Tcl_EvalObjEx (or whichever is the core one these days) would get the cousin int Tcl_ResumeObjEx(interp, objPtr, flags, resumeIdx, resumeData) The tricky part is of course that all these resumeProcs must be provided when the command is created. For a long time I thought that this meant nothing of this could be implemented before Tcl 9 anyway (hence there would be no rush to generate a string representation :-] of the suspend/resume idea), but now I'm not so sure -- it's perfectly reasonable to have e.g. Tcl_CreateObjCommand create commands without a resumeProc (resumeProc==NULL), and instead introduce a new function Tcl_Command Tcl_CreateSuspendableCommand( interp, cmdName, proc, clientData, deleteProc, resumeProc ) for creating commands that do have it. Calling Tcl_ResumeObjEx for a command that doesn't have a resumeProc won't work, but we can simply report that as an error, so it's no big deal (at the C level). However, rather than reporting such errors at the resuming stage, it would be better to detect them at the suspend stage. In principle, that could be done by having Tcl_Eval* verify that any command returning a TCL_SUSPEND also has a resumeProc, or else convert that TCL_SUSPEND into an appropriate error. As far as I can tell, that would be the only ***potential incompatibility*** of this scheme against current Tcl. COMPARISON OF [coroutine]/[yield] AND [suspend]/[resume] Roughly, [suspend] corresponds to [yield], whereas [resume] is more like the coroutine-cmds; there is no explicit [coroutine]-like command needed in the [suspend]/[resume] approach, since one is implicitly provided by the main event loop (when that is running). *Existence.* Obviously, a big difference is that an implementation of [coroutine]/[yield] exists, whereas [suspend]/[resume] is at best a sketch. *Model.* [coroutine]/[yield] is, as far as I can tell, modelled after the concept of a generator: a subroutine than can return several times. [suspend]/[resume] rather follows the continuation model: the rough idea of "the program from this point on" is given tangible existence. It is different from the LISPish (call-cc) in that the continuation is not given the form of an anonymous function, but that's natural given the more imperative nature of Tcl, and it is also different in that it is not the part of the program that calls [suspend] which gets to handle the continuation, but rather some generic handler at the top level. *Storage.* Since [suspend] starts putting data in the interpreter result, everything has to be put under a Tcl_Obj wrapper. This is potentially a slow operation (but probably not so slow that it becomes a major issue when suspending the handler for an event). By contrast, [coroutine]/[yield] hides everything under the opaque handle of a command. Giving continuations the form of a Tcl_Obj brings all the usual EIAS advantages: can pass by value and store in data structures, can save on file or hand over to another thread, one can even resume the same continuation several times (thus admitting a native implementation of oracles for nondeterministic automata)! The cost is that one actually has to implement (for every resumable command!) a relevant freeIntRepProc, dupIntRepProc, updateStringProc, and setFromAnyProc. This _is_ just a Simple Matter Of Programming compared to [coroutine]/[yield], since the potentially nontrivial task of isolating the internal state of the generator from the rest of the interpreter has already been done and all that remains is to serialize/deserialize this state. Designing a serialization format capable of expressing the necessary data structures is obviously possible. Designing it so that it can _only_ express sensible instances of the necessary data structures is perhaps less easy, but this is not technically required for EIAS. There is OTOH no principal problem in introducing explicit commands that serialize and deserialize a coroutine-command in the [coroutine]/[yield] approach (it just hasn't been done yet), and this could then be used to transport coroutines across thread boundaries, but there is probably a practical problem in that cooperation (serialization/deserialisation of clientData) would be required from anything that creates an NRE callback. *Emulation.* [coroutine] and [yield] can be emulated using [suspend]/[resume], as follows (rough implementation): interp alias {} yield {} suspend yield proc coroutine {cmd args} { if {[catch {{*}$args} res opt] != $::TCL_SUSPEND} then { return -options $opt $res } switch -- [lindex $res 0 0] "yield" { interp alias {} $cmd {} call-again $cmd $res return [lindex $res 0 1] } } proc call-again {cmd continuation value} { rename $cmd "" coroutine $cmd resume $continuation $value } I don't see how the converse would be possible (but since NRE is more than just [coroutine], that needn't be a problem). *Intervention.* Since a TCL_SUSPEND is a return code and can be caught, it allows surrounding control structures to intervene and/or react to being suspended. As I understand it, NRE provides nothing in this area. As an example of intervention, consider control structures that exist not to do flow control, but to guard the utilization of some limited resource. One such case is the transaction subcommand of a TDBC handle: proc foo {db expr} { ... $db transaction { ... bar $expr $value ... } ... } proc bar {expr value} { ... if $expr then {set value [yield $value]} ... } coroutine baz foo $db $expr Chances are that the [$db transaction] above will count as recursion with respet to the NRE and thus cause [yield] to error out, with a [$db rollback] as consequence, but if it does not then the database could stay locked for a rather long time, without a clear offender. By contrast, if the [yield] had been a [suspend] instead then [$db transaction] would be explicitly informed about what is going on, and thus given a chance to react sensibly. Doing an immediate [$db rollback] and changing the TCL_SUSPEND into a TCL_ERROR is the most elementary reaction (and perhaps the only one directly supported by the TDBC interfaces), but it might often be more practical to capture the operations made so far in some kind of diff, and attempt to reapply them when the transaction is resumed. In that case, the TCL_SUSPEND should be passed on. A complication for control structures implemented in Tcl is that they need to create some representation of their own internal state when passing on a TCL_SUSPEND. If a third command besides [suspend] and [resume] is needed, then this will probably be why. On the other hand, if the serialization format used for the internal state of a proc is documented, then all sorts of programming tricks (e.g. disconnecting an [upvar]ed variable) can be implemented as [suspend]ing execution and having some detail in the state of some surrounding procedure modified... miguel sofer skrev: Hadn't thought of that one, but OTOH I was mostly thinking Tcl9 anyway (until recently). Realistically though, if some TCT member had come up with an idea that required usurping another return code, then I doubt there would have been much opposition against doing so within the 8.x series. Also, that noone else reported bug#647307 is perhaps an indication that nonstandard return codes aren't that heavily used. ;-) *That* is not a bug; it is a feature (as explained above)! Late addition: One could improve interoperability between [suspend]/[resume] and old control structures implemented in Tcl by making it so that [catch] only catches TCL_SUSPEND if it has an extra argument -- thus extending the syntax to catch $script ?resvar? ?optionsvar? ?resumeitemvar?