Version 49 of Project Ideas for Google Summer of Code 2010

Updated 2010-03-23 12:25:07 by apw
A part of Google Summer of Code. http://code.google.com/images/2010soclogo.jpg

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.

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: Factor Photo Image Handling
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 bytecode frontend module for XMLVM

XMLVM [L1 ] is an experimental modular compiler that takes bytecode from various input modules, casts it into a standard XML bytecode format, then retargets the standardized bytecode to various output platforms. Current bytecode inputs are Java, .NET and Ruby. Current outputs are Java, .NET, Javascript, Python, Objective C, C++.

The goal of the proposed project would be to create an input module for Tcl bytecode.

DKF: I don't think this is a good idea. Tcl uses a different model of values and different model of variables to those other languages, so you'd only be able to do the targeting with the aid of a substantive support library…

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 [L2 ] and [L3 ]. 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

SEH: Right now, 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. This is fine if the volume of data your program handles is low and steady for the life of the interpreter, but if the 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 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 ([L4 ]), 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 [L5 ]). 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

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

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 which are more Tk (or perhaps more Ttk?) like.

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

Auto Documentation Tool for Tcl

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 [L6 ] and the command for building the dicts (itcldoc.tcl) and can be found here [L7 ]

Benefit for student: learn a lot about Tcl and it's possibilities to parse different kind of source code as well as get experience in generating html code for web pages

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

Category Community