Version 77 of Project Ideas for Google Summer of Code 2010

In case brainstorms strike as this year's projects progress.

Ideas from Last Year

These are things that weren't accepted then. See Project Ideas for Google Summer of Code 2009 for full descriptions.

GSoC Idea: Tk - Factor Photo Image Handling

Tcl: Better string sentence and title case handling
Tk: Demo Expansion
Tcllib: XLS Read/Write
Tcl Application Server
Tclhttpd: refurbish
Tk: Curses implementation of Tk
Tk: Icon Themes
Gnocl
Tk: Megawidget development
AOLserver: libpurple integration
Tcl[?]: FireFox Scripting and DOM access
Tcl[?]: Complete TclScript project for IE scripting
Tcl/Tk Browser Plugin: User-Privileged Security
Tcl/Tk Browser Plugin: OSX Port
Improving dotLRN
Tcl: Constraints
Tk: Drag-n-drop for Aqua
OpenScripting Tcl
Glade XML to Tk translator
Cicero refurbish

From Things holding Tcl back:

1. Printing support!
2. Add Drag and Drop support for Mac.
3. Support for more textured backgrounds in Tk and Tile on Mac. Pinstripe's terribly unfashionable. Ideally, we should be able to define our own background images.
4. Alpha transparency in widget backgrounds.
5. A KDE theme for Tile, incorporated in the base Tile download.
6. A Gnome theme for Tile, also incorporated in base Tile.

New suggestions:

1. Fix binary-support with low-level tempfile-creation API, so that 'exec ... << "$data"' doesn't fail with \0-bytes - very long overdue.

Tcl state machine back-end module for XMLVM

SEH: Instead of a previous XMLVM-related suggestion, this project would make Tcl a target for XMLVM bytecode output. XMLVM takes bytecode input from Java, .NET and Ruby, refactors it into a common format and generates stack-based state machines in Java, javascript, .NET, Python, etc. that can run the bytecode. The goal of this project would be to write a pure-Tcl state machine compatible with XMLVM output, thus adding Tcl to the list of XMLVM output target platforms.

Benefits for the student: learn about bytecode technology, XML, XSLT, XQuery, XPath. Writing a stack-based state machine is an excellent exercise for any computer science student, good for understanding basics of computer processing.

Benefits for community: Tcl acquires ability to run code written in other languages natively, thus adding another dimension to Tcl's utility as "glue." Tcl programmers can choose from a wider range of already-written code libraries without having to worry about compilation or existence of other language interpreters on ones OS of choice.

Gnocl

Its a good time to get involved with Gnocl. The major topic discussed regarding GSOC was the implementation of support from Glade generated XML UI description files. Well, that's pretty well complete now although there are other things worth working on. Gnocl support for native Gnome printing is there but incomplete, support for image manipulation is due for inclusion in the next major release due around Eastertime. Support for Cairo would be a nice project for anyone with the time on their hands. This would allow direct vector drawing onto any GdkWindow. Combine this with the forthcoming feature for the runtime allocation of widget properties for the gnocl::drawingArea widget provides the basis for a nice environment for Tcl/Gnocl megawidget development. Other package 'germs' waiting for TLC are OpenGL via the GtkGlext bindings, webkit and poppler bindings.The broader topic of print support for Tcl, certainly under Gnome, might be approached via the GtkPrintContext .

If some of these project suggestions don't make it into the GSOC programme, no matter, if anyone wants to develop their C/Gtk/Tcl programming skills then they can still contribute to Tcl/Gnocl development.

In terms of cross platform issues, the Gtk packages are available for Window and MacOS. Some help on porting the latest versions of Gnocl to to these platforms would be most welcome.

TkPath

Tkpath implements path drawing modelled after SVG. It is very flexible and reproduces all standard drawing canvas items. Features include: opacity, antialiasing, gradient fills, affine transformations, and fill rules. Backends include: CoreGraphics on MacOSX, GDI on Win32, GDI+ on WinXP, Cairo on X11, and Tk drawing as a fallback

TkPath is a powerful, yet not completed, extension to the tk canvas.

It could be an interesting idea to go further in this direction which allow to take advantages of the canvas with the power of TkPath new functions.

