Hello Andrew!

In the last few years it has come in vogue create daily nodelist.
In order to accomplish this, the PUBLish <DAY> has to be changed every day.
Although it is not difficult o use some form of scripting to accomplish
this, it would be more convenient if "PUBLish" TODAY could be used in the
control file. For those who want to make the file one day in advance
(before 24:00) "TOMORROW" would also be a usefull publishing day.

I have had a look at the code, and applied the following patch:

---8<------------------------------------------------------------------------ diff -r makenl_ng/makenl-code/src/config.c makenl_fg/makenl-code/src/config.c 399a400,401

{"TODAY", 3, 7},
{"TOMORROW", 3, 8},

798a801,810

}
time(&thetime);
mytime = localtime(&thetime);
if (NewExtWDay == 7)
NewExtWDay = mytime->tm_wday;
{
}
if (NewExtWDay == 8)
NewExtWDay = mytime->tm_wday + 1;
{

---8<-------------------------------------------------------------------------

When using this patch, it is of importance, that

in the files section of the controlfile wilcards are used.

Region 28 region28.* 2:28/0

If the wildcard is omitted, only files of the same publishing day will
be looked for. When not found, older files published on the same weeday wil
be used. (There is aworkaround, but that is not relevant here).

I am not completely happy with how the wild card operates. It probably sorts the files by their suffix and uses the highest number.

How this works out at the changeover from one year to the next may be implemented in makenl, but I am not shure.

It would suit me better if files were sorted by creation date like in
"ls -t ". If such a construct would work for all the versions that exits is questionable.

I hope that the main users would like the above patch to be included in
the mainstream version of makenl_ng. When the keywords TODAY and TOMORROW are not used, the code is just idle.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi Kees,

On 2017-11-23 20:52:30, you wrote to Andrew Leary:

I am not completely happy with how the wild card operates. It
probably sorts the files by their suffix and uses the highest number.

How this works out at the changeover from one year to the next may be implemented in makenl, but I am not shure.

It would suit me better if files were sorted by creation date like in
"ls -t ". If such a construct would work for all the versions that exits is questionable.

The most reliable way would be, to read the first line of the file and try to determine the date from that, before using the file date. (file dates can change)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Kees!

23 Nov 17 20:52, you wrote to me:

@MSGID: 2:280/5003.4 5a172ead
@CHRS: LATIN-1 4
@TZUTC: 0100
@TID: hpt/lnx 1.4.0-sta 16-02-06
Hello Andrew!

In the last few years it has come in vogue create daily nodelist.
In order to accomplish this, the PUBLish <DAY> has to be changed
every day. Although it is not difficult o use some form of scripting
to accomplish this, it would be more convenient if "PUBLish" TODAY
could be used in the control file. For those who want to make the file
one day in advance (before 24:00) "TOMORROW" would also be a usefull publishing day.

I have had a look at the code, and applied the following patch:

---8<----------------------------------------------------------------- ------- diff -r makenl_ng/makenl-code/src/config.c makenl_fg/makenl-code/src/config.c 399a400,401

{"TODAY", 3, 7},
{"TOMORROW", 3, 8},

798a801,810

}
time(&thetime);
mytime = localtime(&thetime);
if (NewExtWDay == 7)
NewExtWDay = mytime->tm_wday;
{
}
if (NewExtWDay == 8)
NewExtWDay = mytime->tm_wday + 1;
{

---8<----------------------------------------------------------------- --------

When using this patch, it is of importance, that

in the files section of the controlfile wilcards are used.

Region 28 region28.* 2:28/0

If the wildcard is omitted, only files of the same publishing day will
be looked for. When not found, older files published on the same
weeday wil be used. (There is aworkaround, but that is not relevant
here).

I am not completely happy with how the wild card operates. It probably sorts the files by their suffix and uses the highest number.

I suspect this is system dependent. Some systems match wildcards in some sort of sorted order, but most probably just go by the order the files are physically listed in the disk directory.

How this works out at the changeover from one year to the next may be implemented in makenl, but I am not shure.

It would suit me better if files were sorted by creation date like in
"ls -t ". If such a construct would work for all the versions that exits is questionable.

It should be possible to implement it, but will require a significant investment of coding and testing time to ensure that it works on all of the platforms and compilers MakeNL currently supports.

I hope that the main users would like the above patch to be included
in the mainstream version of makenl_ng. When the keywords TODAY and TOMORROW are not used, the code is just idle.

I don't see a compelling reason to not include it. After all, if those keywords are not used, the program continues to work exactly as it currently does.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Wilfred!

24 Nov 17 00:55, you wrote to Kees van Eeten:

The most reliable way would be, to read the first line of the file and
try to determine the date from that, before using the file date. (file dates can change)

This is only the case if the lower level submits updates using MakeNL or other nodelist generating software. For ZCs receiving updates from RCs, this is usually the case. However, it is fairly common for NCs of smaller nets to just edit their segment by hand with a text editor. In cases such as these, you can't expect the segment date to be in any particular format on the first line of the file; in fact it may not even be there at all. Even the default date line inserted by MakeNL isn't in the most convenient format for sorting by date, unless you are going to rely on the 3 digit day number, which will cause issues when crossing year boundaries.

In most cases where a segment is sent shortly after being generated, the file date stored on disk should be close enough.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Kees,

In the last few years it has come in vogue create daily nodelist.
In order to accomplish this, the PUBLish <DAY> has to be changed every
day.
Although it is not difficult o use some form of scripting to accomplish this, it would be more convenient if "PUBLish" TODAY could be used in
the control file. For those who want to make the file one day in advance (before 24:00) "TOMORROW" would also be a usefull publishing day.

There are 4 people in the nodelist concerned by this. 2 are producing a daily nodelist, maybe 3 but I'm not certain about the 3rd one.

None of these, I think, are in need of such an update. At least I will not use it most likely.

So I think you are proposing an update which may or may not be used by a grand total of 1 person.

Worth the trouble?

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hello Ward!

24 Nov 17 10:57, you wrote to Kees van Eeten:

There are 4 people in the nodelist concerned by this. 2 are producing
a daily nodelist, maybe 3 but I'm not certain about the 3rd one.

None of these, I think, are in need of such an update. At least I will
not use it most likely.

So I think you are proposing an update which may or may not be used by
a grand total of 1 person.

Worth the trouble?

MakeNL is used in other networks besides FidoNet. Several of them do produce daily nodelists.

Besides, the coding and testing time for this change will be minimal, as the code is basically already written.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi Andrew,

On 2017-11-24 03:32:32, you wrote to me:

The most reliable way would be, to read the first line of the file
and try to determine the date from that, before using the file date.
(file dates can change)

This is only the case if the lower level submits updates using MakeNL or other nodelist generating software. For ZCs receiving updates from RCs, this is usually the case. However, it is fairly common for NCs of smaller nets to just edit their segment by hand with a text editor. In cases such as these, you can't expect the segment date to be in any particular format on the first line of the file; in fact it may not even be there at all. Even the default date line inserted by MakeNL isn't in the most convenient format for sorting by date, unless you are going to rely on the 3 digit

day

number, which will cause issues when crossing year boundaries.

That's why I said "try". ;)

In most cases where a segment is sent shortly after being generated,
the file date stored on disk should be close enough.

It's the thing to use if the try didn't work...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Ward,

On Friday November 24 2017 10:57, you wrote to Kees van Eeten:

So I think you are proposing an update which may or may not be used by
a grand total of 1 person.

Worth the trouble?

Yes, I think it is.

First: it is not all that much trouble.

Second: when the option is there, more nodelist clerks will probably start using it. ZC3 issues a daily zone segment. He may start issuing a daily nodelist as well when there is no longer the hassle of multiple configurations.

Third: I see no reason why RCs and even NCs would not start using it as well, As it s this RC produces region segments with the day number of next Friday in the header and the file extension. Having the day number in the header and the file extension reflect the number of the day it is actually produced is more logical and transparant.


Cheers, Michiel

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

Hello Ward!

24 Nov 17 10:57, you wrote to me:

There are 4 people in the nodelist concerned by this. 2 are producing a daily nodelist, maybe 3 but I'm not certain about the 3rd one.

None of these, I think, are in need of such an update. At least I will not use it most likely.

So I think you are proposing an update which may or may not be used by a grand total of 1 person.

Worth the trouble?

With respect to makenl_ng you have always been hard to convince. ;)

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Andrew!

