pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pika-dev] Starting work on strings from the scm side


From: Andreas Rottmann
Subject: Re: [Pika-dev] Starting work on strings from the scm side
Date: Mon, 15 Mar 2004 22:58:51 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Tom Lord <address@hidden> writes:

>     > From: Andreas Rottmann <address@hidden>
>
>     > Matthew Dempsky <address@hidden> writes:
>
>     > > Andreas Rottmann <address@hidden> writes:
>
>     > >> Now that object locks are basically in place, I could go
>     > >> ahead and do the string wrapping, catching up to what jao
>     > >> has done on the hackerlab side. OK?
>
>     > > I began work on strings and added the string type, but I
>     > > haven't done any work on wrapping the hackerlab operations.
>     > > I think Tom has merged these, but I could be mistaken.
>
>     > I know of your --strings branch and also thought Tom merged that, but
>     > apparently he did only up to patch-12 (in his scm--devo--0.1--patch21).
>
>     > I think it should cause no trouble if I merge in your --string branch
>     > into a newly created --string branch, branched off my --integration
>     > branch. However, if you'd like to carry on doing string work, I can
>     > search some other place to hack around.
>
> Just from the arch perspective ---  this is a case where if you merge
> in Jivera's changes as a starting point we'll be violating "star
> topology" and slightly complicating merges.   But arch copes with that
> well enough so it's no big deal.   Do whatever helps you make best
> progress and I'll worry about integration.
>
Well, as we just talked on IRC, there probably is no need to merge the
missing bits, since they are not string-data-type relevant.

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]