Hi

I've made a branch with some changes for wrapping message lines over 80 chars... previously when wrapping it would chop words in half, and drop characters.

I started out wrapping words, and then wrapping quotes as well... so a
long quote line should also get broken up into multiple lines for
display.

This is all very experimental, so it's in a branch... I can't reliably
test it on fsxnet (due to mystic wrapping messages before I get them).
So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

You can checkout the unmangle_ansi_changes branch if you want to try it
out... but please be warned it may be crashy (I haven't had any crashes
yet though)..

Andrew

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

Quoting apam to All <=-

So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

I've not been processing on Magicka long enough but I think the linux
echo on fightonet may be a good place to look. One of the guys does
nothing but make fun of FTN software. I can't see him wrapping lines,
but hell what do I know?

Shawn

... Top secret! Burn before reading!

--- EzyBlueWave V3.00 01FB001F
* Origin: Tiny's BBS - telnet://tinysbbs.com:3023 (21:1/130)

This is all very experimental, so it's in a branch... I can't reliably test it on fsxnet (due to mystic wrapping messages before I get them).
So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

Yep, I'm not sure if I have any here. I am connected with Mystic nodes in fidonet also so a fair bit of the stuff I have here has passed through a
Mystic BBS, directly or indirectly.

This could happen in other situations to.. I'm not sure how many
softwares are out there that also do this perhaps when they save original messages.

It's not going to be easy to get around so maybe it has to be worked with
as it is.

I have links in z1, 2 and 3 that don't run mystic. We could engineer a
mystic free path but I suspect this or other problems would still be
seen.

You can checkout the unmangle_ansi_changes branch if you want to try it out... but please be warned it may be crashy (I haven't had any crashes yet though)..

I don't mind running that here. I have a small number of users here but I
think they were just looking and I could put up a blog post and let folks
know where are building stuff so ...

What command do I issue to grab that branch?

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On Tue, 5 Nov 2019 21:00:13 +1000
"apam -> All" <0@126.1.21> wrote:

This is all very experimental, so it's in a branch... I can't reliably
test it on fsxnet (due to mystic wrapping messages before I get them).
So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

I have several fidonet areas. How much test data do you need?

---
* Origin: (21:1/151)

On Tue, 5 Nov 2019 14:32:47 +0100
"Oli -> apam" <0@151.1.21> wrote:

On Tue, 5 Nov 2019 21:00:13 +1000
"apam -> All" <0@126.1.21> wrote:

This is all very experimental, so it's in a branch... I can't reliably
test it on fsxnet (due to mystic wrapping messages before I get them).
So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

I have several fidonet areas. How much test data do you need?

I have sent you the two files binkd.tar.bz2 and synchronet.tar.bz2

---
* Origin: (21:1/151)

I have sent you the two files binkd.tar.bz2 and synchronet.tar.bz2

Thanks!

Andrew

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

Quoting apam to All <=-

So if anyone has any jam bases with messages with long lines to test
with, could you please send me a copy.

I've not been processing on Magicka long enough but I think the linux
echo on fightonet may be a good place to look. One of the guys does
nothing but make fun of FTN software. I can't see him wrapping
lines, but hell what do I know?

Thanks :)

I think Oli sent me enough - I had a message from Blue White's archive
he sent me a while back that tested the quote wrapping.. I more wanted
to make sure things didn't crash with messages that would otherwise have worked...

Andrew

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

On Tue, 5 Nov 2019 21:00:13 +1000
"apam -> All" <0@126.1.21> wrote:

Did you receive my messages? I'm asking, because I didn't receive some messages
in the fsxnet echomail areas yesterday.

I have several fidonet areas. How much test data do you need?

I have sent you the two files binkd.tar.bz2 and synchronet.tar.bz2

---
* Origin: (21:1/151)

I have several fidonet areas. How much test data do you need?

I have sent you the two files binkd.tar.bz2 and synchronet.tar.bz2

Yes I did, thankyou.

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

Did you receive my messages? I'm asking, because I didn't receive some messages in the fsxnet echomail areas yesterday.

That is odd, and I don't think that has been a problem in fsxNet. If you
like we can link in the fidoweb way for redundency.

I just had a look at a few messages here and I see your node in the
seen-by's so I'm not sure that would help at all.

There may be a keywork for hpt to ignore your node in the seen-by's and
send your way anyway? I vaguely remember reading that but I may be wrong,
I'd have to look again.

Anyway, we can do that if you like.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On Wed, 6 Nov 2019 01:41:00 -0800
"Al -> Oli" <0@106.4.21> wrote:

Did you receive my messages? I'm asking, because I didn't receive some
messages in the fsxnet echomail areas yesterday.

That is odd, and I don't think that has been a problem in fsxNet. If you like we can link in the fidoweb way for redundency.

I just had a look at a few messages here and I see your node in the seen-by's so I'm not sure that would help at all.