24 Nov 17 05:58, you wrote to Ward Dossche:

Besides, the coding and testing time for this change will be minimal, as the code is basically already written.

I found that there are 4 superfluous curly brackets in my code example.
This is what the whole case should look like:

case CFG_PUBLISH:
NewExtWDay = xlate_switch(strupper(args[0]), DOWSwitchTab);
if (NewExtWDay == -1)
{
mklog(LOG_ERROR, "%s -- Invalid day of week '%s'",
cfgline, args[0]);
mode = -1;
break;
}
time(&thetime);
mytime = localtime(&thetime);
if (NewExtWDay == 7)
NewExtWDay = mytime->tm_wday;
if (NewExtWDay == 8)
NewExtWDay = mytime->tm_wday + 1;
NewExtWDay = (NewExtWDay + 1) % 7; /* publishing day->new
filextension day */
break;


For completeness the is the other change in it's complete context.

static const struct switchstruct DOWSwitchTab[] = {
{"SUNDAY", 3, 0},
{"MONDAY", 3, 1},
{"TUESDAY", 3, 2},
{"WEDNESDAY", 3, 3},
{"THURSDAY", 3, 4},
{"FRIDAY", 3, 5},
{"SATURDAY", 3, 6},
{"TODAY", 3, 7},
{"TOMORROW", 3, 8},
{NULL, 0, -1}
};

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Wilfred!

