Re: [Gnu-arch-users] [BUG] feature plan -- version variables

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > >     > I'd imagine limiting it to ASCII until we make patchlogs utf-8.

    > > You're confused.

    > > You're talking about how a version variable value is written.

    > > I'm talking about what the version variable value may contain.

    > Well, maybe I was a little confused, but I prefer making the 
    > representation and contents the same, where possible, and if delaying 
    > utf-8 until it's available in the representation is necessary to do 
    > that, it suits me fine.

    > > (The reason for this restriction is not to control the contents
    > > of patch-logs but to simplify the C interface for manipulating these
    > > lisp-like values.   I don't want to drag in a dependency on a Unicode
    > > based interface just yet.)

    > If you make it iso-8859-1 now, you can't make it utf-8 later.  Restrict 
    > it to ASCII, and you don't have to decide now.

No, you are really somewhat confused.  It's on a subtle topic, though.

Here's the issue:  

There will be some external syntax for string values in version
variables.  We don't care about that for now --- that's a trivial
problem (the answer is that the external syntax is an ASCII-only
subset of Pika Scheme syntax).

There is some internal representation.   A string in a version
variable shows up in C as something like:

        struct a_string
        {
          size_t length;

          ______ * data;
        };

The question is what to fill in the "______" with and how to interpret
`data'.

For the initial implementation of this feature, I've chosen to fill
in the blank with `t_uchar' -- equivalent to `unsigned char'.
(Later, perhaps, I'll change that so that instead of `t_uchar *' 
the data is a `t_udstr' (hackerlab unicode string) or some such ---
but for now, it's just `t_uchar'.)

What do `t_uchar' values mean in this context?   We're pretty much
constrained that values 0..127 are ASCII characters.   

The only thing I've said with the restriction that string datums 
have to be ISO-8859-1 is that all of the `t_uchar' values in a string
datum are, in fact, Unicode code points.

Now, you could be saying "let's not specify what 128..255 mean in
those strings .... that way we can later say that they are UTF-8"
but that doesn't make sense in this context --- libhackerlab will
(soonishly) provide a different representation for Unicode strings.
There's no good reason to avoid saying, for now, that those are the
iso-8859-1 codepoints.




    > >     > Are those map semantics?  I'd imagine if the same name appears 
multiple 
    > >     > times, only the last assignment is used?  Or is it an error?

    > > Interesting question.

    > > I think the way to do it is:

    > > 1) `commit' and friends won't commit a changelog that sets the same
    > >    name twice.

    > > 2) When _reading_ a variable value, ./{arch}/++variables takes
    > >    precedence but if the variable isn't set there, and is set
    > >    twice in the most recent log entry, then that variable can't
    > >    be read.

    > >     > Care to specify a representation for lists, or do you think the 
list 
    > >     > user should chooose it?

    > > I have no idea what you mean.  Lists are written with parentheses.

    > Never mind, you clearly have (3 4 1) in mind as list format.

Ah.  Ok, you must have been thinking of version variable values as
strings-that-can-be-interpreted-otherwise.   No, this is actually
values as (a subset of) scheme datums.


    > >     >>   If the file ./{arch}/++variables exists then it should contain
    > >     >>   0 or more valid `set-in-version' log message headers -- these
    > >     >>   override the settings in the latest patch log entry.

    > >     > Is this file immortal, or is it deleted by commit/import?

    > > Probably deleted by commit/import but only after being copied into the
    > > log message.

    > (You meant "after the commit/import succeeds", right?)

(right)

    > > A related question is whether or not (or which) variable values should
    > > be copied from one branch to another by `tag'.

    > There are definitely some that should not be copied by 'tag', like 
    > branch-description or branch-class.  None that should be copied come to 
    > mind immediately.

Good point.   Yeah, I had been avoiding thinking about complex
inheritence rules thinking I'd just work those out when it came time
to implement this.


    > >     > Would this delete a version-var?
    > >     > % tla version-var name #f

    > >     > (Is there any difference between a false value and a missing 
value?)

    > > If a variable is _not_ set locally, then its value is determined by
    > > the most recent patch log entry.

    > Right, but is there a way of deleting version vars so that they no 
    > longer appear in the patch-log, or are you stuck with foo appearing in 
    > every patch-log even if it's set to #f?

Suppose a variable is locally set to #f.

Then there's no reason to record in the patch log at all when a commit
happens.   By omitting the variable from the patch log, you
effectively set its patch-log value to #f.

-t