!!!!!!
A part of [Google Summer of Code]. <<br>>[http://code.google.com/images/2010soclogo.jpg]
!!!!!!
----
[SEH]: The brainstorming starts now: [Project Ideas for Google Summer of Code 2011]
----
**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.  http://xmlvm.org/overview/%|%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 http://library.gnome.org/devel/gtk/2.16/Printing.html%|%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 http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/82a129b24002bb1a#%|%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 [http://tktable.git.sourceforge.net/git/gitweb.cgi?p=tktable/tile-qt;a=summary] and [http://tktable.git.sourceforge.net/git/gitweb.cgi?p=tktable/tile-gtk;a=summary]. 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.  http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2006-08/msg00675.html%|%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_Obj]`s) 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 [http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/f06c133517eaa20a#%|%here%|%], and some proposed solutions are [https://sourceforge.net/tracker/?func=detail&aid=2960042&group_id=10894&atid=110894%|%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 ([http://www.tcl.tk/cgi-bin/tct/tip/363]), 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 [expr]essions. 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 [http://ftcl.sf.net]). 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 http://wiki.tcl.tk/20832%|%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 http://wiki.tcl.tk/21777%|%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'''
<<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.

[WJG]This 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].

----

**http://openstreetmap.org%|%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. [GSoC 2009 Executed Projects%|%Improve GIS support in Tcl] by [Alexandros Stergiakis]
   2. [http://docs.activestate.com/activetcl/8.5/tcllib/map/map_slippy_fetcher.html%|%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 [namespace]s, [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 [dict]s 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 [http://sourceforge.net/projects/itclng/] and the command for building the dicts (itcldoc.tcl) and can be found here [http://itclng.svn.sourceforge.net/viewvc/itclng/itclng/]

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 [dict]s?)

----

**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 http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/cc8f015a89308421/89c71a2fd57c907e?#89c71a2fd57c907e%|%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 (this was partly implemented now)
 - tested with starkits 
 - not ported to MacOS X Aqua environment (most important for full cross-platform usage)

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
    * http://michael-aram.com/papers/xowikiscorm.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.

The client could include a macro facility (scriptable in Tcl, of course) that would allow new functionality to be added by aggregating existing Fossil features.

'''Benefits for studen'''t: 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 http://en.wikipedia.org/wiki/MapReduce%|%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 [coroutine]s 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.

----

**Ideas for next year**

These were raised after the project deadline, but can remain food for thought until next year.

***Build system for extensions***

[Mo Dejong]
One thing that really holds Tcl back as far as extensions go is the build process. It is simply too difficult to create Tcl C extensions because [autoconf] has a high learning curve, and it is very hard to have any confidence that any given set of build commands will actually work on other platforms. Python has a nice feature that lets an extension author build C code with the currently installed python. This should be a standard part of Tcl. All an extension author should need to provide is a list of the .h and .c files in the extension, then the build system should compile those files using the rules defined when Tcl itself was build on that platform. There is no viable solution to building Tcl and Tk without the autoconf tools due to the bootstrap issue, but there is no reason every extension author should have to create an autoconf based build and test on every platform. I would be interested in helping a student implement just such a project.

[stevel] Are you aware of [Critcl] and how it can be used to build extensions?  A simple example is on the [fork] page and many others are at [Critcl examples].  Sure, it isn't part of "the core" per se,  but Critcl is a self-contained [Starkit] that doesn't require Tcl/Tk to be installed on the build system. It can even cross-compile, building Windows extensions on a *nix platform.  Critcl can be used to build extensions in C, C++ and Fortran (see [Critcl goes Fortran] - useful when adding GUIs to legacy numerical programs).

[hat0] I think the more important idea is that of a single "blessed" method of building extensions, whether it's critcl or a separate (not autoconf-based) process.  A developer shouldn't have to download some extra stuff to build a simple extension.  (Do you want to push for critcl's inclusion in the core distribution?  if not, why not?)

[Lars H]: Note that there's a difference between ''building'' an extension and ''developing'' an extension. I believe building doesn't depend on autoconf being installed, since typically source distros typically come with pre-generated outputs (the configure and Makefile.in files) of autoconf, so "only" very standard Unix tools are needed. But if doing development (e.g. adding a source file) you need autoconf to regenerate those files.

Is Mo's point that the configure script shouldn't be needed either, on account of all the "intelligence" in that having been exercised already when Tcl/Tk itself was built, and that Tcl itself therefore should "know" how to perform builds for this platform and combination of configure flags? (A catch might be that it is not unusual to get a binary distribution of the core, but not of the extension in question.)

[hat0] Yes, I believe that is his concern.  I too was referring to developing extensions, not just compiling them.

<<categories>> Community