24 Nov 17 00:55, you wrote to me:

The most reliable way would be, to read the first line of the file and try to determine the date from that, before using the file date. (file dates can change)

That is not what you want as same number is in file suffix.
But acually there is only one case where it is needed.

From one source two updates are received on Wednesday, one with the Wednesday
daynumber and one with the Friday daynumber. If succesive updates are
available, on Thursdays the Friday daynumber will be preferred when the sort
is made on suffix. Sorting on c-date would solve this. For the odd occation
where the above is the case, it is probably not worth the effort to
have it implemented. I think Ward will agree. ;)


Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi Kees,

On 2017-11-24 12:14:26, you wrote to me:

The most reliable way would be, to read the first line of the file
and try to determine the date from that, before using the file date.
(file dates can change)

That is not what you want as same number is in file suffix. But
acually there is only one case where it is needed.

I was thinking about the full date in the first line (including the year), not just the day number!

From one source two updates are received on Wednesday, one with the Wednesday daynumber and one with the Friday daynumber. If succesive updates are available, on Thursdays the Friday daynumber will be preferred when the sort is made on suffix. Sorting on c-date would
solve this.

That depends on the c-date of the file being correct. Which doesn't have to be the case. That's why I suggested to use the full "internal" date in the file.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Kees,

With respect to makenl_ng you have always been hard to convince. ;)

But you cannot claim that in the end I do not fall for proper argumentation.

In the DAILYLST story Z2 led the pack.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Andrew,

Worth the trouble?

MakeNL is used in other networks besides FidoNet. Several of them do produce daily nodelists.

And how many of these "other networks" have requested an update?

Thank you for reading the question, I know the answer though.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hallo Michiel,

Worth the trouble?

Yes, I think it is.

To me it looks like a techie-thing ... "Nothing techie has been done for a while, let's do something techie... gives the FTSC something to document"

First: it is not all that much trouble.

And I'm not advocating "against", only highlighting there's no demand.

Second: when the option is there, more nodelist clerks will probably
start using it.

The theory is nice, but in your position as FTSC-chair running an election you know perfectly how difficult it is to even raise the attention of a large portion of those regional nodelist clercs.

