Andy Tai | 7 Oct 08:56 2005
Picon

article on GNU Arch

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!

Eric W. Biederman | 8 Oct 21:03 2005

Re: article on GNU Arch

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

Mikhael Goikhman | 8 Oct 23:07 2005

New arch-magic releases are available

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)

Thomas Lord | 9 Oct 01:01 2005
Picon
Picon

re: sad events

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)

Thomas Lord | 9 Oct 04:42 2005
Picon
Picon

licensing clarification

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

Thomas Lord | 10 Oct 03:33 2005
Picon
Picon

a new project

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)

Andy Tai | 11 Oct 00:42 2005
Picon

Re: a new project

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!

Jan Hudec | 11 Oct 08:49 2005
Picon

Re: a new project

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)

Ludovic Courtès | 11 Oct 14:35 2005
Picon
Picon

Re: a new project

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

Thomas Lord | 11 Oct 17:48 2005
Picon
Picon

merging OpenOffice formats and the like

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)


Gmane