More information on status and needs of TkPath here . TkPath is currently abandonware, so the project could include grooming a new maintainer.

Themed Tk on Unix

PT Since the introduction of the theming engine into Tk in version 8.5 it is now possible to make Tk applications appear native on Windows and MacOSX. This is achieved by having the graphical elements of the Tk widgets (things like borders, backgrounds or indicators) be drawn using the native drawing functions. For instance on Windows XP and above the Tk vsapi style engine makes calls to the DrawThemeBackground() Windows API when drawing so that it always matches the users current desktop.

Unfortunately on X Windows we still have no real idea what 'native' really means. Maybe the user desktop is using KDE, maybe GNOME. There is no reliable way to find out but we can let the user configure a suitable theme using the *TkTheme XRDB resource. What we require to make Tk applications fit smoothly into X desktops is a ttk style engine that uses Qt or Gtk to do the drawing of the theme elements. In fact we do have an early version of this: tile-qt and tile-gtk originally done by G. Petasis and currently make TEA compatible and hosted in git repositories at SourceForge [L1 ] and [L2 ]. Both of these need work. tile-qt is working but incomplete and segfaults on exit. tile-gtk doesn't work at the moment.

A project to get these themes working properly should suit someone interested in Gtk and/or Qt development with Tk and a strong in GUI usability and design. A benefit of getting these working should yield a significant reduction in the amount of complaining from git users on unix that gitk and git-gui (both Tk applications) are ugly on that platform. Both have already been 'ttk-ified' - they just need suitable theme engines to make them pretty and to fit into the modern unix desktop. Ultimately this should benefit all Tk users, including Python Tkinter and any Perl/Tk users out there too.

hat0 Our very own Joe English wrote in 2006, "testing $KDE_FULL_SESSION and $GNOME_DESKTOP_SESSION_ID makes for a reasonable discriminant" for whether or not the user's running a gtk-based or qt-based desktop. quoted from here . So we can make a good guess at what "native" means that covers 95% of *nix users in 2010.

Computational geometry for glyph outlines

Lars H: Modern font technologies (TrueType/OpenType, SVG, Postscript Type 1) describe glyph graphics by parametrising the outlines. There are however at least one older font technology (MetaFont) and certainly many scripts (e.g. Chinese/Japanese/Korean) that rather view glyphs as composed from a number of intersecting pen- or brush strokes. A naive approach to generating glyph outlines would be to first parametrise the outline of each stroke in isolation and then compute the outlines of their union, but this has turned out to be difficult; the equation systems one has to solve are highly nonlinear, and often ill-conditioned, resulting in numerical instability. An alternative approach is to start with a 2D analogue of intervall arithmetic, and first describe the individual strokes using inner and outer bounding polygons. From computational geometry with these it is possible to compute the outline topology and also get a good approximation of which part of which stroke determines which section of the combined outline, thus avoiding most of the ill-conditioned problems.

A good first step towards realising the above programme would be to create a package (in Tcl, possibly later with some C accelleration if necessary) for computational geometry with polygons in the plane (probably through translation to the dual problem of arithmetic with circulations on geometric graphs) that also admits tagging vertices with information about "what gave rise to them". Such a package would be useful also for other things (polygon intersection being a trivial example).

Benefit for student: Learn about computational geometry, some graph theory.

Benefit for Tcl: Get a code library capable of computing with polygons.

Garbage Collection for Tcl Values

• Mentor: Donal Fellows
• Difficulty: Medium (C skills required)

Currently, memory allocated by the interpreter for Tcl values (Tcl_Objs) is reserved for recycling after the objects are destroyed; the memory is never freed until the interpreter exits (the “high-water-mark” model). This is fine if the volume of data your program handles is low and steady for the life of the interpreter or if the interpreter is relatively short-lived, but if a persistent program handles spikes of data volume, a very large percentage of the computer's RAM can be stuck in a reserved state: neither in use nor available for use by other non-object-creating actions of the language, not to mention out of reach of all other processes on the computer.