Expecting to get a "wow"-effect and kick-starting that part of the realm is wishful thinking ... in my opinion.

Having the day number
in the header and the file extension reflect the number of the day it is actually produced is more logical and transparant.

All the tools are present to achieve exactly that already ... have been doing that for over 2 decades now.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Wilfred,

That depends on the c-date of the file being correct. Which doesn't have
to be the case. That's why I suggested to use the full "internal" date in the file.

And what about if it passed through ERRFLAGS ?

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Kees,

From one source two updates are received on Wednesday, one with the Wednesday
daynumber and one with the Friday daynumber. If succesive updates are available, on Thursdays the Friday daynumber will be preferred when the sort is made on suffix. Sorting on c-date would solve this. For the odd occation
where the above is the case, it is probably not worth the effort to
have it implemented. I think Ward will agree. ;)

Do I have to? 8-)

The point I would like to make is that it is absolutely silly to produce 2 ZONE1 files on Wednesday with an interval of 2-3 hours, one having the Friday Julian-date.

There will be another ZONE1-file a day later which may contain more current information than the ZONE1-file with Friday's Julian date ... hence on Friday a
ZONE1-file with non-current information risks to be used when sticking to Wednesday's file.

All that can be avoided by simply producing a single ZONE1-file every day of the week using a single procedure with a single set of region-files and drop the Wednesday's version with Friday's Julian date.

My opinion as the longest serving nodelist clerc at Zone-level having produced so far 1,668 nodelists and maybe the same number of dailylsts.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hi Ward,

On 2017-11-24 13:43:13, you wrote to me:

That depends on the c-date of the file being correct. Which doesn't
have to be the case. That's why I suggested to use the full
"internal" date in the file.

And what about if it passed through ERRFLAGS ?

What about it?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Ward!

24 Nov 17 13:08, you wrote to me:

With respect to makenl_ng you have always been hard to convince. ;)

But you cannot claim that in the end I do not fall for proper argumentation.

Well for your switch to makenl_ng it took some 12 years.

In the DAILYLST story Z2 led the pack.

That did not require changes to makenl, but probably some preprocessor
for the CTL file. If the currently proposed update to PUBLish had been
available you would have had one requirement less in your preprocessor.
Now that everything has been working for quite some time, it is clear that
no change is needed for you.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Ward!

24 Nov 17 13:09, you wrote to Michiel van der Vlist:

To me it looks like a techie-thing ... "Nothing techie has been done for a while, let's do something techie...

You sound like a manager, who is advised by a subordinate.

gives the FTSC something to document"

As far as I know, the implementation of makenl_ng is not subject to the FTSC.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Ward!

24 Nov 17 13:46, you wrote to me:

where the above is the case, it is probably not worth the effort to
have it implemented. I think Ward will agree. ;)

Do I have to? 8-)

No.

The point I would like to make is that it is absolutely silly to
produce 2
ZONE1 files on Wednesday with an interval of 2-3 hours, one having the Friday Julian-date.

There will be another ZONE1-file a day later which may contain more current information than the ZONE1-file with Friday's Julian date ... hence on Friday a ZONE1-file with non-current information risks to be used when sticking to Wednesday's file.

All that can be avoided by simply producing a single ZONE1-file every day of the week using a single procedure with a single set of region-files and drop the Wednesday's version with Friday's Julian date.

I agree with you, but I do not meddle in the affairs of wizzards.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Kees,

And what about if it passed through ERRFLAGS ?

What about it?

It plays with the top-line.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Kees,

But you cannot claim that in the end I do not fall for proper
argumentation.

Well for your switch to makenl_ng it took some 12 years.

The argumentation was very poor then it seems.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Kees,

I agree with you, but I do not meddle in the affairs of wizzards.

Wizzards have beards ... "Houston, we have a problem" ... 8-)

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hallo Ward!

24.11.2017 16:33, Ward Dossche schrieb an Wilfred van Velzen:

[Errflags]

It plays with the top-line.

I can't see (in the sourcecode) with the topline.
What do you ment in detail?

