[Pharo-project] Issue 3485 in pharo: VMMaker does not load on Pharo 1.2
Status: Accepted Owner: laurent.laffont Labels: Milestone-1.2 New issue 3485 by laurent.laffont: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: dev Pharo core version: 1.2 beta2 Steps to reproduce: 1. Load VMMaker 2. RecentMessageList>>createTheMethodReference: fails for B3DAcceleratorPlugin>>#primitiveAllocateTexture as SourceReference>>parseTimestampFrom: 'ar (auto pragmas 12/08) 9/9/2000 15:50' fails as the timestamp cannot be parsed.
Comment #1 on issue 3485 by siguctua: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 <meta comment> i wonder how much time must pass for people to learn to not mix arbitrary text and well-formatted data (such as timestamp) in single field and then miserably fail attempt to parse it, or invent a incredibly complex and clever algorithms to extract this data.
Comment #2 on issue 3485 by stephane.ducasse: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 Yes may be we could add --// \\ this is an automated comment !! -- \\
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> So may the best is to republish a method with the correct timestamp.
Comment #4 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> So may the best is to republish a method with the correct timestamp.
Updates: Cc: Benjamin.VanRyseghem Comment #5 on issue 3485 by stephane.ducasse: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 (No comment was entered for this change.)
Comment #6 on issue 3485 by stephane.ducasse: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 Ok so how to we deal with methods not following the format in 1.2
Comment #7 on issue 3485 by stephane.ducasse: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 So apparently we should provide for 1.2 a way to load author SPACE commentn comment comment comment SPACE date and time (knowing that date and time will contain space but that may be we only get date.
Comment #8 on issue 3485 by johanbri...@me.com: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 - Improved the parser to return the epoch datetime whenever it cannot extract a timestamp - Timestamp is computed lazily instead of all the time (should improve performance of MethodReference whenever a timestamp is not needed) I have to check the fixes in a latest image again. Once that is done, I will tag this issue as fixed (but now I have to run... will do it later today) Attachments: SourceReferenceTimeStampParserFix.1.cs 4.7 KB
Updates: Status: Fixed Comment #9 on issue 3485 by johanbri...@me.com: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 Verified the attached changeset.
Updates: Status: Closed Comment #10 on issue 3485 by marcus.denker: VMMaker does not load on Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3485 12293
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>
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? If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community. best Eliot So may the best is to republish a method with the correct timestamp.
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? :)
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. Still, i agree it is useful, even in such messy form, but only to human reader, and unfortunately not to system, since it have no means to distinguish where this method comes from, who is author and what is datestamp of it. Would you like to query a system some day, like: 'show me all methods modified by Mr. Eliot Miranda in Dec 2010' ? If yes, then probably we should think about some formalism there. At least, please stop inventing new format types each other day, which will confuse already complex parser.
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
obviously, pharo can't impose any rules to projects which developed outside pharo.
best Eliot
So may the best is to republish a method with the correct timestamp.
-- Best regards, Igor Stasenko AKA sig.
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.
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
Still, i agree it is useful, even in such messy form, but only to human reader, and unfortunately not to system, since it have no means to distinguish where this method comes from, who is author and what is datestamp of it.
Would you like to query a system some day, like: 'show me all methods modified by Mr. Eliot Miranda in Dec 2010' ? If yes, then probably we should think about some formalism there. At least, please stop inventing new format types each other day, which will confuse already complex parser.
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
obviously, pharo can't impose any rules to projects which developed outside pharo.
best Eliot
So may the best is to republish a method with the correct timestamp.
-- Best regards, Igor Stasenko AKA sig.
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.
you mean that it was reverse-engineered to determine the specs for stamp field by looking at it? wow. :)
probably try and error trying to parse all the methods in the system.
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?
Sounds good and we need to handle not compliant methods. Next question is what do we do for 1.2. Because how can tools relying on time work? Finally point: I have more and more problem to get Timestamp a subclass of DateAndTime. It looks to me like Car inherits from Wheel. Stef
On 29/12/2010 10:14, Igor Stasenko wrote:
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'
Just out of curiosity is that date the third of February or the second of March 2004? ;)
El mié, 29-12-2010 a las 11:01 +0000, Douglas Brebner escribió:
On 29/12/2010 10:14, Igor Stasenko wrote:
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'
Just out of curiosity is that date the third of February or the second of March 2004? ;)
Or 07:58 in Paris time or California Time. That is not a good format. Even worse is trying to use the timestamps strings like a bad source code management. It was from a time when there were no SCM solutions for Squeak and they served their purpose. But now, the are obsolete. I think that they should have only *last* username (not initials, that is lame, too many collisions, not thinking about future users, imagine Linux kernel contributors using initials!), time stamp in UTC with timezone and not even free text. The core image that is not persisted in monticello can rely on timestamps to see who last edited some method, but the method internal comments are the place to point the comments, not the timestamps. For all the other code that have monticello packages, it is forbiden to even use the method timestamp to store something that seems like a comment. The comments are for the SCM or for the method comments, not for the method timestamps. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 29 December 2010 16:16, Miguel Cobá <miguel.coba@gmail.com> wrote:
El mié, 29-12-2010 a las 11:01 +0000, Douglas Brebner escribió:
On 29/12/2010 10:14, Igor Stasenko wrote:
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'
Just out of curiosity is that date the third of February or the second of March 2004? ;)
Or 07:58 in Paris time or California Time.
That is not a good format. Even worse is trying to use the timestamps strings like a bad source code management. It was from a time when there were no SCM solutions for Squeak and they served their purpose. But now, the are obsolete. I think that they should have only *last* username (not initials, that is lame, too many collisions, not thinking about future users, imagine Linux kernel contributors using initials!), time stamp in UTC with timezone and not even free text. The core image that is not persisted in monticello can rely on timestamps to see who last edited some method, but the method internal comments are the place to point the comments, not the timestamps. For all the other code that have monticello packages, it is forbiden  to even use the method timestamp to store something that seems like a comment.
The comments are for the SCM or for the method comments, not for the method timestamps.
if you would ask me, i'm also not in favor of having comments there.. but then what is this '(auto pragmas 12/08)' then, if not comment? Definitely its not an author's initials :)
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
-- Best regards, Igor Stasenko AKA sig.
The documented format is:
Timestampstrings can be of the form: <authorname><date><time>. <authorname><date> <date><time> <date><time><authorname> <date><authorname> <historical>
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?
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
Eliot we do not impose anything to the community. Please do not bash us we have enough to do without that! Apparently the code was like that and people (may be johan) started to make sense out of it. Stef
On Wed, Dec 29, 2010 at 1:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
The documented format is:
Timestampstrings can be of the form: <authorname><date><time>. <authorname><date> <date><time> <date><time><authorname> <date><authorname> <historical>
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?
If you *want* VMMaker to load in Pharo you need to ensure that Pharo
supports the timestamps *that exist* not the timestamps you want to impose on the community.
Eliot we do not impose anything to the community. Please do not bash us we have enough to do without that!
Steph, /I'm/ not bashing. I got bashed. Suddenly the comments I'd put in VMMaker were to be banned by Pharo. Look, the timestamp syntax if any, is defined by Utilities class>>changeStamp, along with the implicit restriction that the changeStamp can't contain an exclamation point, or it'll break parsing. Utilities class>>changeStamp is essentially anything followed by date and time, because there are /no/ restrictions on what one sets the Author initials to be (some people use full name, some people use initials, some people use put other stuff in there, but it's free apart from the $!). So to parse date and time one has to start at the end of the timestamp, go back two spaces and parse from there (ooh, difficult ;) ). There's no need for anything else. Why make life difficult for the community by imposing syntax when none existed before? All you'll do is make work and frustrate people. Is Pharo about helping or hindering? I think it's about helping, but the above syntax restrictions don't feel like that. KISS, right? If you want to find the date or time in a timestamp start at the end, and leave the beginning free from interpretation. 2¢
Apparently the code was like that and people (may be johan) started to make sense out of it.
Stef
Eliot johan is not that idiot. So far when I see what they built for their company this is more the inverse. He spent several days trying to figure out how to manage decently the source. I will check with him what they did but they probably tried to extract information from all the methods in the system. changeStamp "Answer a string to be pasted into source code to mark who changed it and when." ^ Author fullName , ' ' , Date today mmddyyyy, ' ', ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5) Now how can I identify a comment from a person and and action? Beginning until a space? date end until a space? We can do that. It looks like a hack to me. People are building tools to **help** us but if we push on them unstructured data then we push the shit on them. Let's take a simple example: benjamin smart, young student rewrote the recentMessage tools and the finder for fun. Now the state of MethodReference and its clunky use made something trivial just a big pain. I do not even talk about the change format which need scanner invocation to distinguish between a class def and a doit. So if we do not offer a good infrastructure we will be stuck for years with old tools. Some people do not like change at all but we value it for the better. On Dec 30, 2010, at 12:47 AM, Eliot Miranda wrote:
On Wed, Dec 29, 2010 at 1:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
The documented format is:
Timestampstrings can be of the form: <authorname><date><time>. <authorname><date> <date><time> <date><time><authorname> <date><authorname> <historical>
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?
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
Eliot we do not impose anything to the community. Please do not bash us we have enough to do without that!
Steph, /I'm/ not bashing. I got bashed. Suddenly the comments I'd put in VMMaker were to be banned by Pharo. Look, the timestamp syntax if any, is defined by Utilities class>>changeStamp, along with the implicit restriction that the changeStamp can't contain an exclamation point, or it'll break parsing. Utilities class>>changeStamp is essentially anything followed by date and time, because there are /no/ restrictions on what one sets the Author initials to be (some people use full name, some people use initials, some people use put other stuff in there, but it's free apart from the $!). So to parse date and time one has to start at the end of the timestamp, go back two spaces and parse from there (ooh, difficult ;) ). There's no need for anything else. Why make life difficult for the community by imposing syntax when none existed before? All you'll do is make work and frustrate people. Is Pharo about helping or hindering? I think it's about helping, but the above syntax restrictions don't feel like that. KISS, right? If you want to find the date or time in a timestamp start at the end, and leave the beginning free from interpretation.
2¢
Apparently the code was like that and people (may be johan) started to make sense out of it.
Stef
wow.... let me take a step back here. First of all, *nothing* was ever imposed nor banned. As far as I'm concerned, SourceReference is a work in progress and the timestamp format that it parses has been reconstructed using archeology over different sources. Going back 2 spaces and parsing from there is what I did at first but that soon proved to be *not* correct. Please see formats 2,4 & 5. I did not invent those formats but found them in the sources. It seems there are different formats out there and the goal was to extract timestamps from as many methods as possible. I'll improve the way it extracts timestamps and make a graceful fallback. Johan On 30 Dec 2010, at 10:38, Stéphane Ducasse wrote:
Eliot
johan is not that idiot. So far when I see what they built for their company this is more the inverse. He spent several days trying to figure out how to manage decently the source. I will check with him what they did but they probably tried to extract information from all the methods in the system.
changeStamp "Answer a string to be pasted into source code to mark who changed it and when." ^ Author fullName , ' ' , Date today mmddyyyy, ' ', ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)
Now how can I identify a comment from a person and and action? Beginning until a space? date end until a space?
We can do that. It looks like a hack to me.
People are building tools to **help** us but if we push on them unstructured data then we push the shit on them. Let's take a simple example: benjamin smart, young student rewrote the recentMessage tools and the finder for fun. Now the state of MethodReference and its clunky use made something trivial just a big pain. I do not even talk about the change format which need scanner invocation to distinguish between a class def and a doit. So if we do not offer a good infrastructure we will be stuck for years with old tools. Some people do not like change at all but we value it for the better.
On Dec 30, 2010, at 12:47 AM, Eliot Miranda wrote:
On Wed, Dec 29, 2010 at 1:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
The documented format is:
Timestampstrings can be of the form: <authorname><date><time>. <authorname><date> <date><time> <date><time><authorname> <date><authorname> <historical>
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?
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
Eliot we do not impose anything to the community. Please do not bash us we have enough to do without that!
Steph, /I'm/ not bashing. I got bashed. Suddenly the comments I'd put in VMMaker were to be banned by Pharo. Look, the timestamp syntax if any, is defined by Utilities class>>changeStamp, along with the implicit restriction that the changeStamp can't contain an exclamation point, or it'll break parsing. Utilities class>>changeStamp is essentially anything followed by date and time, because there are /no/ restrictions on what one sets the Author initials to be (some people use full name, some people use initials, some people use put other stuff in there, but it's free apart from the $!). So to parse date and time one has to start at the end of the timestamp, go back two spaces and parse from there (ooh, difficult ;) ). There's no need for anything else. Why make life difficult for the community by imposing syntax when none existed before? All you'll do is make work and frustrate people. Is Pharo about helping or hindering? I think it's about helping, but the above syntax restrictions don't feel like that. KISS, right? If you want to find the date or time in a timestamp start at the end, and leave the beginning free from interpretation.
2¢
Apparently the code was like that and people (may be johan) started to make sense out of it.
Stef
***Thanks*** johan. this is what I thought. Archeology over inconsistency. Stf On Dec 30, 2010, at 11:56 AM, Johan Brichau wrote:
wow.... let me take a step back here.
First of all, *nothing* was ever imposed nor banned. As far as I'm concerned, SourceReference is a work in progress and the timestamp format that it parses has been reconstructed using archeology over different sources.
Going back 2 spaces and parsing from there is what I did at first but that soon proved to be *not* correct. Please see formats 2,4 & 5. I did not invent those formats but found them in the sources. It seems there are different formats out there and the goal was to extract timestamps from as many methods as possible.
I'll improve the way it extracts timestamps and make a graceful fallback.
Johan
On 30 Dec 2010, at 10:38, Stéphane Ducasse wrote:
Eliot
johan is not that idiot. So far when I see what they built for their company this is more the inverse. He spent several days trying to figure out how to manage decently the source. I will check with him what they did but they probably tried to extract information from all the methods in the system.
changeStamp "Answer a string to be pasted into source code to mark who changed it and when." ^ Author fullName , ' ' , Date today mmddyyyy, ' ', ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)
Now how can I identify a comment from a person and and action? Beginning until a space? date end until a space?
We can do that. It looks like a hack to me.
People are building tools to **help** us but if we push on them unstructured data then we push the shit on them. Let's take a simple example: benjamin smart, young student rewrote the recentMessage tools and the finder for fun. Now the state of MethodReference and its clunky use made something trivial just a big pain. I do not even talk about the change format which need scanner invocation to distinguish between a class def and a doit. So if we do not offer a good infrastructure we will be stuck for years with old tools. Some people do not like change at all but we value it for the better.
On Dec 30, 2010, at 12:47 AM, Eliot Miranda wrote:
On Wed, Dec 29, 2010 at 1:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
The documented format is:
Timestampstrings can be of the form: <authorname><date><time>. <authorname><date> <date><time> <date><time><authorname> <date><authorname> <historical>
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?
If you *want* VMMaker to load in Pharo you need to ensure that Pharo supports the timestamps *that exist* not the timestamps you want to impose on the community.
Eliot we do not impose anything to the community. Please do not bash us we have enough to do without that!
Steph, /I'm/ not bashing. I got bashed. Suddenly the comments I'd put in VMMaker were to be banned by Pharo. Look, the timestamp syntax if any, is defined by Utilities class>>changeStamp, along with the implicit restriction that the changeStamp can't contain an exclamation point, or it'll break parsing. Utilities class>>changeStamp is essentially anything followed by date and time, because there are /no/ restrictions on what one sets the Author initials to be (some people use full name, some people use initials, some people use put other stuff in there, but it's free apart from the $!). So to parse date and time one has to start at the end of the timestamp, go back two spaces and parse from there (ooh, difficult ;) ). There's no need for anything else. Why make life difficult for the community by imposing syntax when none existed before? All you'll do is make work and frustrate people. Is Pharo about helping or hindering? I think it's about helping, but the above syntax restrictions don't feel like that. KISS, right? If you want to find the date or time in a timestamp start at the end, and leave the beginning free from interpretation.
2¢
Apparently the code was like that and people (may be johan) started to make sense out of it.
Stef
participants (7)
-
Douglas Brebner -
Eliot Miranda -
Igor Stasenko -
Johan Brichau -
Miguel Cobá -
pharo＠googlecode.com -
Stéphane Ducasse