The objective of this project would be to write a garbage collector for unused Tcl objects. Memory reserved for Tcl objects would be periodically examined and excess memory freed. This would lead to Tcl making more efficient use of computer resources, this efficiency would complement Tcl's other strengths: its otherwise superb stability and economy.

A general discussion of the problem can be found here , and some proposed solutions are here .

Benefits for the student: learn about memory management and garbage collection, one of the most challenging fields for programmers.

Benefits for Tcl: Tcl would become more usable in a wide range of demanding usages, in the coming era of terabyte-scale data sets. Since just about all of the major dynamic languages suffer from similar limitations, Tcl would instantly distinguish itself as the superior choice in this field.

Parsing mathematical expressions

AM Mathematical expressions like those parsed by the [expr] command are not easily manipulated via Tcl commands. What I mean is, if I want to use complex numbers or add support for array expressions (see TIP 363 ([L3 ]), I can do that via Tcl's prefix notation:

   set sum [+ $op1 $op2]

or

   set dotp [inprod $vector1 $vector2]

That is okay for simple expressions, but when things get more complicated, like:

   set diffusion [expr {$diff*(2.0*$conck - $conckm1 - $conckp1)/$deltx**2}]

the prefix notation is cumbersome:

   set diffusion [vecmult $diff [vecdiv [vecsub [vecmult 2.0 $conck] $conckm1 $conckp1] [expr {$deltx**2}]]]

My idea is to make a small extension to convert expression from the mathematical infix notation to Tcl's prefix automatically. I currently have something that almost does the job, but it is still a fair amount of work to make it practical. You could even add extra functionality here, like the introduction of custom operations.

Benefits for the student: learn about parsing.

Benefits for Tcl: more flexibility in mathematical/physical applications.

Lars H: This is not so far from what the infix package does already, but I suppose you might want the extra speed of a C-coded parser (and a slightly nicer calling convention). One thing I've thought about is relation to these things is that one could make it possible to stash parsed/translated/compiled forms of expressions within the intRep of the Tcl_Obj of the expression, like Tcl does with its expressions. Or rather, I've though about whether it would be possible to expose such functionality at the script level. Currently infix stashes its "compiled code" in an array instead, which is a major reason why the calling convention is unintuitive…

AM Ah! I had forgotten about infix. Now, this is beginning to take the form of a not entirely trivial project, I'd say.

Lars H: How so? Having an existing codebase to make fully practical (perhaps even for a delimited field) seems less ambitious than getting something to work in the first place. Oh, you mean my idea about stashing things in Tcl_Objs? Yes, that's probably a separate project, and perhaps not one suited for GSOC. (Actually, I don't think it would be that much coding, but it would require a thorough understanding of the concepts.)

Sarnold: Did you check xsource? It is worth checking out, even if it has bugs remaining. AM Interesting, but at a first glance not quite what I am after. Lars's infix package comes closer, as it allows you to define what an operation actually means. But I will have a closer look ;).

Wrapping numerical libraries

AM As mentioned on the Tclode I have been playing with the idea to wrap a lot of existing numerical libraries (some written in the venerable FORTRAN 77 programming language, others in C). For C we have Critcl to facilitate the wrapping, for FORTRAN we can use my Wrapfort (in my ftcl project on SourceForge [L4 ]). The problem with many of these libraries is not so much the wrapping in itself, but the design of the interface.

For example, wrapping the LAPACK library (see wrapper extension for LAPACK) is a lot of work because there are so many routines. However, a lot of it can be automated (I have done that part already). The next step is to make the interface Tclish enough: The routines require the dimensions of arrays to be passed explicitly. If you map Tcl lists to arrays (or use byte arrays for efficiency), then the dimensions can be deduced from the data. So the interface exposed by the wrapper can be simpler.

A second part of the work is to package the source code with appropriate make files

Loading shared libraries from memory

A project to allow loading of libraries without recourse to a filesystem location was partially completed in GSoC 2008 GSoC 2008 . More work remains to be done on Linux, and Windows is yet to be tackled. Ability to do this would be very beneficial, so the project should be considered for revival. See here for description of work accomplished in the 2008 project.

Tcl FireFox Scripting and DOM access

• Colin McCormack
• Difficulty: medium-hard (but still an excellent project)

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
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
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.