\%/@rd

Bye/2 Torsten

... MAILBOX: up 6d 1h 35m load: 28 proc, 131 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

Hello Ward,

On Friday November 24 2017 13:09, you wrote to me:

First: it is not all that much trouble.

And I'm not advocating "against", only highlighting there's no demand.

That has been your standard response to any proposed changes/additions for the last fifteen years or so.

You seem to be a poor judge when it comes to evaluating future needs...


Cheers, Michiel

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

Torsten,

[Errflags]

It plays with the top-line.

I can't see (in the sourcecode) with the topline.
What do you ment in detail?

At some point I asked Johan Zwiekhorst that routines to:

1) Force a Region-line with a CRC-cqlculqtion in it when it is missing

2) Check the CRC and if it were wrong, flag it and re-calculate

Eventually that evolved into recalculating and inserting the CRC
"whatever"

If you can't find that, then it means someone tinkered with it.

For the record, I will only work with ERRFLAGS-versions produced by Niels Joncheere (2:292/0) and Tom De Puysseleer (2:29/0).

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Michiel,

You seem to be a poor judge when it comes to evaluating future needs...

I don't know about that ... It seems to be more on your side ...

It is in the collective memory of many sysops you have announced the end of the
world if we don't convert to IPv6 immediately ... that was how long ago? 5 years?

Then your attempts at getting UTF8 in the nodelist and after 3 calendar years still not having a single sensible UTF8-entry in the special UTF8-nodelist which is hardly distributed and used by, I'm assuming, no-one.

The thing is you're going to use this forum to pick a fight with me because you
still haven't managed to accept the whole MOB-discussion went over your head vanishing 'like a fart in the wind' (copyright Stephen King "Rita Hayworth and the Shawshank Redemption") and the subsequent abandonement by net-292 who pulled out of your region-28, re-establishing region-29, because it was unanymously decided by all nodes and its NC you were impossible to deal with.

I would say, enjoy your time in the FTSC and to close I would like to paraphrase one of my colleague ZCs who said in another echo to another sysop:

"Stop wasting my time!"

Take care,

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hello Ward,

On Friday November 24 2017 13:09, you wrote to me:

All the tools are present to achieve exactly that already ... have
been doing that for over 2 decades now.

23 years by your own count.

Another 16 years and tou will have toppe Rubert Mugabe.


Cheers, Michiel

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

Hallo Ward!

24.11.2017 20:53, Ward Dossche schrieb an Torsten Bamberg:

[Errflags]

It plays with the top-line.

I can't see (in the sourcecode) with the topline.
What do you ment in detail?

At some point I asked Johan Zwiekhorst that routines to:
1) Force a Region-line with a CRC-cqlculqtion in it when it is missing
2) Check the CRC and if it were wrong, flag it and re-calculate

If it's configured, correct.

But, errflags doesn't figure out a differnce between filedate, fileending(aka day of the year) or filename/ending inside the submitted file.
It does simply checks about the flags, not about the day of the year.

Eventually that evolved into recalculating and inserting the CRC
"whatever"

the crc will be generated, if it's configuered. If generating of the crc is configured, errflags will but it inside on top of the submitted file.
It doesn't check the 'day of the year' at all.

If you can't find that, then it means someone tinkered with it.

Well, I found the lines. :-)
Because of your message about errflags, I've had a nice evening with a quite old pascal source-codes.
Tha for that. :-) And now I'm getting a propper cold beer.

For the record, I will only work with ERRFLAGS-versions produced by
Niels Joncheere (2:292/0) and Tom De Puysseleer (2:29/0).

I know. I'm getting the information pages of your errflags 2.15. My Downlinks getting the information pages from my errflags 2.18 /OS2 EcomStation 2.2 compiled on my lokal machine on 29.10.2017 0:00h
;-)

\%/@rd

Bye/2 Torsten

... MAILBOX: up 6d 6h 05m load: 29 proc, 132 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

Hello Ward,

On Friday November 24 2017 21:35, you wrote to me:

