**Google Summer of Code 2009 (aka GSOC 2009)**

'''Student applications are accepted Mon, March 23, 12pm – Fri, April 3, 12pm.''' (Pacific Timezone).

----
<<TOC>>
----

This is the central location for proposing ideas for the Tcl Summer of Code [http://code.google.com/soc]. We have been '''accepted''' by Google in 2009 as mentoring organization - see http://socghop.appspot.com/org_app/show/google/gsoc2009/tcltk.

''Last year a mailing list (tcl-soc2008 at lists.sourceforge.net) was used for discussions of project ideas and other conversations about Tcl/Tk SoC.  Students, Mentors, Potential Students, and Potential Mentors should join. Details are available at https://lists.sourceforge.net/lists/listinfo/tcl-soc2008.''

''This year we've just setup new mailing list (tcl-gsoc at lists.sourceforge.net) at https://lists.sourceforge.net/lists/listinfo/tcl-gsoc. So please use this new mailing list but keep an eye on the old one as for a while some discussion may take place there.''


The 2009 Tcl/Tk SoC administrator is [Matthew Burke] (`mmburke'''at'''gwu'''full-stop'''edu`). As backup administrator will act [Tomasz Kosiak] (`tkosiak'''at'''gmail'''full-stop'''com`). Contact them both if you have any questions.

***Students***

If you are a student interested in getting paid to develop open source software using Tcl/Tk (http://www.tcl.tk), we encourage you to apply.

Why should you want to do this?  Tcl/Tk is perhaps the most mature of the dynamic languages, dating back to 1988.  The evolution of the language over the last 20 years has been marked by passionate preservation of the balance between maintaining simplicity and utility with the adoption of new ideas and new techniques based on accumulated experience.

Tcl/Tk is used in a number of prominent software systems including [DejaGnu] (e.g. used for testing the gcc compiler), [Expect] and [AOLserver].  The language is used by many scientific organizations including NASA as well as being used extensively in the commercial and financial sectors.


Please see [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs%|%Google's SoC FAQ] for more information on the program.  There are several good sources of advice for choosing a project to which you should apply [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents], [http://wiki.python.org/moin/SummerOfCode/Expectations%|%expectations of student participants], [http://drupal.org/node/59037%|%how to write a compelling application], and [http://summer.cs.pdx.edu/propose%|%proposing your own project].


'''Added incentive for students'''

Any project completed  before the [Sixteenth Annual Tcl/Tk Conference (2009)] (Sept 28 - Oct 2 in Portland, OR, USA)  will be accepted for presentation in the conference Technical Track.

***Mentors***
If you have an idea, please include it in the list below.  Put "MENTOR REQUIRED" in the mentor line if you are unable to serve as mentor for the project.  Contact Matthew Burke (see above) with any questions.

Also see the [Organization Application for Google Summer of Code 2009].

Note that many of the '''Project Ideas for the Future''' [http://wiki.tcl.tk/20832#pagetoc64574769] from [Project Ideas for Google Summer of Code 2008] are still relevant for GSoC 2009, as are many of the things listed on [Google Code of Summer 2007 Proposals].

[tkosiak]: [Matthew Burke] submitted our application long before the deadline. Now we have to wait for Google and improve this page meanwhile. I think that exact wording of our application should be put on the wiki at [http://wiki.tcl.tk/22713] to replace the version I have crafted just before the deadline. 

[AK]: This page is becoming to big. I propose to split out proposals to their own page, and have a table here linking to the individual idea pages. As part of the refactoring the proposals can be cleaned as well.

[tkosiak]: I think that we should not split this page but clean up headers like "Benefits ..." "Notes" and insert an index consisting of anchors in the page body. 

[AK]: I agree that an index would help ... Hm. I believe I should ask [jdc] if the wiki markup supports either intra-page links, or has some type of coding which would insert a nicely formatted table of contents into the rendered page. The latter being preferred.

[tkosiak]: I made some formatting cleanup to our ideas list - mostly to get rid of superfluous headers like "Benefits ..." "Notes" - converted them to bold text.

----

**Project Ideas:**

----
***Better string sentence and title case handling***
   * mentor: William J Giddings ([WJG]) NEED CONFIRMATION
   * difficulty: easy - medium

[string totitle] doesn't do what it says on the tin and is regularly confusing to people who're used to it working by capitalizing each word [http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2004-08/1000.html] rather than only the first character of the string entire.

On the [Tcl'ers Chat], it was noted that proper sentence and title handling would be heavily [locale]-dependent, as vastly different conventions apply to various languages; let alone right-to-left languages.

This project would create a Tcl extension for conversion of strings according to locale rules to appropriate sentences and document titles.

'''Notes'''
<<br>>
[WJG] (31/12/08) Creating correctly capitalized titles isn't too difficult. Here's something I posted to the wiki a couple of years ago. Rather than determining what to capitalize, it works on the principle that certain words are traditionally not capitalized. Naturally, capitalization exception lists will vary from language to language. [http://wiki.tcl.tk/15751]

[DKF]: This is a somewhat tricky project, because it'd be producing production-ready code. (We would also want it to be possible to extend what is done so that we can handle other things like collation ordering for '''[lsort] -dictionary''', etc.) It's not that the coding is itself difficult, but it would need to be done to a higher quality than that done by most students. The design phase is difficult though, since very few people have enough exposure to the full nuances involved and so hence miss out on features that are important in some languages.

----
***Regexp engine cleanup***
   * mentor: primary MENTOR REQUIRED as [Donal K. Fellows] ([DKF]) and [Jeff Hobbs] ([JH]) will only help
   * difficulty: medium - hard

[Regular expressions] are an integral part of Tcl, not only through the dedicated [regexp] and [regsub] commands, but also as helpers in numerous other places, most notably the [lsort] and [switch] commands. The current engine, written by [Henry Spencer] and used since Tcl 8.1, has several advantages:
   * It supports [Unicode].
   * It relies on finite automata, and is thus [http://swtch.com/~rsc/regexp/regexp1.html] far more resilient against [DoS] attacks through pathological search patterns than the backtracking engines used in some other communities.
Still, there are things about it which should be improved:
   '''Fixed character width''':   The code assumes the text being searched is a C-vector of ''chr''s, i.e., the bytewidth of characters is fixed (in normal builds to 2 bytes), despite regular expression matching in principle being content with sequential access. One disadvantage of this is that data to be matched frequently has to be converted from Tcl's primary UTF-8 string representation to a monowidth representation. Another disadvantage is that this blocks some approaches for extending Tcl's Unicode support to characters beyond the BMP.
   '''Coding style''':   When originally incorporated into the Tcl core, further upstream development of the regexp engine was expected, and so it was admitted despite not adhering to the [Tcl Style Guide] and not being as readable as the Tcl core in general. Today there is no upstream development, so it would be nice if the regexp engine could be brought in line with the rest. ''(Note that some progress has already been made (when?) on this; the RE engine is a ''lot'' closer to Tcl's standard style than it used to be.)''
   '''Stream interface''':   Make it possible to run the engine on streams of characters being delivered by a callback.
   '''Lookbehind constraints''':   The engine supports lookahead constraints `(?=...)`, but not lookbehind constraints `(?<=...)`. It would be nice to support both.
   '''Reversion''':   The reverse of a regular language is also a regular language, so there is a theoretical foundation for an RE syntax or option meaning "this regexp is to be read backwards". Reversion has a practical application in backwards searches.
''[[Feel free to add more.]]''

'''Benefit for the student'''
<<br>>
Reworking the regular expression engine gives practical experience with a concrete full-featured implementation of a very classical piece of Computer Science (namely, the theory of regular expressions and finite automata).

'''Notes'''
<<br>>
[AMG]: It's interesting to mention both lookbehind constraints and reversion.  I once worked around the absence of lookbehind constraints by reversing the input string to [regexp] (actually, [regsub]).  Find the code on [SYStems]'s hijacked Wiki page. :^)

----
***Printing***
   * mentor: [Clif Flynt] ([CF])

[CF] The first step to being able to print Tk graphics is to extract the drawing information from Tk and render the windows in a printable format.  Krysztof Blicharski did the first step of this
for the 2008 GSoC with a package that will render all standard widgets except the 'text' widget as PDF files.  This work is available at:
[http://www.assembla.com/wiki/show/tktopdf] .  I've used it for one of my projects, and it is functional.

The package is incomplete because the text widget lacks introspection capability to determine exactly where text
wraps (and perhaps other formatting decisions that are made within the widget that I haven't run into yet), and the
TTK widgets lack complete introspection functionality.

The next step to generate PDFs for all Tk widgets will require delving into the Tk "C" layer to:
   1. Extend the text widget introspection capability.
   2. Extend the TTK framework for more introspection and reporting of theme values.

'''Benefits for the student'''
<<br>>
An opportunity to extend their familiarity with "C" code, to work with a large body of code they didn't write themselves, and
to work within a previously defined framework.  An opportunity to work with experts.

'''Benefits to the Tcl Community'''
<<br>>
This is another step towards full printing support.

'''Difficulty'''
<<br>>
Difficult.  Will require knowledge of C, Tcl/Tk, X11/Unix, Windows and Mac OS.

Clif Flynt is willing to mentor this work, and Joe English has agreed to assist with the TTK details.  If someone familiar with
the text widget internals would like to step forward, they'd be more than welcome to join the party.

----
***TkTutor -- WITHDRAWN --***
   * mentor: [Clif Flynt] ([CF])

[CF] Google specifically excludes documentation projects from the GSoC projects.

http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#doc_proposals

[CF] TclTutor has been available for many years and provided the base material for the Tcl tutorial at www.tcl.tk.
I've written a half-dozen Tk tutorials to go with the engine and never had time to
finish them and make them available.

The project would be to write TclTutor lessons for each of the Tk widgets.  These lessons will demonstrate how to use the widgets
in simple cases and how to use the more esoteric options and commands.

The TkTutor html pages could be used to expand the Tutorial section of www.tcl.tk.


'''Benefits for the student'''
<<br>>
The student would become familiar with the Tk widget set.  This is a simple project that an undergrad could work on.
Getting your name on a package that sees thousands of downloads a year.

'''Benefits to the community'''
<<br>>
Improved documentation and tutorial package.

'''Difficulty'''
<<br>>
Easy.  A student should have some knowledge of Tcl/Tk, but need not be expert.

Clif Flynt is willing to mentor this project, but can mentor only 2 projects.
----
***XLS Read/Write***
   * mentor: [Clif Flynt] ([CF])

[CF] CSV Files are sufficient for transmitting data from a Tcl/Tk application to an analyst, but are insufficient for exporting a [tktable] with multiple pages, color or font information.  The [perl] folks have a module that will read/write XLS files.  Having this package in the [tcllib] would enhance Tcl/Tk's usefulness.

'''Benefits to Student'''
<<br>>
Experience with writing pure Tcl code.  Experience in reading and understanding a language spec.  Writing code with a strong potential for moving into commercial/industrial use.

'''Benefits to Community'''
<<br>>
Expanding Tcl's functionality and ability to play with others.

'''Difficulty'''
<<br>>
Moderate.  Student should know Tcl moderately well and be able to read the XLS specifications and design an API.

Clif Flynt is willing to mentor this project, but can mentor only 2 projects.
----
***Tcl Application Server***
   * mentor: [Gerald Lester] ([GWL]) and [Colin McCormack] ([CMcC])

Develop, using [WUB] as a base, of a Tcl Application Sever for web based applications (both WSDL and Rest based) and Tcl 8.6.  This would be similar to JBoss or Zend.
Such a server would implement:
   * Management API
   ** Installation of an service
   ** Authentication and Authorization specification for a service
   ** Access control on a service
   * Servlet API which will include
   ** Hibernate-integration for persistence programming
   ** [TDBC%|%TclDBC%|%]
   ** Log message handling (file, email, service call)

'''Benefits to Student'''

   * Experience with writing pure Tcl code.
   * Experience with web services technologies.
   * Defining and document APIs.
   * Writing code with a strong potential for moving into commercial/industrial use.

'''Benefits to Community'''
<<br>>
A start of an n-tier enterprise application server for Tcl based applications.

[Gerald Lester] and [Colin McCormack] are willing to mentor this project.
----
***Tclhttpd refurbish***
   * mentor: [Steve Huntley] ([SEH]) 
   * difficulty: medium

Last spring there was discussion of an initiative to collect various patches and best-practice code commonly applied in the wild to [tclhttpd] (see comp.lang.tcl thread:
[http://groups.google.com/group/comp.lang.tcl/tree/browse_frm/thread/596899f8582bc87a/5a1b971b62ccb7cd?rnum=21&q=tclhttpd&_done=%2Fgroup%2Fcomp.lang.tcl%2Fbrowse_frm%2Fthread%2F596899f8582bc87a%2Fcca8962ed4ad6ddd%3Ftvc%3D1%26q%3Dtclhttpd%26#doc_96e9b86988408b96])
which would make it more robust and suitable for use in hostile real-world environments.  Said initiative doesn't appear to have gone anywhere.

It would be instructive for a student to analyze a package like tclhttpd (which is generally quite standards-compliant, robust and useful) for the weaknesses that manifest in real-world use, and gather, evaluate and apply the existing solutions to the official code base; as well as create solutions that aren't already available.

A better tclhttpd would be quite useful to the many existing users of the application, as well as a benchmark for successor products as they appear.

----
***Curses implementation of Tk***

Tcl has had a couple of implementations of "Tk for the terminal" in the form of [ctk] [http://www.ma.utexas.edu/restricted-resources/utma-doc/tcl-tk/html/README/Ctk ] (for Tk 4.0b ) and [ck] [http://www.ch-werner.de/ck] (for Tk 8.0 ); however, for current versions of Tk nothing is available (other than the tcllib term package(s) which is rudimentary and does not offer the advantages that (n)curses provides).  Can you imagine what a selling point this would be for TCL? Having the ability to use a GUI on a desktop and then using the same program via a serial port would be a boon to sysadmins.  How many times have you heard things like "We want a Swing UI since its Java its multi-platform". What about Tcl/Tk? Its multi-platform AND you can use the same program in a ssh terminal session or over a serial line  when no windowing system is available. An extension like this would add serious value to Tcl/Tk and make it a contender.  

This could be accomplished quickly given that there are implementations to study and possibly borrow code from. The Ck is the most complete and would be an excellent starting point. 
----
***Tk Factor Photo Image Handling***

Factor the [photo] [image] handling and processing out of Tk, make it independent of presence of [X11] and other graphics core (leave only the absolutely minimal graphics-dependent part in Tk).

''([DKF]: Note that in 8.6 there is already some splitting of the image code into manipulators and renderers. ''I think'' that, of the code that isn't doing rendering, the only part that is critically related to having a GUI is color name parsing. See also Tk FRQ 783802 [https://sourceforge.net/tracker/?func=detail&aid=783802&group_id=12997&atid=362997%|%Tcl'2003: Split photo masters into Tcl package].)''

'''Benefits for the student'''
<<br>>
An opportunity to extend their familiarity with "C" code, to work with a large body of code they didn't write themselves, and to work within a previously defined framework (namely the TK Image infrastructure).

'''Benefits to the Tcl Community'''
<<br>>
This makes an important part of graphical operations available to display-less applications, like report generators, web servers (on-the-fly graphics), etc.

'''Notes'''

   * The estimated difficulty is '''high'''.
   * The mentor for this should have good knowledge of Tk internals.

----
***Tk Icon Themes***

Create a package to create, manage and use '''icon themes'''. This came out of a recent thread on `tcllib-devel` about a package wrapped around the famfam silk icons for easy physical access. This promptly started talk about logical access, plugins and themes. See that thread for more on this idea ... (TODO: get sourceforge url to the thread, or other archive of that mailing list) ...

'''References'''

   * http://freedesktop.org/wiki/Specifications/icon-theme-spec,
   * http://freedesktop.org/wiki/Specifications/basedir-spec,
   * http://freedesktop.org/wiki/Specifications/icon-naming-spec
   * http://www.satisoft.com/tcltk/icons/

'''Notes'''

   * We have pieces for this already, like Tcllib's [ini] package to handle .ini files (The theme information is stored in such files).
   * This is something which can be written entirely in Tcl, no C required.
   * The estimated difficulty is '''medium''' to '''low''', IMHO ([AK]).
   * I ([AK]) am willing to mentor this.

'''Benefits to the Tcl Community'''
<<br>>
Making it easier to create applications which fit into the KDE and Gnome Desktop Environment

'''Benefits for the student'''
<<br>>
???

----
***Gnocl***
I would like to see [Gnocl] get some help. That is the most promising non-Tk framework for Tcl.

'''Benefits for the student'''

   * An opportunity to extend their familiarity with "C" code, to work with a large body of code they didn't write themselves, and to work within a previously defined framework (namely the popular Gnome and GTK+).
   * An opportunity to work with experts.

'''Benefits to the Tcl Community'''
<<br>>
This gives another full GUI toolkit for the community to use in building their Tcl applications.

'''Notes'''
<<br>>
[RLH] I would like to second this one.

[WJG] (12-FEB-09) As the current maintainer of Gnocl I'm really pleased to see interest being taken in the project. Whilst a lot of work has been done and many exciting features will be available in the next release (e.g. window masking and a bag of megawidgets) there is still much to do. Any one interested in contributing to the project will be warmly welcomed. So, let me know what features your interested in and see how these can be added to Gnocl.

----
***Improved HTTP/1.1 support in the core***
    * [Jeff Hobbs]
    * Difficulty: easy

Drawing together mixed implementations that are available, this would require a student with an interest in protocols and a good eye for compliance and discipline for test-driven development.

'''Benefit to student'''
<<br>>
Gain experience in developing language extensions, develop deeper understanding of [HTTP].

'''Benefit to community'''
<<br>>
More consistent and powerful functionality for manipulating HTTP requests and responses in Tcl/Tk scripts.

----
***Megawidget development***
    * [Jeff Hobbs]
    * Difficulty: easy(-ish)

Based on [TclOO] (Tcl's built-in object system), translate and update the plethora of megawidgets into a single, unified megawidget system that can be "core" blessed.  Would involve extensive use of OO, x-platform UI, event-driven coding, etc.

'''Benefit to student'''
<<br>>
Practical experience in design and implementation of a widget framework.

'''Benefit to community'''
   * A consistent widget system making use of new core functionality.
   * A good base for further building of custom widgets in pure Tcl code by the whole community.

'''Notes'''
<<br>>
[DKF]: I want more [megawidget]s, I want to know how good Tk 8.6 is for building megawidgets, I'd love to see a set of [TclOO] base classes for megawidget support, and I'm very keen on learning what things need to be added at the [Tk C API%|%C level%|%] to make megawidgets easier/better. This is an ideal thing for a GSoC project, as it doesn't need a lot of complicated programming and the return on the student's effort is very immediate.

[LV]: at the very least, it would be beneficial for someone to do a review of several existing megawidget frameworks (both within the Tk community and outside), producing a set of requirements for a framework which, when eventually implemented, would provide a set of megawidgets which are more Tk (or perhaps more [Ttk]?) like.

----
***AOLserver-libpurple integration***
    * [Matthew Burke]
    * Difficulty: easy to hard (depending on scope and approach)

The goal for this project is to develop an [AOLserver] module which enables the server to generate instant messages in response to [HTTP] requests and to evaluate resource scripts in response to instant messages.  An easy approach would be to create a separate thread which monitors two queues: one for incoming instant messages and one for responses to be sent out as instant messages.  A more comprehensive approach would be to develop a request handling framework for instant messages that works like AOLserver's other protocol handlers.

Information on libpurple can be found at [http://developer.pidgin.im/].

'''Benefit to student'''
<<br>>
Learn about AOLserver internals, multi-threaded programming, instant message protocols.

'''Benefit to community'''
<<br>>
Allow application developers to easily adapt their services to communicate with users over additional channels with minimal duplication of effort.

----
***Tcl FireFox Scripting and DOM access***
   * [Colin McCormack]
   * Difficulty: medium-hard

Firefox has recently been extended to permit scripts in languages other than JavaScript to appear in <script> and to evaluate them.  These scripts provide access to the DOM.  Production of an XPI installable module which links FireFox scripting to a Tcl interpreter would be a beneficial project.  Addition and rehabilitation of the tcl xpcom interface package would complete the package.

'''Benefit to student'''
<<br>>
Two levels - Tcl and Firefox.  Firefox level hacking is a commercially valuable skill.  FF community has a lot of hot C/C++ people.  Firefox has a long future.  Tcl is great :)  Putting the two together could spark a lot of activity.

'''Benefit to community'''
<<br>>
Web applications have a great future - shame about the JavaScript.  I think the ability to manipulate the DOM from Tcl would immediately enable a wide range of applications due to Tcl's greater maturity and facility compared to JavaScript.  This would benefit Tcl by increasing exposure (it would bear the same relationship to Tcl as Tk does, but in a whole new field.)  I daresay it might also benefit the broader community, by bringing Tcl into this field.

----
***Complete TclScript project for IE scripting***
   * Nominate [Pat Thoyts]?
   * Difficulty: ?

[TclScript] would provide the ability to run Tcl scripts in Internet Explorer similar to the above project's goal of scripting in Firefox.  See [http://wiki.tcl.tk/2870] for more info.  The ability to run Tcl scripts in both IE and Firefox would be very advantageous (Tcl is suddenly a powerful web client development platform), and each of these two projects would make the other more valuable.

----
***[http://plugin.tcl.tk/%|%Tcl/Tk Browser Plugin%|%]: User-Privileged Security***
   * [Jeff Hobbs] (@ [ActiveState])
   * Difficulty: medium-hard

The current Tcl plugin is based on security policies that are configurable via special configuration files on the local system.  These may be extended, but only what is named and known at runtime is available.  A tclet (Tcl plugin application) can request a certain security level and is only given access if the local configuration expressly allows it.  A user is not allowed to "opt-in" some tclets. More information on the current design is at:
   * http://www.tcl.tk/software/plugin/safetcl.html
   * http://www.tcl.tk/software/plugin/man/pluginDoc/policy.htm

This project seeks to revamp the security policy management in the Tcl plugin to allow for UI-level control of security policies, as well as dynamic control for elevation/restriction of security based on domain and/or URL.

'''Benefit to Student'''
<<br>>
Gain experience in web based security and secure coding practices.

'''Benefit to community'''
<<br>>
Improved plugin for web applications.

----
***[http://plugin.tcl.tk/%|%Tcl/Tk Browser Plugin%|%]: Native OS X (Aqua) port***
   * [Jeff Hobbs] (@ [ActiveState])
   * Difficulty: medium

The current Tcl plugin had a Mac Classic port and works on [Win32] and [X11] systems.  It currently lacks a functional native Aqua port.  This project seeks to provide a native Aqua port of the Tcl plugin.  Knowledge of [Tk] and native [MacOS X%|%OS X%|%] APIs would make this easier.

'''Benefit to Student'''
<<br>>
Gain experience in web plugins and OS X.

'''Benefit to community'''
<<br>>
Complete set of "common" platform ports for Tcl plugin.

----
***[http://tktable.sourceforge.net/tile/%|%Gtk theme for Tk%|%]***
   * [Pat Thoyts] and/or [Joe English]
   * Difficulty: medium-hard

Tk 8.5 supports [Ttk%|%themed widgets%|%]. On [Windows] and [MacOS X] the theme engine calls the native APIs to draw widget elements and achieve a native look. On X Window System desktops however Tk uses its own drawing code. There is a theme using [Qt] for [KDE] integration but nothing that permits integration on a [Gtk] desktop (i.e. [GNOME]). Some initial experimentation by Pat Thoyts shows that it is at least possible to have the Gtk style engine draw Tk theme elements.

'''Benefit to student'''
<<br>>
Experience with Gtk and Tk libraries.

'''Benefit to community'''
<<br>>
Significantly improved integration of Tk applications on Gtk-based desktops (e.g. [Ubuntu], Fedora)

[NEM]: Doesn't [TileGTK] already achieve this?

[DKF]: Code exists already[http://tktable.cvs.sourceforge.net/viewvc/tktable/tile-themes/tile-gtk/]. Perhaps this item needs to be removed. (Editing this page is hard, especially when ideas are present in several places...)
----
***[http://sourceforge.net/projects/tktoolkit%|%TkCocoa%|%]***
   * [Daniel Steffen]
   * Difficulty: hard

The current implementation of the native [MacOS X] Tk is based on the legacy Carbon/HIToolbox API. Large parts of this API are deprecated with Leopard and not available to 64bit applications. This project aims to replace Tk's use of HIToolbox with Cocoa/AppKit. In a first instance, window (toplevel) creation and management would be targeted, with other areas like widget creation or event handling to follow if time permits.

   * http://developer.apple.com/cocoa/
   * http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/WinPanel.html
   * http://rutherglen.ics.mq.edu.au/fisheye/browse/Tk/tk/macosx
   * http://rutherglen.ics.mq.edu.au/fisheye/browse/Tk/tk/macosx/tkMacOSXWm.c?r=HEAD

'''Skills required'''
<<br>>
Experience with C and Objective-C, in-depth familiarity with Cocoa frameworks, familiarity with Carbon and X11 APIs a plus.

'''Benefit to Student'''
<<br>>
Gain experience with the use of Cocoa in an unfamiliar and challenging environment, learn about lower-level details of the [MacOS X] frameworks. 

'''Benefit to community'''
<<br>>
Assure Tk's future on [MacOS X] by moving away from deprecated APIs in the Tk implementation.

'''Notes'''
<<br>>
''J. Todd Slack is now working on this. Please see the discussions on the tcl-mac mailing list [http://sourceforge.net/mailarchive/forum.php?forum_name=tcl-mac], [http://sourceforge.net/mailarchive/forum.php?thread_name=2D0D676C-2396-4BE6-8195-75D331D82DCB%40gmail.com&forum_name=tcl-mac] for details.''
----
***[http://www.talend.com/%|%Talend Open Studio Integration%|%]***
   * [Nima Mazloumi]
   * Difficulty: medium-high

Talend Open Studio [http://www.talend.com] is an open source integration suite based on the Eclipse platform [http://www.eclipse.org]. Talend is a graphical Extract, Transform, Load (ETL) editor with support for Perl and Java code generation. The open architecture of Talend makes it extensible regarding new editors and ELT-components [http://www.talendforge.org/components/index.php]. The Eclipse Dynamic Languages Toolkit (DLTK)[http://www.eclipse.org/dltk/] provides a TCL development environment ready to use out of the box which could serve as the basis to provide TCL support to Talend.

There are two possible tasks for a student interested in this project depending on the skills and interests. The tasks include the following:

   * Integrate DLTK inside Talend and implement the interfaces for the Tcl code generation engine.
   * Provide Tcl ELT component counterparts to those available for Perl and Java.

'''Benefit to student'''

   * Experience in Tcl, Java and templating languages (code generation).
   * Experience in platform and RCP programming.
   * Experience data mining and enterprise integration.

'''Benefit to community'''
<<br>>
Providing Tcl support to Talend is a significant contribution to the Tcl community. It will provide Tcl developers all fully integrated and graphical development environment for data and system integration. Generated ETL jobs can be easily deployed on any operating system with Tcl support.

----
***[http://www.dotlrn.org/%|%Several Ideas on Improving dotLRN%|%]***
   * [Nima Mazloumi]
   * Difficulty: low-high

The learning management system .LRN [http://www.dotlrn.org] is an open source platform based on the web application framework [OpenACS] [http://www.openacs.org], [AOLServer] and Tcl. It supports the e-learning standards IEEE LOM, SCORM 1.2, IMS QTI 1.2.1 and IMS LD 1.0 and partially IMS Enterprise.

There are several ideas for a student interested in this project depending on the skills and interests. The tasks include the following and are all based on existing work:

   * Provision of a fail-safe graphical installer for [linux]
   * Implementation of a web based and graphical learning activity editor
   * Implementation of a web based and graphical concept map editor
   * Full support for IMS enterprise
   * Upgrade to SCORM 2004 r3
   * Upgrade to IMS QTI 2.x
   * Data integration between SCORM, QTI and IMS LD via the shared variable approach and AICC CMI

Contact proposer directly for information about difficulty of specific tasks.

'''Benefit to student'''

   * Experience in Tcl, Javascript, AJAX, DHTML, Scalable Vector Graphics.
   * Experience with e-learning standards.
   * Experience with an exiting web application platform

'''Benefit to community'''
<<br>>
Providing full e-learning standard conformance and web based editor functionalities to .LRN will make the platform the leading open source learning management system in the web.

----
***Constraints in the Tcl Core***
   * [Phil Mercurio]
   * Difficulty: medium-high

A constraint solver can be an effective way to support a more declarative programming style and to exploit parallelism. This project would investigate adding constraints to the Tcl core by implementing a constraint solver as a package and identifying the core modifications that would be necessary to support it. As a starting point, the mentors can provide a working one-way constraint implementation, a discussion of the likely core changes needed, and a pointer to a multi-way constraint algorithm that would be a good candidate for implementation [http://citeseer.ist.psu.edu/sannella93multiway.html].

'''Benefit to student'''
<<br>>
Experience in Tcl and C/C++, constraints, and parallel processing.

'''Benefit to community'''
<<br>>
Providing a robust constraint solver that can be integrated into the Tcl core is a significant contribution to the Tcl community that will complement Tcl's existing strong support for thread-based multiprocessing.

----
***TDBC Driver Development***

   * [Kevin Kenny]
   * difficulty: medium. 

Tcl Database Connectivity ([TDBC]) is a new feature in Tcl 8.6 whereby the API to access SQL databases is standardized. While most popular database are accessible via the ODBC driver, native drivers exist only for MySQL and SQLite (and the latter is inefficient because it uses SQLite's Tcl API rather than the C one). On this project, the student's task is to produce a driver for at least one other database API together with the associated test suite, documentation and release bundle.

'''Requirements for the student'''

   * C programming skills
   * Fair knowledge of SQL and at least one set of database bindings.
   * High motivation.
   * Ability to communicate in English.

'''Benefits for the student'''

   * Opportunity to extend familiarity with 'C' coding, and to develop intimate familiarity and expertise with at least one database's application program interface (API).
   * Opportunity to work with a body of code that the student didn't design, and to work bridging two previously defined frameworks.
   * Opportunity to work with recognized experts in both Tcl and SQL development.
   * Opportunity to see code transition quickly into widespread commercial and industrial use.

''' Benefits for the community'''
<<br>>
Further standardization of the TDBC API, enabling more cross-platform development of Rapid Application Development tools.

----
***[http://wiki.tcl.tk/20889%|%Cross-platform framework for database application GUI development%|%] based on Tcl/Tk + Tile***
   * [Tomasz Kosiak]
   * Difficulty: easy - medium

Tcl/Tk toolkit with [Tile] (theming support) allows building cross-platform GUI with native look & feel for MS Windows, Linux & Mac OS X.
Recent http://www.tcl.tk/cgi-bin/tct/tip/308.html%|%TIP #308: Tcl Database Connectivity (TDBC)%|% proposes standard SQL database API for Tcl. Selection of high quality tabular widgets combined with excellent retrospection capabilities of Tcl allowing to effortlessly create (like in Ruby on Rails) editing forms, provides basis for a framework for building database applications and their user interface [GUI]. Unlike in popular [RAD] (ex. Borland Delphi) we would like to build GUI by generating code not visually - as this is a recommended way to create GUI with Tcl/Tk.

First step in this project is to gain real life experience in cross platform Tk/Tile development by building simple time tracker like http://mg.pov.lt/gtimelog/%|%gtimelog%|% (used further to track project progress). Next step is an attempt to port to Tcl/Tk/Tile selected fragments of quite complex business application UI build with RAD. This process should lead to choosing appropriate widgets, showing how to use and glue them together with database API.

Mentioned commercial database application will be provided by a mentor, who has full access to its source code and its primary authors.

'''Requirements for students'''

   * Experience with some kind of [RAD], database bindings, good SQL knowledge, basic Tcl & Tk knowledge and high motivation.
   * Being able to meet personally in the early stages of the project or communicate in polish is a big plus.

'''Benefit to student'''
<<br>>
Getting to know Tcl/Tk toolkit with native widget support by [Tile] extension (integrated in Tk as ttk::* namespace commands).

'''Benefit to community'''
<<br>>
Verification and consolidation of separate components needed to build very common kind of application.

----
***[http://tkdnd.sourceforge.net/%|%Tk Drag&Drop%|%]: Native OS X (Aqua) port***
   * [Jeff Hobbs] (@ ActiveState)
   * Difficulty: medium

[tkdnd] is the drag & drop extension to Tk that works on Win32 (OLE) and X11 (Xdnd) systems.  It requires an OS X (Aqua) port to complete the common Tk platform set.  Finishing this would allow its full integration into the core Tk codebase.  Completing this might require refactoring of the currently public API for tkdnd in the case where OS X APIs don't match other platforms.  Knowledge of Tk and native OS X APIs would make this easier.

'''Benefit to Student'''
<<br>>
Gain experience with Tk and OS X.

'''Benefit to community'''
<<br>>
Provide a reliable drag&drop extension for all platforms.

----
***[http://tcljava.sourceforge.net/%|%Jacl Modernization%|%]***
   * [Mo Dejong], [Tom Poindexter]
   * Difficulty: medium-hard

[Jacl] is an implementation of Tcl in Java.  Jacl currently implements Tcl version 8.0, with some support 
for newer Tcl versions.  This project aims to bring Jacl's implementation to at least Tcl 8.4 levels.
Primary focus is implementing [fileevent] for sockets and pipes, modern regular expression processing 
(i.e., [PCRE], [ARE]), and updating other commands for Tcl 8.4 compliance.  Additional features from Tcl 8.5
may also be incorporated, including Tcl 8.5 commands and list-expansion syntax [{*}].

'''Benefit to Student'''
<<br>>
Gain experience implementing a language system in Java;  direct use of Java NIO and network programming; event-driven systems.

'''Benefit to community'''
<<br>>
Jacl will be modernized to current Tcl versions so that scripts written in Tcl run unchanged in a Jacl interpreter.  

----
***[http://tcljava.sourceforge.net/%|%Jacl TJC compiler optimization%|%]***
   * [Mo Dejong]
   * Difficulty: medium-hard

TJC, the ''Tcl-to-Java Compiler'', is a compiler for [Jacl].  It compiles Tcl
source files into Java source, which is then compiled with an embedded Java compiler.  This project
seeks to optimize code generation and compile additional Tcl commands.  Note that the TJC compiler is written primarily in Tcl, and generates Java source code.

'''Benefit to Student'''
<<br>>
Gain experience compiler implementation and optimization.

'''Benefit to community'''
<<br>>
Jacl/TJC will be enhanced to run Tcl scripts faster in the Java environment.

----
***OpenScripting Tcl***
   * [Matthew Burke]
   * Difficulty: easy-medium

The Open Scripting Architecture [http://developer.apple.com/documentation/AppleScript/Conceptual/AppleScriptX/Concepts/osa.html] is an extendible mechanism for inter-application communication in Mac OS X. Although originally designed for Applescript, it is possible to support other languages and their are OSA implementations of Ruby [http://rubyosa.rubyforge.org/], Javascript [http://www.latenightsw.com/freeware/JavaScriptOSA/], Perl (supposedly).

This project entails writing a library to allow Tcl scripts to respond to OSA events. 

'''Benefit to Student'''
<<br>>
The student will learn about developing FFI software, Mac OS X, and Tcl internals.

'''Benefit to community'''
<<br>>
Better integration of Tcl scripts with OS X applications.

'''Notes'''
<<br>>
''[Lars H]: Doesn't [TclAE] already provide this functionality?''

Urk.  Now you see what happens when you do a half-***ed search.  Yes, it does.  I'll leave this here though just in case it sparks some
ideas for someone.--[Matthew Burke]

[RLH] Maybe a cocoa bridge like Perl, Ruby and Python are using?

----
***Glade XML-to-Tk Translator***
   * ?
   * Difficulty: medium?

Glade [http://glade.gnome.org/] is a visual GUI authoring tool designed for creation of Gnome applications.  It saves its designs in a simple XML-format file, which is read and rendered at runtime by the libglade library into actual GUI code.  The goal of this project would be to produce a rendering script which reads a Glade XML format file and renders it into Tk script instead.

The Tcl/Tk community would thus get a quality, maintained, cross-platform visual GUI authoring tool for free.

A Glade-to-[gridplus] translator might be an easier and more straightforward way to accomplish the same net result.

[WJG] I looked at this some time ago. At that time the idea was to simply re-map Gnocl widget options to their Tk equivalents. Although Gtk has shares a common ancestry with Tk so many changes have occured (especially with Gtk) that these packages really are two separate species. The inherent difficulties in this path lies in trying to match the distinct widget properties of the two different widget sets. The management of signals too are different, Gtk has no equivalent of bind, for instance, and each widget has responds to events differenty. I do feel, however, that the fundamental idea of having a module that will read an XML description of a Tk layout is a sound one, similary a Tk command which would save any given UI to an XML file. As Tcl/Tk is so flexible and UI elements can be included ad hoc. saving any given widget state would be useful and XML the format of choice. Perhaps someone can produce a more streamlined, purpose made UI editor for Tk, something along the lines of Glade. 

----
***Cicero refurbish***
   * ?
   * Difficulty: medium

Although Tcl/Tk-based text editors are legion, the corresponding number of [WYSIWYG] word processors in the Tcl/Tk world is tiny.  This is a shame, given the power of Tk and the sophistication of the text widget.  In addition, word processor choices in the free software world in general tend to be either bloated or under-featured.

From the dawn of time (or rather, 1996) comes [Cicero], one of the few ambitious attempts in the Tcl/Tk world at an full-featured TeX-integrated WYSIWYG word processor.  This project would involve bringing Cicero up to modern programming standards and library compatibility, and making it suitable again for use in the present day.

'''Benefit to Student'''
<<br>>
Gain familiarity with document display, publishing and printing technologies, learn how dynamic and compiled languages can cooperate to create a powerful application, learn project management and entree into the free software community by becoming the maintainer of a potentially useful application.

'''Benefit to community'''
<<br>>
Fill a significant hole in the Tcl/Tk portfolio of applications, showcase the greatly improved Tk 8.5 text widget, increase exposure and use of Tcl/Tk by providing a lightweight WP app suitable for the new generation of small computer devices, provide a real-life test bed for ongoing expansion of Tcl/Tk publishing and printing capabilities.

----
***Graphs***
   * Create a graph query language (GraphQL), analogous to the existing [TreeQL]
   * Based on the previous comment, create a language to specify and execute graph transformations

[AK]: [Alejandro Eduardo Cruz Paz], he who worked on the graph operations last year tells me that he is continuing work in this area.

----
**Other Projects Ideas**
These are things that other projects will lead, but which are also of interest to the Tcl/Tk community.

***Git project***
   * [PT]: there is a proposal on the Git SoC page for enhancing their TortoiseGit clone that needs someone with Tk interests.
See git-cheetah [http://git.or.cz/gitwiki/SoC2009Ideas] for more information.
----
***Glade Project***
****Extending Gnocl support to include Glade and GtkBuildable UI XML Description Files****

Implement support for the GtkBuilable [http://glade.gnome.org] and libglade [http://library.gnome.org/devel/libglade/unstable/GladeXML.html] interfaces . This would enable XML UI definitions to be loaded directly into Gnocl applications. In doing so, this would provide closer integration of Tcl/Gnocl with the Gnome/Gtk development environment by enabling Gnocl developers to take advantage of the Glade [http://glade.gnome.org] interface designer which is part of the Gnome Development Tools package.

The actual implementation of these interfaces can be considered from two of perspectives dependent upon whether a C or pure Tcl code solution is pursued. In the former case, the construction of the main interface would be handled by the GtkBuildable/libglade library routines with the bulk of the SOC project programming based upon providing the created widgets with pointers to Tcl script procedures. In using Tcl to solve the problem, the XML file would be parsed and the UI built from the tagged data. In both cases, the idea of providing support for the conversion of XML UI definitions into Tcl/Gnocl script format should also be considered.

From a learning and training perspective, the Tcl approach would not require an in depth understanding of the Gtk libraries, whereas the C approach would require the SOC student to become familiar with the Tcl development interface, the Gnocl sourcecode and the Gtk development libraries.

Judging from the postings received in the past, this solution would prove attractive to existing Tcl/Tk developers who wish to explore the creation of pure Gtk/Gnome applications without investing in the initial time overhead of becoming familiar with the Gnocl scripting process. Similarly, the use of Glade created UI files may draw interest from existing Gtk developers who rely heavily upon Glade to produce manageable user interfaces. [WJG] (02/03/09)
----
**Incomplete Ideas**

There are lots of ideas scattered around the wiki.
There may be duplicates of things above here.

***Interp clone***
My personal favourite would be someone implementing [interp clone] (see [http://wiki.tcl.tk/4470] and c.l.t.).

''Difficulty: hard (meaning is not yet fully understood, and impact on extensions would need deep study)''
----
***SSH***

[Googie] 2 Jan 2009 - [Pure-Tcl] [SSH] client (as described at [http://wiki.tcl.tk/20283]) seems to be pretty useful, especially when combined with [TclVFS] which would give us [SFTP] filesystem support.

''Difficulty: medium-easy (code exists in principle)''

----
***Extended Unicode***
[LV] Perhaps this is too large a project for the summer... Right now, not all Unicode characters are handled by Tcl. Tcl handles the most common Unicode characters, but UTF-16 and UTF-32 have been defined as code points beyond the original definition.

[DKF]: [Unicode] goes up to 31 bits IIRC. If we're tinkering in this area, either we need to use surrogate pairs and give up on the one-character-is-one-character principle, or we need some other representation of strings. Experience with 8.1->8.3 shows that we ''need'' to have constant-time indexing of strings at least some of the time.

[AK]: Related to that, explore the use of [rope]s to represent strings.

[WJP]: Although UTF-32 nominally goes up to 32 bits, the Unicode Consortium has agreed not to go beyond 21 bits.
If alignment constraints are not a factor, one could use 3 bytes per character rather than 4.

[DKF]: Because tackling this also requires tackling unicode normalization, this project has ''difficulty: high''.
----
***Tk***

''Difficulty: easy (provided you know C)''
   * [[$photo put]] support of "" for transparent pixels
   * Another thing would be to contribute more image formats (e.g., [jpeg]2000 or MNG) or faster image reader code to [tkimg]; I'm sure that would be appreciated, and it could all be done by leveraging other open code (which mustn't be [GPL] for license reasons), which is a Summer-of-Code sort of thing to do.
   * Another nice GUI thing would be to add support for automatically animating a [GIF] to core Tk. In theory, it should be fairly simple to do using [after%|%timer events%|%], though I've no idea about how hard it is in practice. Right now, the animation has to be done manually, and without regard for the delays specified in the file.
''Difficulty: medium''
   * A full remapping of the plethora of [wm transient]/[wm state%|%state%|%]/parent/etc into [wm attributes] options
   * ([AM], 11 february 2009) "Better" communication with window managers/desktop environments like [Gnome] and [KDE]. Note: I am not sure what this should mean, but I conclude from a recent thread on c.l.t. (the [Ruby] report on GUI toolkits) that this might be an interesting area for improving Tk (probably in the form of an extension). Not sure what this would mean for [Windows] or [MacOS X].
   * Font fallback mappings
''Difficulty: hard''
   * Font alias control
   ** Understanding what needs to be done is the big challenge here
   * Support for named colors (similar to the existing named fonts, but potentially allow for things like patterns)
   ** See the draft [TIP] #154[http://tip.tcl.tk/154.html] for details/ideas.
   ** Difficulty is due to handling what happens when a named color is reconfigured (without breaking existing code) is the really tough problem here.
   * Move Tk's text widget towards supporting the full [CSS]2 box model (even if not with the same syntax, and definitely ''without'' the [HTML] parsing!) That would be useful for so many things.
   ** Difficulty is due to the complexity of the [text] widget.
----
***[Tcllib]***
''Difficulty: medium''
   * A nice and proper [IMAP] package. Could use the partial [imap4] module as starter, or not.
   * More [critcl]-based implementations for various modules (struct::{[matrix],[pool],[struct],[prioqueue],[disjointset],[skiplist]}, [aes], [des], [blowfish], etc.).
''Difficulty: hard (unless student already has experience with multiprocessing)''
   * ([AM], 11 February 2009) Support for multiprocessing — separate processes on the same or different machines cooperating via [tuplespace]s (see the relevant pages on the Wiki) or libraries like [MPI] (see [tmpi]).

'''General'''
   * [LV] Are there other packages, or semi-packages, present on this wiki that might be worthwhile having as a part of tcllib? A project might be for a student to work with the authors of said code to get things into shape for tcllib - writing docs, test suites, etc. Along with that, they might also be able to write test suites and/or docs as necessary for modules already present in tcllib
   ** Regarding the above, yes, very likely (example ideas: Machine-Learning, Clustering, Bayesian Reasoning, ...)

----
*** Tcl Core Byte Code***
   * Rework the engine to generate optimized bytecodes when features like [trace]s are '''not''' used. ''i.e.'' for code not using the extreme dynamicity of some tcl features we can generate simpler byte code, like keeping values on the stack instead of spilling to variables, etc.
   * Revamp the engine for native code generation or alternate virtual machines such as [LLVM] or [JVM].

The difficulty of these two projects is estimated to be '''very high'''; the student should have experience with bytecode engines ''before'' attempting them.

----
***Tklib***
   * ([AM], 11 february 2009) Easier-to-use [tree] widget?

[JSB] Do you mean [ttk::treeview] in the Tile set?  If so, I use it a good deal and think it's one of the easier to use Trees.  My opinion though.

[AM] Good to hear that, the thread I mentioned above mentions that Tk lacks a suitable tree widget, so I thought I'd copy that complaint. If it is good enough for most people, well, I was the delivery boy in this ;)

[LV] Lately there has been discussion about tktreectrl vs treeview vs what might really be an ''ultimate'' tree widget. What might be interesting as a summer project is for a student to do the requirements gathering and design work for a tree widget. While this might take the entire summer, it might very well produce the specifications needed for a project next summer to implement said widget.

[DKF]: Wrapping megawidgets round [tktreectrl] for common use cases would be a good thing. Apparently that's something that people have talked about for years. ''(Difficulty: medium even with a working megawidget framework due to the complexity of tktreectrl)''
----
***Tray TIP***
An implementation of [http://www.tcl.tk/cgi-bin/tct/tip/325.html%|%TIP #325].
   * ''Difficulty: easy'' for single platforms (due to existing code) but ''hard'' overall (developing for lots of platforms is awkward)

----
***Coverage Analysis***
   * [LV] making use of contemporary code coverage tools, and the existing Tcl and Tk test suites, determine how much of the existing code is covered by the current test suite, then, if time permits (and I would expect that it would), create a series of additional tests that would, when included, increase the coverage to at least 80%.

   * [LV] have a student write tutorials for tcl (and tk) covering introductory topics not yet covered by the tcl.sf.net tutorial or Mark Roseman's Tk tutorial. Perhaps even write a series of lessons for Clif Flynt's TclTudor based on Mark's work on the Tk tutorials.

----
***Bring all GIS-related stuff together***
[AM] The Wiki and [Tklib] contain all manner of bits and pieces to make a simple GIS with Tcl feasible. However, the utilities are scattered, there are quite complete but dedicated applications for displaying and manipulating geographical maps, but there does not seem to be a ready-to-use package of building blocks.

Such a package would hold:
   * Procedures to read files in popular GIS formats like ESRI shape files
   * Procedures to display maps and select layers 
   * Procedures to zoom in and zoom out
   * ...
----
***Improve Web Support***
   * Consolidate best practices from existing custom-built Tcl web servers into one multiplatform (unix/Microsoft windows/embedded) embeddable multithreaded application web server in pure Tcl - modular, supporting http/1.1 mechanisms like pipelining, caching, streaming data. Something like Mongrel for [Ruby] or Simple for [Java]. [wub] and [tclhttpd] should be considered in the plan.
   * Debug and fix poor [AOLserver] connection handling on oversaturated client links where Apache do it the right way
   * [nstcl]/nsdlib/mod_aolserver integration and tweaking AOLserver to allow it to be started from [tclsh]/[wish] as a [package require]
   * [[A]] webservice container (including a decent amount of security support infrastructure) as a [starkit]/[starpack] so I could just add services and key-pairs to make a full system, ready to go. That'd be really cool, and interesting to me in my professional capacity as well as my Tcl-hacker capacity.
----
***Improve Windows Support***
''Difficulty: hard (due to Win32 API complexity)''
   * Create full Tcl bindings for DDEML (Dynamic Data Exchange Management Library - MS Windows IPC used in many [SCADA]s). It will allow easy creation of data providers/consumers (dde servers/clients) doing for example serial communication with particular device type and [DDE] with HMI suide. What previously has to be accomplished by have commercial products.
   * Effective implementation of serial Tcl channel for Windows using overlapped I/O so handling of 50 or more serial ports in Tcl under [Windows] will be no more a problem for modern PC hardware
   * Building tool which can reliably run Tcl applications as MS Windows services. There are a few example code base to borrow best ideas [XYZNTservise]/[winserv]/[tclsvc]. Project should also emphasize slick user experience by enabling easy deployment with multithreaded [starkit]/[starpack] and showing application presence in system tray.
----
***Better IPC/Process Handling***
''Difficulty: medium-easy''
   * Add background exec ([BLT]'s [bgexec]) to core Tcl (there is some code for this)
''Difficulty: hard''
   * Process signalling ([[[pid] signal]])
   * Work on fine-grained locking/mutex issues in conjunction with `pthread_atfork` on [linux]/unix
----
***Exploring Tcl and [CUDA]***
[TV] I didn't check any mailing list or irc lately, but I thought I'd post a free suggestion here, though maybe that's more a engineering graduation project, depending on how it's done, of course: I'd think with good reason it's interesting to '''make a Tcl''' (not yet Tk) '''version which runs on [Cuda]''', the widely spread NVidia graphics card parallel computer with quite some horsepower. Like with [LISP] I'd think it may be possible to use [SWIG] as a first try, though honestly I don't know (means I lack the input or experience, I seem to recall compiling Tk 3D - OpenGL uses a swig binding) how good that would be for parallelization. I think two main paths could be at least investigated:

   1. Cuda computations for certain commands and variables (crude but working tryout: [Tcl on Cuda])
   1. full tcl or full tcl threads on cuda processors (probably exciting for PP freaks, even in limited, tryout implementation, and surely profitable for big computations)

----
***Other***
''Difficulty: unevaluated''
   * [BitTorrent] client in Tcl
   * Make [ZipVFS] fully writable/appendable
----
!!!!!!
%| [Category Community] |%
!!!!!!