WJGThis is an excellent proposal. Tcl is a great scripting language and the fruit of this project would, I'm sure, be worth the effort.

More mtmtcl structures

Lars H (not being very optimistic about the chances of finding a student with the relevant qualifications, but hey, we might get lucky): Mtmtcl is a collection of implementations of various mathematical structures, for example the ring of integers, the free abelian group (with arbitrary set of generators), and the semigroup algebra (for arbitrary semigroup and ring of scalars). So far, what is in there has been directed primarily by what I've needed for the computations I wanted to do, and consequently there are some gaps in its coverage even for rather elementary things. The project would then be to fill those in. Some possibilities are:

• Rational numbers
• More generally, the field of fractions of an arbitrary integral domain
• Finite fields (of non-prime order)
• Various groups, for example:
  • Matrix groups: GL(n), SL(n), O(n), U(n), SO(n), SU(n), …
  • Permutation groups
  • Some other finite group of particular interest (cyclic groups are already implemented, as recast to multiplicative notation of integers-modulo-n)
• Products of groups (the dihedral groups can be expressed as semidirect products of cyclic groups)
• Set of algebraic expressions
• Lattice of ideals (via Gröbner bases)

Some are easy and some are hard. The difficulty of the project can be varied to match the student.

Requirements: Some familiarity with (i) abstract algebra and (ii) LaTeX (for documenting the code).

Benefit for the student: Exposure to the computational side of algebra, which is often ignored in courses although it may help understanding the concepts. Experience of literate programming.

OpenStreetMap and related