Stephen King "Rita Hayworth and the Shawshank Redemption") and the subsequent abandonement by net-292 who pulled out of your region-28, re-establishing region-29, because it was unanymously decided by all
nodes and its NC you were impossible to deal with.

You are totally wrong, but this is not the proper place to discuss that.


Cheers, Michiel

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

Torsten,

Well, I found the lines. :-)
Because of your message about errflags, I've had a nice evening with a quite old pascal source-codes.
Tha for that. :-) And now I'm getting a propper cold beer.

At least I hope I haven't spoiled too much of your time.

Cold beer ... good idea.

Have a nice week-end ... I will, lotsa non-fido stuff coming up ... including beer tomorrow ... and Sunday too.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Michiel,

All the tools are present to achieve exactly that already ... have Mv>WD> been doing that for over 2 decades now.

23 years by your own count.

Another 16 years and tou will have toppe Rubert Mugabe.

You just invented the "van der Vlist variation on Godwin's Law".

We're done.

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hallo Ward!

24.11.2017 23:15, Ward Dossche schrieb an Torsten Bamberg:

Well, I found the lines. :-)
Because of your message about errflags, I've had a nice evening
with a quite old pascal source-codes. Tha for that. :-) And now
I'm getting a propper cold beer.

At least I hope I haven't spoiled too much of your time.

Gna, to spent the time it was nice and usefull. I got quite more involved into the code. ;-)

Cold beer ... good idea.

;-)

Have a nice week-end ... I will, lotsa non-fido stuff coming up ... including beer tomorrow ... and Sunday too.

Have fun.

Tomorrow I've got to make this strange 'Martin MAC 500' Moving head lights working. Hopefully I've got only to change the software. Next spring we've a lot open air music events with some international bands and starlets. Also some
very intresting metal-music events with bands of norway, denmark, sweden, germany and switzerland.

Lot's of non fidostuff to do.

Even finishing the design and construction work of my risc-based lightning desk
is waiting.

\%/@rd

Bye/2 Torsten

... MAILBOX: up 6d 8h 30m load: 29 proc, 132 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

Torsten,

Next
spring we've a lot open air music events with some international bands
and starlets. Also some very intresting metal-music events with bands of norway, denmark, sweden, germany and switzerland.

Are you involved or a mere spectator?

\%/@rd

--- D'Bridge 3.99
* Origin: Resist-Insist-Persist-Enlist / onwardtogether.org (2:292/854)

Hi Ward,

On 2017-11-24 16:33:57, you wrote to me:

And what about if it passed through ERRFLAGS ?

What about it?

It plays with the top-line.

If it changes the list, it needs to change the crc. But does it change the date?


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Kees,

On 23 Nov 17 20:52, you wrote to Andrew Leary:

I have had a look at the code, and applied the following patch:

I'd like to help you test this fix but I do not understand how to use binary executable diffs. I'm currently using MakeNL 3.4.6 (Linux). Could you please drop a copy of your patched Linux executable to me? Pretty please?

Region 28 region28.* 2:28/0

[ ...much text deleted... ]

It would suit me better if files were sorted by creation date like in
"ls -t ". If such a construct would work for all the versions that exits is questionable.

Trust me on this... the wildcarding does not matter when there is only a single
segment available. :)

Thanks in advance.

Cheers,
Paul.

... Two wrongs don't make a right. But three lefts do.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

I just love timely replies ... 8-)


Date: 26 Sep 18 21:31:39 -------------------->-----------------+
From: Paul Quinn !
To: Kees van Eeten !
Subj: Dailylists with makenl_ng ! ________________________________________________________________!
!
Hi! Kees, !
!
On 23 Nov 17 20:52, you wrote to Andrew Leary: !
========= ------------<------------<----------------<--------+

8-)

--- D'Bridge 3.99 SR33
* Origin: A man's most proud moment is when he takes a shit (2:292/854)

Hello Paul!

26 Sep 18 21:31, you wrote to me:

