On 29 December 2010 10:54, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 28, 2010, at 8:48 PM, Igor Stasenko wrote:
On 28 December 2010 19:04, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 28, 2010 at 8:47 AM, <pharo@googlecode.com> wrote:
Comment #3 on issue 3485 by stephane.ducasse: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485
The documented format is:
Timestampstrings can be of the form: Â Â Â Â Â Â Â Â <authorname><date><time>. Â Â Â Â Â Â Â Â <authorname><date> Â Â Â Â Â Â Â Â <date><time> Â Â Â Â Â Â Â Â <date><time><authorname> Â Â Â Â Â Â Â Â <date><authorname> Â Â Â Â Â Â Â Â <historical>
wow thats incredible..
can you add there support for:
<author-><time><-name><date>
cause i prefer this format for myself? :)
In fact I do not know where this information is coming from. May be johan when he tried to recover what was stored in the strings.
you mean that it was reverse-engineered to determine the specs for stamp field by looking at it? wow. :)
Says /who/? Â When I created all these timestamps to document a refactoring change there was no documented restriction on timestamps I could see. Â Why impose restrictions which have little value? Â Why needlessly break compatibility? Â That timestamp *contains useful information*. Â Why ban it?
Information is useful, if it can be understood by system , which can extract three distinct fields, like <author> Â <comment> <date&time> but when information looks like a soup where different things put in random order and random <historical> format, then it is just garbage.
Yes structuring a bit would help tool builders else forget it, all our tools will be try and error. I like that structure: <author> Â <comment> <date&time> it makes sense
Let me clarify, what i proposing. Entries like: ADPCMCodec methodsFor: 'private' stamp: 'zz (auto pragmas 12/08) 3/2/2004 07:58' should look like: ADPCMCodec methodsFor: 'private' author: 'zz' comment: 'auto pragmas 12/08' timestamp:'3/2/2004 07:58' and we can leave a potential for future extensions, by taking a message pattern which starts from #methodsFor: .... and store all keywords which follows it like 'author' 'comment' 'timestamp' in a dictionary, with key/value pairs. Also, it would be nice to simply evaluate this using smalltalk compiler, but doing a trick with substituting global name bindings like ADPCMCodec with proxies, which understand these messages. Then you will have a clean and extensible changeset/smalltalk source code reader. What could be simpler? -- Best regards, Igor Stasenko AKA sig.