The first part is a package(s) for handling OpenStreetMap data in convenient form, which will automatically translate between internal and XML forms, communicate with server, and give easy access to all objects. Also, it needs to have some abstraction to give ability to manipulate virtual ways, so-called segments, as suggested by somebody on IRC (#osm-ru@oftc).

The second part would be an OpenStreetMap editor in Tk, utilizing the package(s) from the first part, and the segmented approach.

Another option would be a stand-alone public transport routes editor, as currently editing routes is not an easy task, and it is not visualized enough.

Currently, there are some GIS-related packages for Tcl and Tk, some of them can be used in this project.

andrewshadoura 2010-03-17

AK Some references to related things.

1. Improve GIS support in Tcl by Alexandros Stergiakis
2. Access to slippy-based map tile servers , also http://docs.activestate.com/activetcl/8.5/tcllib/map/map_slippy.html , and http://docs.activestate.com/activetcl/8.5/tcllib/map/map_slippy_cache.html
3. The demo for http://docs.activestate.com/activetcl/8.5/tklib/canvas/canvas_sqmap.html is a map display using osm tiles.

Implement More Mikroconf Modules

MikroConf is a command line administration interface for Linux-based embedded systems, which can be easily extended with new administration modules written in the Tcl programming language. It is not only written 100% in Tcl, but also makes heavy use of certain Tcl features such as, Tcl threads, Safe interpreters, TclVFS, and others. It is thus a great advertisement for Tcl's capabilities.

Depending on his background, the student should pick at least three of the following modules ideas to implement, except for the case of routing, which is a project on its own:

• vlan: VLAN configuration using busybox vconfig applet.
• ppp: Support PPPoE, PPPoA, PAP, CHAP using pppd, so that it is possible to configure ADSL gateways.
• serial: Support communication through serial lines.
• tunnel: Support various (encrypted/unencrypted) tunnel technologies, using vtun, stunner, and other programs.
• qos: QoS, Traffic Shaping.
• routing: Dynamic routing using quagga. Integration with quagga should be done on a C-API level, just like Quagga shells communicate with Quagga daemons.
• ddns: Dynamic DNS using dyndns.
• vrrp: VRRP support using vrrpd.
• dhcp: DHCP Server using busybox's udhcpd applet.
• dns: DNS Server using dnsmasq.
• nat: SNAT/DNAT configuration using iptables.
• firewall: Support for access-lists and prefix-lists using iptables.
• snmp: Basic SNMP configuration (read-only) using net-snmp.
• wireless: Wireless configuration using wireless-tools.
• bridge: Layer 2 bridging configuration using busybox's brctl applet.

Mentor: Alexandros Stergiakis Difficulty: Easy/Medium depending on selected modules.

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 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 DKF: I want more megawidgets, 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 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 that are more Tk (or perhaps more Ttk?) like.

DKF: Tk 8.6 has a small core for megawidgets that is used to drive the core of the iconlist widget (used in the Unix version of tk_getOpenFile).

Wub + OpenACS + TDBC

Wub is a showcase technology for Tcl with its speed and use of coroutines. OpenACS is also a Tcl success story, but it is limited on one end by AOLServer and on the other by dependence on Oracle/PostgreSQL. The goal of this project would be to enable an alternative (nearly) pure-Tcl OpenACS stack and replace the specific database dependencies with TDBC, which would ease install and deployment, and enable use of OpenACS modules in a wider range of contexts. Project steps would consist of:

1. Comparing Wub and AOLServer for performance and suitability for hosting OpenACS modules
2. If Wub is found suitable, writing bridge code/APIs to allow Wub to serve OpenACS modules
3. Replacing OpenACS code that specifically targets Oracle and Postgres with TDBC interface code, making it possible to choose any database with a TDBC driver

These steps could comprise one or several individual student projects.

Benefit for student: get experience with web technology and performance testing, high-demand database technology, threading.

Benefit for community: leverage strong but under-utilized code base with cutting-edge new Tcl innovations, and vice versa. Liberate OpenACS code to be used in new contexts. Make it easier to create and deploy new custom OpenACS configurations.

The nstcl project may be relevant for this. Also, a similar partially-executed project is described at http://www.jsequeira.com/projects/portable.nsd/

CMcC asides that since TDBC requires tcl8.6, one means of satisfying the community benefits of this project would be to treat it as a software archeology and restoration projecct: take those bits of OpenACS which work well, and rewrite them to (1) provide a more abstract interface to the underlying web facilities (much as TDBC provides an abstract DB layer), (2) use tcl8.6 facilities (I'm thinking dict, here for representing data.) The first would liberate the useful facilities for broader use, the second would probably make the code cleaner than it is now. It's the same project, really, but turned inside-out.

sisusimple thinks another way round: is it possible to make a library for TCL of AOLserver? Benefit: mature http server, easier integration with other TCL code.

SEH: Wub is pure Tcl. AOLServer is a mix of Tcl and C, and thus presents issues of portability, maintainability and deployability. One of the goals of this project would be to make OpenACS more portable and deployable. It might be interesting to see if one could turn AOLServer into a stubs-enabled loadable library. But I think that would be a separate project.

Auto Documentation Tool for Tcl

• Mentor: Arnulf Wiedemann
• Difficulty: easy

apw There are some Tcl tools for doing javadoc like documentation using inline comments with special tags like tcldoc, autodoc and zdoc. The problem of all of these is, that they only support "normal" Tcl programs. What is missing is support for namespaces, itcl or itcl-ng and TclOO.

I have started building a Tcl program called itcldoc.tcl based on a script level version of itcl-ng called itclng to use the parser available there for the itcl syntax and by adding some more parsing routines for "normal" Tcl code, namespace eval code and TclOO code. This program is used to parse all the variables, commons, methods, procs and comment blocks which are placed before that kind of code as well as references to variables and store them in dicts on a file level base. With that parsed information html pages could be built to show cross reference listings, descriptions of code or the source code with mixed in links for variables, procs, methods etc. when they are referenced or called in the code.

The itclng project can be found here [L5 ] and the command for building the dicts (itcldoc.tcl) and can be found here [L6 ]

Benefit for student: learn a lot about Tcl and its possibilities to parse different kind of source code as well as get experience in generating html code for web pages eventually using ATWF.

Benefit for community: provide an up-to-date tool for auto documentation (and maybe also a base for debugging tools based on these dicts?)

Continue BLT Library Refactoring

Last year, a student project partially refactored the BLT library, making it compatible with modern Tcl releases. Much work remains, as described here :

 RBC is: 
 - BLT's vector, graph, barchart,  stripchart, winop, and eps components 
 - TEA compliant 
 - 3800+ automated test suite, plus many more manual tests 
 - Works (for me) on win32, linux 32 bit and linux 64 bit, Tcl/Tk 8.4, 8.5, and 8.6beta. 

 RBC is not (yet): 
 - documented 
 - experienced 
 - beautiful (see pkgIndex.tcl for an example) 
 - free from Tcl/Tk internals 
 - including Zoom-Stack 
 - tested with starkits 

The Refactored BLT Components page has more information and link to project page containing work done so far.

SCORM Compliant Run-Time Environment for OpenACS

• Mentor: Gustaf Neumann
• Difficulty: low to high (depending on the number of met requirements)

OpenACS is a powerful open source community system used for a wide set of application ranging from e-learning (DotLRN) over community site to e-commerce shops. The xo*-family of packages (xotcl-core, xowiki and xowf) has established itself as a flexible, generic, object oriented toolkit for OpenACS, enabling rapid development of arbitrary applications for both OpenACS and DotLRN. XoWiki is one of the most flexible wiki-frameworks, supporting advanced concepts like for example structured wiki features, multiple access policies, flexible application integration and workflows. In the e-learning context, XoWiki can be used as a single tool for content development for (adaptive) content presentation, (collaborative) content development, blog style content distribution and assessment.

SCORM is a collection of standards and specifications adapted from multiple sources to provide a comprehensive suite of e-learning capabilities that enable interoperability, accessibility and reusability of Web-based learning content.

This project is a follow-up project to last year's successful project "SCORM Compliant Content Packaging for Wiki-based Content Development", which focused on input/export and presentation of SCORM learning resources. During the last project, it turned out that implementing the runtime environment specified by the standard is a relatively big task. Thus, in the current state, the runtime environment makes use of the most basic RTE-API functions and is therefore only capable for importing simple packages. However, a standard conformant runtime Environment is still a precondition for using the outcome of the former project in real-world scenarios.

Goal

The main goal of this project is an implementation of a SCORM compliant Run-Time Environment (RTE) for OpenACS/DotLRN.

Minimum Requirements

• The Runtime environment should be "SCORM Version 1.2 Run-time Environment Conformant – Minimum (LMS–RTE1)", as defined in the SCORM Conformance Requirements Document

Optional Requirements

• Reaching Conformance Level “SCORM Version 1.2 Run-Time Environment Conformant – Minimum with Some Optional Data Model Elements (LMS-RTE2)"
• Reaching Conformance Level “SCORM Version 1.2 Run-Time Environment Conformant – Minimum with All Optional Data Model Elements (LMS-RTE3)"
• SCORM 2004: LMS RTE 1.1 – The LMS complies with the requirements defined in the SCORM 4th Ed. Run-Time Environment Version 1.1

Base materials and links

• http://www.adlnet.gov/Technologies/scorm/default.aspx
• http://media.wu-wien.ac.at/download/xowiki-doc/
• http://nm.wu-wien.ac.at/research/publications/b766.pdf
• Paper: SCORM Compliant Content Packaging for Wiki-based Content Development

Requirements for the student High motivation, experience with SCORM, OpenACS, DotLRN, XOTcl.

Benefits for the student

Gaining experience with e-learning standards, object oriented web 2.0 development frameworks and systems integration.

Benefits for the community

Users of the community framework OpenACS are provided with flexible means to launch (i.e. "play") learning content from other e-learning systems such as Moodle. http://wiki.tcl.tk/23190

Create Free-standing Slate Widget

Difficulty: easy-medium

slate is a sophisticated object-oriented widget for authoring interactive graphs and hierarchies, which uses the Tk canvas as a support base. It was developed as part of the Tycho project, now abandoned. It would be worthwhile to extract the slate code from the overall Tycho codebase, update it for modern Tcl/Tk compatibility, and submit it to Tklib.

The slate wiki page describes a previous partial attempt to do just this. This project would take up where it left off, or use it for guidance in a wholly new effort.

If any time is left over, the student could examine the Tycho codebase for more code gems (of which there are many), identify them and extract them in a similar way.

Benefits for the student: learn object-oriented programming and design patterns as they apply to GUI development and graph theory. Graph theory is an important concept for areas such as decision flow, software modeling, hardware IC design, etc.

Benefits for the community: Acquire powerful old/new widget that leverages new TclOO feature to provide a tool for graphing applications.

Fossil Tk Client

• Mentor: Steve Landers
• Difficulty: Medium

The Fossil distributed software configuration management system is used in many Tcl-based projects. It's ease of installation and use, and comprehensive features making it an attractive alternative to the more complex systems like Git and Mercurial.

Although Fossil comes with a built-in web interface, the objective of this project is to make a Tk-based GUI interface, and in doing so kill several birds with the one stone (so to speak)

• a Tk GUI that could be more feature-rich than the web interface
• SSL support (via TLS)
• a Fossil Tcl extension based on the Fossil source but wrapped with Critcl to produce a scriptable fossil library
• Starkit deployment as a single file executable

One of the existing Tk GUI's (such as TkCVS/TkSVN or GiTk) should be used as a basis, and the first part of the project would be a review of these programs and an assessment of their suitability.

SSL support already exists in the Fossil server and Unix clients, but building the SSL-enabled Fossil client on Windows has proven problematic. So this project, if successful, is likely to achieve wide visibility amongst the Windows Fossil users.

Benefits for student: Gain experience in reviewing and evaluating existing programs, learn about Tk programming and User Interface and User Interaction Design, learn about Distributed Software Configuration Management, learn about interfacing to C libraries via Critcl, learn about simple crypto concepts via TLS, learn about Starkit deployment.

Benefits for Tcl: Provide an improved GUI interface on all platforms for the many Tcl projects already using Fossil, and an easy to deploy SSL-enabled client on Windows in particular.

Controlling (numerical) computations and simulations

AM This is just a haphazard description of an idea that has been pestering me for some time now.

Imagine this situation:

• You have a couple of programs that each do their job fine, but the one needs results from the other, possibly in a feedback loop
• You can transform these programs into libraries instead of distinct programs and that may help to bring them together in a more modern way
• A Tcl layer on top can then be used to control how often, and in which order these programs or libraries will run

Here is a more tangible example:

• Program 1 simulates the physical environment, say, a river and its delta
• Program 2 simulates the economy of the region (houses are built, roads are constructed, there is waste water to take care of ...)
• Program 3 is an expert system that evaluates the economical activities and their impact on the environment and sets up a set of measures

These three programs will interact, but they also work on different time scales - the physical environment will have a time scale of days, where the time scale of economy is more typically months or years. You can build a static program that controls these three programs and make sophisticated input facilities to experiment with the various options (how often to invoke program 1 before invoking program 2 for instance), but it would be more flexible to do so with a high-level program written in a Tcl-based domain-specific language.

This is just the sort of applications I like to think about - there are many other areas where similar tasks have to be combined in smart and flexible ways.

Benefits: to be added

MapReduce Algorithm Using Scripted Channels and Threads

SEH: Tcl's new reflected channel feature makes it possible to create and manipulate channels entirely within the interpreter, without recourse to the network layer. This feature allows a channel to be opened with one communicating end in one interpreter, and the other end in another. Furthermore, the two interpreters may be in separate threads, thus enabling a method for exchanging data between threads.

This makes it possible to envision a multicore-friendly processing environment in which a "master" interpreter manages a central repository of data in memory, which it parcels out to independent processing threads on demand, via scripted channel interactions. This is just the framework needed to execute a mapReduce distributed computing architecture.

MapReduce is a leading technique for parallel computing, which has become an important field in the current multi-core hardware world. The purpose of this project would be to use Tcl's threads and scripted channel features to create a pure-Tcl framework for executing mapReduce-based algorithms.

I would suggest that coroutines might play a role in executing this project, but I don't understand enough about them to know if that would be appropriate or practical.

Benefit for the student: learn about parallel computing, one of the most significant topics in computing today, as well as channel and threading concepts.

Benefit for community: despite the acknowledged importance of parallel computing, it is widely agreed that available tools are not adequate to write software that takes full advantage of modern multi-core and cloud computing environments. A simple and stable parallel execution architecture would leverage some of Tcl's latest and best features and offer an opportunity for Tcl to take a leading role in the field.