This may be of interest... An article on tla http://www.freesoftwaremagazine.com/free_issues/issue_08/intro_tla/ Andy Tai, atai <at> atai.org Free Software: the software by the people, of the people and for the people! Develop! Share! Enhance! Enjoy!
Andy Tai <atai <at> gnu.org> writes: > This may be of interest... > > An article on tla > > http://www.freesoftwaremagazine.com/free_issues/issue_08/intro_tla/ Wow what a publishing delay. Eric
This message is meant to inform of the availability of new archzoom, axp, archway and arch-perl releases. These projects implement a web-based, a command-line-based and a GUI front-ends to Arch. Various bug-fixes and new features were implemented. The latest tla and baz versions are better supported now. For the release notes, see: http://migo.sixbit.org/software/arch-magic/release-notes-20051008 Further information, source tarballs and rpms are available from the project home pages: http://migo.sixbit.org/software/archzoom/ http://migo.sixbit.org/software/axp/ http://www.nongnu.org/archway/ http://migo.sixbit.org/software/arch-perl/ The Future of arch-magic ------------------------ The latest events are sad. It seems that neither Tom Lord nor Canonical are interested in developing Arch anymore. And noone yet volunteered as the new maintainer. In any case, the arch-magic users and distributions that package arch-magic projects will continue to get support. We will continue to fix bugs and support new versions of tla and baz (if any). The code base is quite good, so it may eventually find a life in new projects. However, there are currently no plans to switch to another(Continue reading)
Michael Goikhman writes: > The latest events are sad. It seems that neither Tom Lord nor > Canonical are interested in developing Arch anymore. And noone yet > volunteered as the new maintainer. Let me expand on, perhaps even change my position about that. Negatives, and then positives. The negatives: ~ I am not interested in continuing as an official GNU Maintainer I have too many political differences with RMS about the proper handling of the GNU project and so I do not think I can represent the project's values and policies well enough to be a maintainer. *Of course* I agree about the importance of software freedoms and will do my best to always chose GPL-compatible free software licenses but those points of agreement are insufficient, in my opinion, to also stand as a public interface to an official GNU project. ~ I am not interested in running a "fashionable" public free software project. I've taken no end of heat from vocal members of the Arch mailing lists about such things as whose patches and bug reports I spend time on and when. Often the implicit threat, and actual effect, has been "Do our bidding or we trash your professional reputation."(Continue reading)
I wrote: *Of course* I agree about the importance of software freedoms and will do my best to always chose GPL-compatible free software licenses but those points of agreement are insufficient, in my opinion, to also stand as a public interface to an official GNU project. The phrase "GPL-compatible" is too weak. I will chose a GPL-compatible *copyleft* (i.e., similarly viral) license whenever I can, usually the GPL itself. I can *imagine* very obscure circumstances when I would do otherwise but I don't expect them to come to pass. -t
One way to help advance the cause of distributed revision control
is to facilitate a greater number of applications that can make good
use of it. In that direction:
Contents:
* The Goal: "Human Friendly Application Documents" (HFADs)
** What is an HFAD?
** The Most Well Known Example of an HFAD
** Envisioned Applications ** The Technical Goals
* Solution Theory -- LALR(1) Recursive Decomposition Parsing
** Illustrations
** Performance
* Implementation Strategy
* How to Help
* The Goal: "Human Friendly Application Documents" (HFADs)
The goal of this project is to create software tools for implementing
"human friendly application documents" (HFADs).
** What is an HFAD?
An HFAD is a plain-text format for structured data, designed
for
~ readability and editability
The syntax should have a natural appearance -- the structured
data should be presentable as one human might present it
to another, even though it must also be readable by programs.
(Continue reading)
Well, in a related note, are there any solutions to revision control of common documents (say these in the Microsoft Word format (now commonly accesible by free software) or in the new Opendocument format)? If a revision control system can efficiently allow diff'ing of such documents in their native formats, and is free software, that will be extremely useful. However, I am not sure of any that exists right now. --- Thomas Lord <lord <at> emf.net> wrote: > One way to help advance the cause of distributed > revision control > is to facilitate a greater number of applications > that can make good > use of it. In that direction: > Andy Tai, atai <at> atai.org Free Software: the software by the people, of the people and for the people! Develop! Share! Enhance! Enjoy!
On Mon, Oct 10, 2005 at 15:42:51 -0700, Andy Tai wrote: > Well, in a related note, are there any solutions to > revision control of common documents (say these in the > Microsoft Word format (now commonly accesible by free > software) or in the new Opendocument format)? If a > revision control system can efficiently allow diff'ing > of such documents in their native formats, and is free > software, that will be extremely useful. However, I > am not sure of any that exists right now. OpenOffice is able to diff documents. However, it can only show the differences interactively (y marking them and/or walking over them). I am not sure it could be used for reconstructing the other document either. The opendocument format is a zipped archive of some XML and other stuff (images in jpeg or png etc.). An XML diff exists and the rest is just expanding it to a directory for taking the diff. So writing a diffing tool for it should not be all that hard. I am not avare that anyone did though. > --- Thomas Lord <lord <at> emf.net> wrote: > > > One way to help advance the cause of distributed > > revision control > > is to facilitate a greater number of applications > > that can make good > > use of it. In that direction: > > >(Continue reading)
Hi, Andy Tai <atai <at> gnu.org> writes: > Well, in a related note, are there any solutions to > revision control of common documents (say these in the > Microsoft Word format (now commonly accesible by free > software) or in the new Opendocument format)? If a > revision control system can efficiently allow diff'ing > of such documents in their native formats, and is free > software, that will be extremely useful. However, I > am not sure of any that exists right now. Tools such as OpenOffice.org Writer include versioning tools specifically tailored for their document format[0]. This allows users to view ``semantic diffs'', i.e. changes to the document itself, not to its underlying representation. Similarly, Lisp-like languages could greatly benefit from a tailored diff format, an ``sexp-diff''. According to Google, it seems that MzScheme already has an implementation of this. Thanks, Ludovic. [0] http://www.openoffice.org/dev_docs/source/features.html
The idea of XML diffing for applications like OpenOffice worries me a bit: Such diffing/merging algorithms can either be generic -- they operate on any two or three XML trees -- or application specific, tuned for a specific schema. If generic, we'd expect them to work pretty well for very minor differences (e.g., someone rewords a couple of paragraphs) but fail gracelessly for larger changes. Naively done, a merge could produce output which is not valid to the application: it might fail to conform to the schema or, even if that bug is avoided, might produce far coarser conflict reports than one would like (e.g., "Sure, there are only 20 changed words in these five pages but all the application can say is `these 5 pages conflict'.") If application-specific, and we'd like all our personal productivity apps to have these "teamware" capabilities, then conjuring up format-specific diff/merge tools is yet another thing (like component architectures, configuration subsystem hooks, etc.) which every application is supposed to have. What tends to happen with such architectures is that many applications either don't have those parts at all or have them in a poor form. That state of affairs is *slowly* corrected over time in response to perceived demand but then only that the cost of considerable bloat in the overall stack. You get enough such "just one more thing" features that well-behaved applications are supposed to have and pretty soon you have an intractable system.(Continue reading)
RSS Feed1 | |
|---|---|
4 | |
5 | |
1 | |
1 | |
2 | |
1 | |
3 | |
8 | |
11 | |
5 | |
38 | |
13 | |
28 | |
16 | |
10 | |
4 | |
10 | |
18 | |
18 | |
1 | |
25 | |
27 | |
12 | |
28 | |
80 | |
67 | |
145 | |
77 | |
109 | |
244 | |
146 | |
204 | |
282 | |
180 | |
174 | |
148 | |
141 | |
171 | |
282 | |
419 | |
313 | |
153 | |
191 | |
674 | |
775 | |
1459 | |
857 | |
994 | |
833 | |
1056 | |
996 | |
1240 | |
872 | |
1183 | |
1199 | |
788 | |
1364 | |
2145 | |
984 | |
1853 | |
970 | |
815 | |
274 | |
1085 | |
832 | |
1392 | |
911 | |
464 | |
368 | |
5 |
