In the interest of completeness and closure I should admit, if it weren't
clear from my smileys and sarcastic quips, that my x64 "solution" is not a
solution at all. Pete and I discussed this. It is a very dirty hack. More
thought need to go into this process.
It will facilitate my spellcheck plan but that's it. In this context I just
wanted the error count down so my errors, introduced by removing existing
spellchecker code won't drown in the soup.
I can work with the spellchecking with this, and make the changes to the
32bit version afterwards once I sense some kind of pattern.
On Mon, 29 Oct 2018 at 17:45, Pete Maclean petemaclean@users.sourceforge.
net wrote:
I must jump in and say that I think creating a separate branch for an x64
Hermes would be a big mistake. At least in the Windows world, in most
cases, there need be very little difference between 32-bit and 64-bit code.
I was telling Soren privately earlier today that I have several programs
that I build in both 32- and 64-bit versions from a single code base in
each case. Taking one example, a program with 135,000 lines of C++ code in
193 modules has only 26 sections that are conditionally compiled in
different ways for 32 versus 64 and many of those contain only single-line
alternatives.
In case there is any doubt, I want to emphasise that I am wholly in favour
of creating a 64-bit Hermes. But only after we have a clean and completed
32-bit version.
My reading of Mr Thygesen's eMail is that he judges the 64-bit version to
be easier to write/compile than the 32-bit. That is the only reason I
suggested branching off.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
From a typical user viewpoint, there is probably little performance to be gained by a 64 bit email client. Interoperability, yes for sure going down the road. I fully support your intention to getting a clean compile of 32 bit Hermes first if for no other reason than to modernize the codebase.
I also reiterate the possibility of the Hermes project leader contacting Steve Dorner (or other Eudoraheads) for any guidance they might offer, if/when you feel the need. Dorner's on LinkedIn. I didn't look for the others.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From a typical user viewpoint, there is probably little performance to
be gained by a 64 bit email client.
I'm sure you're right here. User's wouldn't experience any true performance
boost. It's mostly about how much stuff is addressable, and the more
distance the more time needed,
Interoperability, yes for sure going down the road. I fully support your
intention to getting a clean compile of 32 bit Hermes first if for no other
reason than to modernize the >> codebase.
Yes, there seems broad consensus about finishing the 32 bit version first.
A wise choice sure.
I also reiterate the possibility of the Hermes project leader contacting
Steve Dorner (or other Eudoraheads) for any guidance they might offer,
if/when you feel the need.
Dorner's on LinkedIn. I didn't look for the others.
From a typical user viewpoint, there is probably little performance to be
gained by a 64 bit email client. Interoperability, yes for sure going down
the road. I fully support your intention to getting a clean compile of 32
bit Hermes first if for no other reason than to modernize the codebase.
I also reiterate the possibility of the Hermes project leader contacting
Steve Dorner (or other Eudoraheads) for any guidance they might offer,
if/when you feel the need. Dorner's on LinkedIn. I didn't look for the
others.
David Morrison noted in a message he posted to this list a while ago that Steve Dorner is unlikely to be inclined to offer guidance, or anything, since he is suffering from cancer. Also he would probably not have much to offer anyway because he wrote the Mac version and was not involved with the Windows version. Maybe it could not hurt to try contacting him but personally I would leave him alone. He must know that Windows Eudora has been open-sourced and, I imagine, would have offered assistance already had he been inclined.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This seems by far the most respectable solution. Let's not disturb him with
something so mundane. If one's religious I guess a prayer would be in
order. I'm not, so I hope he's got a chance with medicin or something. Evil
disease. I've had it close in my family myself.
David Morrison noted in a message he posted to this list a while ago that
Steve Dorner is unlikely to be inclined to offer guidance, or anything,
since he is suffering from cancer. Also he would probably not have much to
offer anyway because he wrote the Mac version and was not involved with the
Windows version. Maybe it could not hurt to try contacting him but
personally I would leave him alone. He must know that Windows Eudora has
been open-sourced and, I imagine, would have offered assistance already had
he been inclined.
(AFK)
In the interest of completeness and closure I should admit, if it weren't
clear from my smileys and sarcastic quips, that my x64 "solution" is not a
solution at all. Pete and I discussed this. It is a very dirty hack. More
thought need to go into this process.
It will facilitate my spellcheck plan but that's it. In this context I just
wanted the error count down so my errors, introduced by removing existing
spellchecker code won't drown in the soup.
I can work with the spellchecking with this, and make the changes to the
32bit version afterwards once I sense some kind of pattern.
But a true x64 transition it isn't.
Regards
On Monday, October 29, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
From a typical user viewpoint, there is probably little performance to be gained by a 64 bit email client. Interoperability, yes for sure going down the road. I fully support your intention to getting a clean compile of 32 bit Hermes first if for no other reason than to modernize the codebase.
I also reiterate the possibility of the Hermes project leader contacting Steve Dorner (or other Eudoraheads) for any guidance they might offer, if/when you feel the need. Dorner's on LinkedIn. I didn't look for the others.
I'm sure you're right here. User's wouldn't experience any true performance
boost. It's mostly about how much stuff is addressable, and the more
distance the more time needed,
Yes, there seems broad consensus about finishing the 32 bit version first.
A wise choice sure.
One for you Mr.Matavka?
Regards.
On Tue, Oct 30, 2018 at 6:14 PM Walt Stagner wstagner@users.sourceforge.net
wrote:
David Morrison noted in a message he posted to this list a while ago that Steve Dorner is unlikely to be inclined to offer guidance, or anything, since he is suffering from cancer. Also he would probably not have much to offer anyway because he wrote the Mac version and was not involved with the Windows version. Maybe it could not hurt to try contacting him but personally I would leave him alone. He must know that Windows Eudora has been open-sourced and, I imagine, would have offered assistance already had he been inclined.
This seems by far the most respectable solution. Let's not disturb him with
something so mundane. If one's religious I guess a prayer would be in
order. I'm not, so I hope he's got a chance with medicin or something. Evil
disease. I've had it close in my family myself.
Regards.
On Tue, Oct 30, 2018 at 7:47 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
I have never had it in my close family but a lot in close friends. A dreadful scourge.