Hello Andrew,

When line ends with just the baud rate field as fo rexample in 2:280/127, MakeNL addes a trailing comma when it is not there:

Pvt,127,Trapgate_Test,Brunssum,Frans_Lupschen,-Unpublished-,300,

It does not add a trailing comma, when the baud rate is not the last field.

FTS-5000 allows the trailing comma, but does not require it.

Any remaining fields from position eight (8) onward are flag
fields. Note there may or may not be a trailing comma after
Field 7 if there are no flags listed.

I think MAkeNl should not forcefully add a trailing comma. It should also not remove it when it is present in the submitted segment. It should just pass it "as is" in the case that field seven is the last field.

In Zone 2 we have the odd situation that the R28 segment that I edit does not have the trailing comma. When I run it trough MakeNl, it adds the comma. I submit it to the ZC, who runs it through a filter (ERRFLAGS) that removes the trailing comma. It reports it as an error. And then the ZC's MakeNl puts the comma back in....

We could make it an option, but just not touching the trailing comma would be fine with me.


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
* Origin: http://www.vlist.eu (2:280/5555)

Hello Kees,

On Monday June 30 2014 17:23, you wrote to me:

MvdV>> I think MAkeNl should not forcefully add a trailing comma. It
MvdV>> should also not remove it when it is present in the submitted
MvdV>> segment. It should just pass it "as is" in the case that field
MvdV>> seven is the last field.

In order to to get makenl_ng accepted by all ZC's, it had to behave
as the original makenl.

It /has/ been accpeted by all ZCs. So thathurdle has been taken. And I have already seen one ZC expressing a preference for a change.

The above behaviour is in complience with this aim.

If dropping 100% drop-in compatibility with the old MakelNl is a show stopper, we can do as we have done before: make it an option that has the old behaviour as the default.

We have however already crossed the line. What is in use now by the ZC's is not
how the old MakeNl behaved. What is in in use now allows "-Unpublished-" without the Pvt or Hold keyword. Plus a few other things.

Strict drop-in compatibilty was desirable in the transition phase form the old to the new MakelNl. But now that at least all ZC's use the new NakeNl, as probably a large fraction of the RCs and NCs, we can drop that.


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On Sunday July 06 2014 19:45, you wrote to me:

FTS-5000 allows the trailing comma, but does not require it.

Effective with v3.4.4 (committed to CVS today), MakeNL will no longer
add a trailing comma after the baudrate field when there are no flags listed.

Great!

I think MAkeNl should not forcefully add a trailing comma. It
should also not remove it when it is present in the submitted
segment. It should just pass it "as is" in the case that field
seven is the last field.

Due to the design of the program, this is difficult to achieve.

OK.

In Zone 2 we have the odd situation that the R28 segment that I
edit does not have the trailing comma. When I run it trough
MakeNl, it adds the comma. I submit it to the ZC, who runs it
through a filter (ERRFLAGS) that removes the trailing comma. It
reports it as an error. And then the ZC's MakeNl puts the comma
back in....

When the 3.4.4 version is released, this situation will be eliminated.

Indeed, so the problem is de facto solved.

I note, however, that FTS-5000 allows the trailing comma, so ErrFlags
is broken if it flags that as an error.

From a purely technical POV I agree.

OTHO, the whole idea of ERFLAGS - frowned upon by some, I know - is to be stricter than the FTSC. It started as a cleanup filter for frivolous user flags
and it evolved into a general error checker/corrector. But I think this is not
the place tod discus that.

We could make it an option, but just not touching the trailing
comma would be fine with me.

The change I have made will no longer add one that is not there, but
it will also strip one that is. Given the number of nodes presently existing with no flags, I don't see this as a high priority at this
time.

I can live with it. So thanks and keep up the good work. ;-)


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On Sunday July 06 2014 19:45, you wrote to me:

Effective with v3.4.4 (committed to CVS today), MakeNL will no longer
add a trailing comma after the baudrate field when there are no flags listed.

Is there a WIN32 .exe available and if so, where can I get it?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Andrew,

On Monday July 28 2014 18:40, you wrote to me:

Effective with v3.4.4 (committed to CVS today), MakeNL will no
longer add a trailing comma after the baudrate field when there
are no flags listed.

MvdV>> Is there a WIN32 .exe available and if so, where can I get it?

I am in the process of testing to make sure nothing else was broken by
the changes. I can send you a test .EXE; but I ask that you not distribute it further until a release is made.

Got it, applied it to the R28 segment and it works as expected. No trailing comma for 2:280/127.

Keep up the good work!


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Kees,

On Wednesday July 30 2014 12:04, you wrote to me:

MvdV>> Got it, applied it to the R28 segment and it works as expected.
MvdV>> No trailing comma for 2:280/127.

MvdV>> Keep up the good work!

Are you aware that implementing this option, will create difficulties
for those who build their Nodelist from the previous list and a diff.

I don't see the problem. As far as diff processing is concerned, removing or adding a comma is no different than any other change in the nodelist.

It will only work if all convert to this option at the same time.

Why? I used to send R28 segments to Ward with a trailing comma at 280/127. From
now on I send an R28 segment to Ward without the trailing comma for 280/127. The latter is now processed by without Ward's ERRFLAGS flagging it a s an error.

What will go wrong next Friday when the diff is processed?

Blowing this problem away with: "there is no need to use diffs as the full list is small enough", is not a solution.

As I see it, there is no problem.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Kees,

On Wednesday July 30 2014 14:57, you wrote to me:

MvdV>> I don't see the problem. As far as diff processing is
MvdV>> concerned, removing or adding a comma is no different than any
MvdV>> other change in the nodelist.

My fault, I transposed the adding of the comma, to diff-processors

OK.

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)