Likely mentor: Anthony Sorace Skills: HTML, C (or another suitable language), possibly JavaScript Project size: Medium Difficulty: Medium Expected outcome: Web application providing a tree comparison
The LXR project has created some very useful tools for cross-referencing different source trees. This idea has been productively expanded by FXR to compare across operating systems (FXR includes various BSDs, Linuxes, and an old Plan 9 tree). As Plan 9 evolves, it would be very useful to tree maintainers to have an easy way to find, track, and explore differences between trees. This project would be to provide tools to scan different source trees (at least the final Bell Labs tree, 9legacy, 9atom, and 9front; possibly Inferno, Plan 9 from User Space, and others) and allow users to see specific changes, perhaps including changes over time.
Your proposal should describe the interface you're thinking about providing (file server? web application?), what you think some of the important issues are, and clearly define the scope of work (for example, will you be doing multi-way diffs, or just 1-to-1 comparisons?). Multiple Plan 9 sites would be happy to host the results of this work.
We estmate ths project at medum size and difficulty for a more conventional FXR-like web-based interface, and a bit harder and larger if you want to define a flesystem-based interface. Your proposal should include a rough outline of your ideas for that part if you intend to include it.
Note that porting the existing FXR or LXR are almost certainly not good starting points.
Likely mentor: Skip Tavakkolian, Anthony Sorace Skills: C or Go Project size: Medium Difficulty: Medium Expected outcome: 9p server
Write a 9P file server that can be instructed to create a file tree and associate each node with external directories, files or processes. A good starting point would be to use the proto(2) format (hence the name) as used by mkfs(8) and others, although there are some obvious useful extensions for this application. Very roughly, the prototype file tree instructions might look something like:
/ fst/ = /usr/fst/www/ edit/ snarf > /dev/snarf paste < /dev/snarf mouse | fd0rw /dev/mouse
Your application should describe the set of extensions you think would be useful, and ideally your plan for adding those in after first establishing a working base model.
This should be a relatively easy project, although it could be a bit more complex depending on the specific extensions you support.
Likely mentor: Paul Lalonde & Rob Kroeger Skills: Go Project size: Large Difficulty: Medium (High if including all three) Expected outcome: Modifications to Edwood to support colored text in windows
Edwood is a text editor based on Plan 9’s acme user interface and programmable interface, rewritten in Go to allow more agile extension. Like acme, edwood is limited to monochrome and mono-font text representations. It allows changing the font on a per-window basis. It does not support any text coloring. This project is to extend edwood with three new interconnected features:
These together should allow external programs to manage syntax coloring, for example. A stretch goal would be to connect established syntax coloring processors to edwood through its synthetic file system interface. Part 1 will require modifying edwood’s text buffer representation to include an attribute per character. A policy will be required to determine what attributes newly inserted text should inherit from surrounding text. Part 2 will require modifying libframe to support color attributes. Part 3 will require developing an interface to compactly communicate the attributes of the visible portion of the text.
| Last modified Wed Jan 31 15:55:16 PST 2024 | [ Current version | Changelog | Create a new page ] |
About the server
|
|