My guess is that .pkt files are lost, some problems with the .flo files or .pkt
files are not tossed properly by crashmail. I would prefer to find the real problem instead of working around it. Is it a bug with Mystic, some binkd<->Mystic incompatibility or a Crashmail problem?

I always suspect Mystic, I regularly got dupes from 21:1/100 until I switched from compressed mail to uncompressed mail.

There may be a keywork for hpt to ignore your node in the seen-by's and send your way anyway? I vaguely remember reading that but I may be wrong, I'd have to look again.

Anyway, we can do that if you like.

I'm more interested in setting up a hub that doesn't use Mystic, maybe in collaboration with one or two other sysops. Apart from the mysteriously lost mails I would love to have a path in fsxnet that doesn't do line-breaking.

---
* Origin: (21:1/151)

My guess is that .pkt files are lost, some problems with the .flo files
or .pkt files are not tossed properly by crashmail. I would prefer to find the real problem instead of working around it. Is it a bug with Mystic, some binkd<->Mystic incompatibility or a Crashmail problem?

That's the million dollar question. I have not noticed problems myself
but if they are there the quicker they come to light the better.

I always suspect Mystic, I regularly got dupes from 21:1/100 until I switched from compressed mail to uncompressed mail.

I have dupe checking on currently and in the last month I only see 4
dupes that originated at the FTN <-> QWK gateway at 21:4/10.

There may be a keywork for hpt to ignore your node in the seen-by's and send your way anyway? I vaguely remember reading that but I may be wrong, I'd have to look again.

Anyway, we can do that if you like.

There is such a keyword, -sbign<???/???>

I'm more interested in setting up a hub that doesn't use Mystic, maybe
in collaboration with one or two other sysops. Apart from the
mysteriously lost mails I would love to have a path in fsxnet that
doesn't do line-breaking.

There is no such thing currently. It's a possibility I think but that
won't happen over night as Paul would need to think on that.

I can offer you a link using the above keyword for redundency, you will
receive many dupes. Pehaps like that we can shine a light on any hidden
issues.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On Wed, 6 Nov 2019 04:57:00 -0800
"Al -> Oli" <0@106.4.21> wrote:

Is it a bug with
Mystic, some binkd<->Mystic incompatibility or a Crashmail problem?

That's the million dollar question. I have not noticed problems myself
but if they are there the quicker they come to light the better.

It seems nobody else has that problem (or has noticed it). I will try to narrow
it down ...

I always suspect Mystic, I regularly got dupes from 21:1/100 until I
switched from compressed mail to uncompressed mail.

I have dupe checking on currently and in the last month I only see 4
dupes that originated at the FTN <-> QWK gateway at 21:4/10.

The dupes were only a symptom. The real problem was that I did receive the same
PKTs multiple times, like the ones I already received didn't get deleted. The next time I polled the system I received the PKTs that I already polled again.

I'm more interested in setting up a hub that doesn't use Mystic, maybe
in collaboration with one or two other sysops. Apart from the
mysteriously lost mails I would love to have a path in fsxnet that
doesn't do line-breaking.

There is no such thing currently. It's a possibility I think but that
won't happen over night as Paul would need to think on that.

It was not my plan to do this right now, at the moment I have more important stuff to work on. But in theory it would be possible to do it over night. FTN is decentralized, we can route echomail to other nodes without the intervention
of Paul ;).

I can offer you a link using the above keyword for redundency, you will receive many dupes. Pehaps like that we can shine a light on any hidden issues.

I'm not sure how that would help to find the problem. I don't want to toss two feed to the same message base. Maybe I could toss the mails from your system to
another message base and then compare both feeds. Some script that could read the PKTs directly and outputs any message that is missing in one feed would be nice.

I keep your offer in mind, but for now I think I'm better off without an additional echomail feed.

---
* Origin: (21:1/151)

The dupes were only a symptom. The real problem was that I did receive
the same PKTs multiple times, like the ones I already received didn't
get deleted. The next time I polled the system I received the PKTs that
I already polled again.

OK, In that case I am going to step away. I misunderstood. I though you
were missing messages somehow.

I can offer you a link using the above keyword for redundency, you will receive many dupes. Pehaps like that we can shine a light on any hidden issues.

I'm not sure how that would help to find the problem. I don't want to
toss two feed to the same message base. Maybe I could toss the mails
from your system to another message base and then compare both feeds. Some script that could read the PKTs directly and outputs any message
that is missing in one feed would be nice.

I was thinking of a feed for redundency. If the problem is that your are getting PKT's more than once it would not help to get even more. It would
just make it harder to figure out.

I keep your offer in mind, but for now I think I'm better off without
an additional echomail feed.

Definately. I don't think redundency feeds are needed in fsxnet because
we all have a short path to each other and the hubs pay attention to what
is happing in the net. If there are problems they are not hard to find or
fix.

It's different in fidonet where path lines can be very long. Missing
messages can be a thing there and hard to figure out why. Redundency
there makes more sense in that case.

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)