I'd like to help you test this fix but I do not understand how to use binary executable diffs. I'm currently using MakeNL 3.4.6 (Linux). Could you please drop a copy of your patched Linux executable to me? Pretty please?

Andrew Leary, who maintains the code, has include the patch in v3.4.8
It is however a bit tricky to use it.

In hindsight, I think, he probably should not have done it.

Trust me on this... the wildcarding does not matter when there is only
a
single segment available. :)

Are you using windows or a unix like OS.?

The most secure option is to start with an empty master directory, well the
cporight, prolog and epilog files can stay.

Then supply the most recent segments to the inbound directory.
Then run makenl with the current day as publishing day. With the patch
you can use TODAY as publishing day. That save you the task of changing
the publishing day or using seven control files.

Anyway if you run into troubles, let me know, I have tried many variations,
but solutions vary on what list you are producing.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Paul!

Just as an addition to my previous message.

A very basic way of creating dailies, is running makenl on a daily basis,
without changing the Publishing day.

The are the some values you fave to edit in the first line of the
produced Nodelist. The date and the daynumber. Changing this line has no
influence on the CRC. Ofcourse the daynumber suffix has to be changed as well.

With some tinkering this can all be done with a batch file.


Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi Paul,

On 2018-09-26 16:39:38, Kees van Eeten wrote to you:

The are the some values you fave to edit in the first line of the produced Nodelist. The date and the daynumber. Changing this line has
no influence on the CRC. Ofcourse the daynumber suffix has to be
changed as well.

With some tinkering this can all be done with a batch file.

I use this command sometimes to create a first line sometimes when updating segments for the AmigaNet nodelist:

date +';A Region Nodelist for %A, %B %-d, %Y -- Day number %j : 00000'

Might get you started...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred!

26 Sep 18 16:59, you wrote to Paul Quinn:

With some tinkering this can all be done with a batch file.

I use this command sometimes to create a first line sometimes when updating segments for the AmigaNet nodelist:

date +';A Region Nodelist for %A, %B %-d, %Y -- Day number %j : 00000'

You solved one of my issues. I did not think of the %-d.
%d generates a leading 0 for numbers below 10. So I used %e the adds a leading
space vor numbers below 10, I then replaced the double space by a single
space in a later string handling.

Thanks.

I generate " for %A, %B %-d, %Y -- Day number %j : "

and then i used sed to replace ' for .* : ' with the above gnerated date
string. This edits only the date dependent parts, The CRC is untouched.

As for the CRC, it can be used to see if the file has not been altered.
As far as I have found makenl only checks the CRC when a diff file is applied.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi! Ward,

On 09/26/2018 03:00 PM, you wrote:

I just love timely replies ... 8-)

Date: 26 Sep 18 21:31:39 -------------------->-----------------+
From: Paul Quinn !
To: Kees van Eeten !
Subj: Dailylists with makenl_ng ! ________________________________________________________________!
!
Hi! Kees, !
!
On 23 Nov 17 20:52, you wrote to Andrew Leary: !
========= ------------<------------<----------------<--------+

8-)

Careful now. Your satirical genius is showing. :-P

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: So where the bloody hell are you?!? (3:640/1384.125)

Hi! Kees,

On 09/26/2018 10:44 PM, you wrote:

Anyway if you run into troubles, let me know, I have tried many
variations, but solutions vary on what list you are producing.

Yes, I have been successful thus far with a region of small networks. I have been doing all of that which you say since early July, thanks to your kind notes and my observations of Ward's comments. It is an untidy method.

In the case of an inclusive new version I'll switch ASAP. Thank you, kindly

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Cogito sumere potum alterum. (3:640/1384.125)

Hi! Wilfred,

On 09/27/2018 12:59 AM, you wrote:

I use this command sometimes to create a first line sometimes when updating segments for the AmigaNet nodelist:
date +';A Region Nodelist for %A, %B %-d, %Y -- Day number %j : 00000'

Might get you started...

An "untidy method" still rings in my ears. :) A fascinating notion, thanks, but no thanks.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Cogito sumere potum alterum. (3:640/1384.125)