Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1503053004:
Move messages out of dart2js. (Closed)
|
Created:
5 years ago by floitsch Modified:
5 years ago CC:
reviews_dartlang.org, Brian Wilkerson Base URL:
git@github.com:dart-lang/sdk.git@master Target Ref:
refs/heads/master Visibility:
Public. |
DescriptionMove messages out of dart2js.
The format of the shared messages is still valid Dart, but it is restricted, so that a JavaScript parser can easily parse it.
R=johnniwinther@google.com
Committed: https://github.com/dart-lang/sdk/commit/e802e26d7b1b6379097c8317d161b073e60fe8be
Patch Set 1 #
Total comments: 5
Patch Set 2 : Address comments. #Patch Set 3 : Fixes #Patch Set 4 : Merge. #
Total comments: 4
Messages
Total messages: 17 (3 generated)
floitsch@google.com changed reviewers: + johnniwinther@google.com
Proposed approach. Currently the shared file is still inside dart2js, but I would move it into its own package. I ended up keeping it a Dart file, since that simplifies things. For instance, the dummy-compiler-test would need to be changed if it had to find a file somewhere. However, the structure in the file is severely restricted, so that parsing it is simpler. I already started on a JavaScript parser that can read that file. In the long run, we should move all dart2js messages to the shared one. Note: I have added a random ID to every message, but I think we will want to have several messages with the same ID (and then use a sub-id to differentiate).
lgtm https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... File pkg/compiler/lib/src/diagnostics/messages.dart (right): https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... pkg/compiler/lib/src/diagnostics/messages.dart:416: MessageKind.ASSERT_IS_GIVEN_NAMED_ARGUMENTS: "ASSERT_IS_GIVEN_NAMED_ARGUMENTS", Long line. More below. https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... File pkg/compiler/lib/src/diagnostics/shared_messages.dart (right): https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... pkg/compiler/lib/src/diagnostics/shared_messages.dart:56: // An INFO message should always be preceded by a non-INFO message, and the I'm not sure INFO should be a part of the shared messages; or in other words: they should not have an ID since the are only part of another message.
I'm running all the tests now. It takes a *long* time. I will have to check tomorrow, if I slowed down the compiler. https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... File pkg/compiler/lib/src/diagnostics/messages.dart (right): https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... pkg/compiler/lib/src/diagnostics/messages.dart:416: MessageKind.ASSERT_IS_GIVEN_NAMED_ARGUMENTS: "ASSERT_IS_GIVEN_NAMED_ARGUMENTS", On 2015/12/08 09:18:27, Johnni Winther wrote: > Long line. More below. I used dartfmt to format the file. There are a few other changes now, but they don't look too bad, so I kept them. done. https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... File pkg/compiler/lib/src/diagnostics/shared_messages.dart (right): https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... pkg/compiler/lib/src/diagnostics/shared_messages.dart:56: // An INFO message should always be preceded by a non-INFO message, and the On 2015/12/08 09:18:27, Johnni Winther wrote: > I'm not sure INFO should be a part of the shared messages; or in other words: > they should not have an ID since the are only part of another message. I removed that comment from the shared file. At the moment I don't know how to detect what an INFO message is. We can add that comment back, when we migrate one of those messages.
lgtm https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... File pkg/compiler/lib/src/diagnostics/shared_messages.dart (right): https://codereview.chromium.org/1503053004/diff/1/pkg/compiler/lib/src/diagno... pkg/compiler/lib/src/diagnostics/shared_messages.dart:56: // An INFO message should always be preceded by a non-INFO message, and the On 2015/12/09 08:42:40, floitsch wrote: > On 2015/12/08 09:18:27, Johnni Winther wrote: > > I'm not sure INFO should be a part of the shared messages; or in other words: > > they should not have an ID since the are only part of another message. > > I removed that comment from the shared file. At the moment I don't know how to > detect what an INFO message is. > We can add that comment back, when we migrate one of those messages. DiagnosticReporter.reportInfo is deprecated. Info messages are now part of a DiagnosticMessage which is the one that should have an ID.
I agree that info-messages shouldn't need an ID. Since the addition of ids was automatic, I suggest that we remove them from info messages when we migrate them to the shared file. Clearly, IMPORT_PART_HERE doesn't make sense if it isn't used in combination with IMPORT_PART_OF. We should either move the info message into the data-map of IMPORT_PART_HERE or find another way to show this relationship.
Description was changed from ========== Move messages out of dart2js. The format of the shared messages is still valid Dart, but it is restricted, so that a JavaScript parser can easily parse it. ========== to ========== Move messages out of dart2js. The format of the shared messages is still valid Dart, but it is restricted, so that a JavaScript parser can easily parse it. R=johnniwinther@google.com Committed: https://github.com/dart-lang/sdk/commit/e802e26d7b1b6379097c8317d161b073e60fe8be ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) manually as e802e26d7b1b6379097c8317d161b073e60fe8be (presubmit successful).
Message was sent while issue was closed.
sigmund@google.com changed reviewers: + sigmund@google.com
Message was sent while issue was closed.
https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the first two in [template] and the last in [howToFix]. It would be good to add a guideline also on what to do when moving a message from here to shared.dart. For example: - keep the old entry here - add an extra field "deprecated" that indicates the forwarding ID in the shared location https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', What's the benefit on using the random sequence for the ID rather than a number? How do we generate a new unique sequence when adding a new message to ensure there are no collisions with messages in any other tool? I initially had in mind to use a pair: area + number, for example: ['dart2js', 42], ['shared', 1], ['analyzer', 31]. So adding at the end of a file becomes pretty trivial.
Message was sent while issue was closed.
https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the first two in [template] and the last in [howToFix]. On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > It would be good to add a guideline also on what to do when moving a message > from here to shared.dart. For example: > - keep the old entry here > - add an extra field "deprecated" that indicates the forwarding ID in the shared > location Agreed. Once we know what and how to move we should update the comment. https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > What's the benefit on using the random sequence for the ID rather than a number? > How do we generate a new unique sequence when adding a new message to ensure > there are no collisions with messages in any other tool? I initially had in mind > to use a pair: area + number, for example: ['dart2js', 42], ['shared', 1], > ['analyzer', 31]. So adding at the end of a file becomes pretty trivial. Personally I prefer IDs (although 6 might be too short). There can't be an area, since the whole goal is to have shared messages. If we prefixed messages with "dart2js" and the analyzer gave the message, it would look really bad. We could just increment the numbers, but then all users of the messages must make sure that they don't collide (including users within the same team). Unique IDs also have a higher chance to yield unique Google results. "Error XQSRXO" has a higher chance of finding the exact error than "Error 400441". I believe that we will need "subids" though: "Error XQSRXO-1" All this is not set in stone, though.
Message was sent while issue was closed.
On 2015/12/10 01:21:15, floitsch wrote: > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the first > two in [template] and the last in [howToFix]. > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > It would be good to add a guideline also on what to do when moving a message > > from here to shared.dart. For example: > > - keep the old entry here > > - add an extra field "deprecated" that indicates the forwarding ID in the > shared > > location > Agreed. > Once we know what and how to move we should update the comment. > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > What's the benefit on using the random sequence for the ID rather than a > number? > > How do we generate a new unique sequence when adding a new message to ensure > > there are no collisions with messages in any other tool? I initially had in > mind > > to use a pair: area + number, for example: ['dart2js', 42], ['shared', 1], > > ['analyzer', 31]. So adding at the end of a file becomes pretty trivial. > > Personally I prefer IDs (although 6 might be too short). > There can't be an area, since the whole goal is to have shared messages. If we > prefixed messages with "dart2js" and the analyzer gave the message, it would > look really bad. My idea with the prefix was only to use area-specific prefixes while the message was not shared and used only by that tool. As soon as it moved to a shared place, it would use "shared" as the prefix. > We could just increment the numbers, but then all users of the messages must > make sure that they don't collide (including users within the same team). > Unique IDs also have a higher chance to yield unique Google results. > "Error XQSRXO" has a higher chance of finding the exact error than "Error > 400441". I like that. We could also make sure all ids start with something that will make it clear for engines how to search it (e.g. DARTMSG_323344) > > I believe that we will need "subids" though: "Error XQSRXO-1" > > All this is not set in stone, though. So I'm still not clear on what's the process to generate a new ID. Is the plan to have an id-generator we should all use or do we make something up every time? How do we guarantee that it is unique?
Message was sent while issue was closed.
On 2015/12/10 01:34:44, Siggi Cherem (dart-lang) wrote: > On 2015/12/10 01:21:15, floitsch wrote: > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the > first > > two in [template] and the last in [howToFix]. > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > It would be good to add a guideline also on what to do when moving a message > > > from here to shared.dart. For example: > > > - keep the old entry here > > > - add an extra field "deprecated" that indicates the forwarding ID in the > > shared > > > location > > Agreed. > > Once we know what and how to move we should update the comment. > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > What's the benefit on using the random sequence for the ID rather than a > > number? > > > How do we generate a new unique sequence when adding a new message to ensure > > > there are no collisions with messages in any other tool? I initially had in > > mind > > > to use a pair: area + number, for example: ['dart2js', 42], ['shared', 1], > > > ['analyzer', 31]. So adding at the end of a file becomes pretty trivial. > > > > Personally I prefer IDs (although 6 might be too short). > > There can't be an area, since the whole goal is to have shared messages. If we > > prefixed messages with "dart2js" and the analyzer gave the message, it would > > look really bad. > > My idea with the prefix was only to use area-specific prefixes while the message > was > not shared and used only by that tool. As soon as it moved to a shared place, > it would use "shared" as the prefix. > > > We could just increment the numbers, but then all users of the messages must > > make sure that they don't collide (including users within the same team). > > Unique IDs also have a higher chance to yield unique Google results. > > "Error XQSRXO" has a higher chance of finding the exact error than "Error > > 400441". > > I like that. We could also make sure all ids start with something that will make > it clear for engines how to search it (e.g. DARTMSG_323344) Yes. We can definitely add our own mix to it. > > > > > I believe that we will need "subids" though: "Error XQSRXO-1" > > > > All this is not set in stone, though. > > So I'm still not clear on what's the process to generate a new ID. Is the plan > to have an id-generator we should all use or do we make something up every time? > How do we guarantee that it is unique? Yes. That's why 6 characters is probably not enough. (I just didn't want to go overboard). We could probably stick to 6 characters and just have an assert that there aren't two messages with the same id.
Message was sent while issue was closed.
On 2015/12/10 01:40:08, floitsch wrote: > On 2015/12/10 01:34:44, Siggi Cherem (dart-lang) wrote: > > On 2015/12/10 01:21:15, floitsch wrote: > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the > > first > > > two in [template] and the last in [howToFix]. > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > It would be good to add a guideline also on what to do when moving a > message > > > > from here to shared.dart. For example: > > > > - keep the old entry here > > > > - add an extra field "deprecated" that indicates the forwarding ID in the > > > shared > > > > location > > > Agreed. > > > Once we know what and how to move we should update the comment. > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > What's the benefit on using the random sequence for the ID rather than a > > > number? > > > > How do we generate a new unique sequence when adding a new message to > ensure > > > > there are no collisions with messages in any other tool? I initially had > in > > > mind > > > > to use a pair: area + number, for example: ['dart2js', 42], ['shared', 1], > > > > ['analyzer', 31]. So adding at the end of a file becomes pretty trivial. > > > > > > Personally I prefer IDs (although 6 might be too short). > > > There can't be an area, since the whole goal is to have shared messages. If > we > > > prefixed messages with "dart2js" and the analyzer gave the message, it would > > > look really bad. > > > > My idea with the prefix was only to use area-specific prefixes while the > message > > was > > not shared and used only by that tool. As soon as it moved to a shared place, > > it would use "shared" as the prefix. > > > > > We could just increment the numbers, but then all users of the messages must > > > make sure that they don't collide (including users within the same team). > > > Unique IDs also have a higher chance to yield unique Google results. > > > "Error XQSRXO" has a higher chance of finding the exact error than "Error > > > 400441". > > > > I like that. We could also make sure all ids start with something that will > make > > it clear for engines how to search it (e.g. DARTMSG_323344) > Yes. We can definitely add our own mix to it. Ah. I think I misunderstood your comment. If we prefix with a special token, and just count the errors, we would have a unique Google friendly error. That would work too. But you would still need to coordinate whenever you want to add a new message. > > > > > > > > > I believe that we will need "subids" though: "Error XQSRXO-1" > > > > > > All this is not set in stone, though. > > > > So I'm still not clear on what's the process to generate a new ID. Is the plan > > to have an id-generator we should all use or do we make something up every > time? > > How do we guarantee that it is unique? > Yes. That's why 6 characters is probably not enough. (I just didn't want to go > overboard). > We could probably stick to 6 characters and just have an assert that there > aren't two messages with the same id.
Message was sent while issue was closed.
On 2015/12/10 01:41:37, floitsch wrote: > On 2015/12/10 01:40:08, floitsch wrote: > > On 2015/12/10 01:34:44, Siggi Cherem (dart-lang) wrote: > > > On 2015/12/10 01:21:15, floitsch wrote: > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): > > > > > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine the > > > first > > > > two in [template] and the last in [howToFix]. > > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > > It would be good to add a guideline also on what to do when moving a > > message > > > > > from here to shared.dart. For example: > > > > > - keep the old entry here > > > > > - add an extra field "deprecated" that indicates the forwarding ID in > the > > > > shared > > > > > location > > > > Agreed. > > > > Once we know what and how to move we should update the comment. > > > > > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': 'VYNMAP', > > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > > What's the benefit on using the random sequence for the ID rather than a > > > > number? > > > > > How do we generate a new unique sequence when adding a new message to > > ensure > > > > > there are no collisions with messages in any other tool? I initially had > > in > > > > mind > > > > > to use a pair: area + number, for example: ['dart2js', 42], ['shared', > 1], > > > > > ['analyzer', 31]. So adding at the end of a file becomes pretty trivial. > > > > > > > > Personally I prefer IDs (although 6 might be too short). > > > > There can't be an area, since the whole goal is to have shared messages. > If > > we > > > > prefixed messages with "dart2js" and the analyzer gave the message, it > would > > > > look really bad. > > > > > > My idea with the prefix was only to use area-specific prefixes while the > > message > > > was > > > not shared and used only by that tool. As soon as it moved to a shared > place, > > > it would use "shared" as the prefix. > > > > > > > We could just increment the numbers, but then all users of the messages > must > > > > make sure that they don't collide (including users within the same team). > > > > Unique IDs also have a higher chance to yield unique Google results. > > > > "Error XQSRXO" has a higher chance of finding the exact error than "Error > > > > 400441". > > > > > > I like that. We could also make sure all ids start with something that will > > make > > > it clear for engines how to search it (e.g. DARTMSG_323344) > > Yes. We can definitely add our own mix to it. > Ah. I think I misunderstood your comment. > If we prefix with a special token, and just count the errors, we would have a > unique Google friendly error. > That would work too. But you would still need to coordinate whenever you want to > add a new message. I might be missing something - I fear that with the random XYZ chars we will need to coordinate too. Or are you saying that with XYZ we have a lower chance of colliding than when using counters, so we can deal with it when the assertion fails, but otherwise there is nothing to do? Another way to coordinate could be to have a shared file with the next available number (and we have have a test that validates that this is true). Then every CL that adds messages can update this file. Two concurrent changes will always conflict before submitting, so developers will know they have to pick a new number in that case. > > > > > > > > > > > > > I believe that we will need "subids" though: "Error XQSRXO-1" > > > > > > > > All this is not set in stone, though. > > > > > > So I'm still not clear on what's the process to generate a new ID. Is the > plan > > > to have an id-generator we should all use or do we make something up every > > time? > > > How do we guarantee that it is unique? > > Yes. That's why 6 characters is probably not enough. (I just didn't want to go > > overboard). > > We could probably stick to 6 characters and just have an assert that there > > aren't two messages with the same id.
Message was sent while issue was closed.
On 2015/12/10 01:52:16, Siggi Cherem (dart-lang) wrote: > On 2015/12/10 01:41:37, floitsch wrote: > > On 2015/12/10 01:40:08, floitsch wrote: > > > On 2015/12/10 01:34:44, Siggi Cherem (dart-lang) wrote: > > > > On 2015/12/10 01:21:15, floitsch wrote: > > > > > > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > > File pkg/compiler/lib/src/diagnostics/dart2js_messages.dart (right): > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:59: // combine > the > > > > first > > > > > two in [template] and the last in [howToFix]. > > > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > > > It would be good to add a guideline also on what to do when moving a > > > message > > > > > > from here to shared.dart. For example: > > > > > > - keep the old entry here > > > > > > - add an extra field "deprecated" that indicates the forwarding ID in > > the > > > > > shared > > > > > > location > > > > > Agreed. > > > > > Once we know what and how to move we should update the comment. > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1503053004/diff/60001/pkg/compiler/lib/src/di... > > > > > pkg/compiler/lib/src/diagnostics/dart2js_messages.dart:81: 'id': > 'VYNMAP', > > > > > On 2015/12/10 01:05:30, Siggi Cherem (dart-lang) wrote: > > > > > > What's the benefit on using the random sequence for the ID rather than > a > > > > > number? > > > > > > How do we generate a new unique sequence when adding a new message to > > > ensure > > > > > > there are no collisions with messages in any other tool? I initially > had > > > in > > > > > mind > > > > > > to use a pair: area + number, for example: ['dart2js', 42], ['shared', > > 1], > > > > > > ['analyzer', 31]. So adding at the end of a file becomes pretty > trivial. > > > > > > > > > > Personally I prefer IDs (although 6 might be too short). > > > > > There can't be an area, since the whole goal is to have shared messages. > > If > > > we > > > > > prefixed messages with "dart2js" and the analyzer gave the message, it > > would > > > > > look really bad. > > > > > > > > My idea with the prefix was only to use area-specific prefixes while the > > > message > > > > was > > > > not shared and used only by that tool. As soon as it moved to a shared > > place, > > > > it would use "shared" as the prefix. > > > > > > > > > We could just increment the numbers, but then all users of the messages > > must > > > > > make sure that they don't collide (including users within the same > team). > > > > > Unique IDs also have a higher chance to yield unique Google results. > > > > > "Error XQSRXO" has a higher chance of finding the exact error than > "Error > > > > > 400441". > > > > > > > > I like that. We could also make sure all ids start with something that > will > > > make > > > > it clear for engines how to search it (e.g. DARTMSG_323344) > > > Yes. We can definitely add our own mix to it. > > Ah. I think I misunderstood your comment. > > If we prefix with a special token, and just count the errors, we would have a > > unique Google friendly error. > > That would work too. But you would still need to coordinate whenever you want > to > > add a new message. > > I might be missing something - I fear that with the random XYZ chars we will > need to coordinate too. Or are you saying that with XYZ we have a lower chance > of colliding than when using counters, so we can deal with it when the assertion > fails, but otherwise there is nothing to do? Yes. 6 is on the low end (giving us maybe a 1 in 100 chance of collision). An assert should be good enough to catch this. > > Another way to coordinate could be to have a shared file with the next available > number (and we have have a test that validates that this is true). Then every CL > that adds messages can update this file. Two concurrent changes will always > conflict before submitting, so developers will know they have to pick a new > number in that case. I'm sure we could find ways to coordinate, I just prefer not needing to. > > > > > > > > > > > > > > > > > > I believe that we will need "subids" though: "Error XQSRXO-1" > > > > > > > > > > All this is not set in stone, though. > > > > > > > > So I'm still not clear on what's the process to generate a new ID. Is the > > plan > > > > to have an id-generator we should all use or do we make something up every > > > time? > > > > How do we guarantee that it is unique? > > > Yes. That's why 6 characters is probably not enough. (I just didn't want to > go > > > overboard). > > > We could probably stick to 6 characters and just have an assert that there > > > aren't two messages with the same id.
Message was sent while issue was closed.
On 2015/12/10 00:35:06, floitsch wrote: > I agree that info-messages shouldn't need an ID. > Since the addition of ids was automatic, I suggest that we remove them from info > messages when we migrate them to the shared file. > > Clearly, IMPORT_PART_HERE doesn't make sense if it isn't used in combination > with IMPORT_PART_OF. We should either move the info message into the data-map of > IMPORT_PART_HERE or find another way to show this relationship. Agreed |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
