We may have to "reinvent the deep dish" (Danish idiom. BACK@U) , although,
I'm sure a windows system has been implemented. It is possible though.
Regards.
One of the strongest things about OpenGL (Dunno properly about DirectX but
that seems very Windows-ish.) is actually it´s crossplatform-compatibility.
This looks pretty good. Not surprising when what you´re talking to is the
actual videocard. Not the OS as such.
We may have to "reinvent the deep dish" (Danish idiom. BACK@U) , although,
I'm sure a windows system has been implemented. It is possible though.
Regards.
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
One of the strongest things about OpenGL (Dunno properly about DirectX but
that seems very Windows-ish.) is actually it´s crossplatform-compatibility.
This looks pretty good. Not surprising when what you´re talking to is the
actual videocard. Not the OS as such.
But crazy? Sure.
Regards.
On Wednesday, December 19, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
On Tue, Dec 18, 2018 at 11:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Hah. What a bummer! Grammatically. :)
On Tue, Dec 18, 2018 at 11:43 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
We may have to "reinvent the deep dish" (Danish idiom. BACK@U) , although,
I'm sure a windows system has been implemented. It is possible though.
Regards.
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
--
----- 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!)
Of course I know C. Although I code in C++ my absolute favorite is embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
Keep in mind that we're under time pressure.
--
----- 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!)
But I must warn you that my experience with the MAC, OS/X or Android, or
whatever the cool kids call it nowadays, is not my force. If it's C I will
be able to assess it's health nonetheless.
So, this is not my major concern. As Mr McLean has made the individual
libraries work, I'm not really worried about the actual functionality of
Eudora. Only the Stingray Toolkit makes me want to paint my east-ward wall
with human blood every two days, or such. Just to keep the
extra-dimensional spiky tentacled horrors at bay. :)
Of course I know C. Although I code in C++ my absolute favorite is embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, Dec 21, 2018 at 7:16 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
Keep in mind that we're under time pressure.
--
----- 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!)
But I must warn you that my experience with the MAC, OS/X or Android, or
whatever the cool kids call it nowadays, is not my force. If it's C I will
be able to assess it's health nonetheless.
It's UNIX, more or less. At least the code uses UNIX conventions. Android
is a Java VM running on top of a UNIX shell, but this is the real deal.
So, this is not my major concern. As Mr McLean has made the individual
libraries work, I'm not really worried about the actual functionality of
Eudora. Only the Stingray Toolkit makes me want to paint my east-ward wall
with human blood every two days, or such. Just to keep the
extra-dimensional spiky tentacled horrors at bay. :)
Regards.
Søren
On Fri, Dec 21, 2018 at 9:32 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Of course I know C. Although I code in C++ my absolute favorite is embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, Dec 21, 2018 at 7:16 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
Keep in mind that we're under time pressure.
--
----- 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!)
--
----- 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!)
As an aside. After I stopped fighting the CClassView generated
CDockablePane and starting working with what is already there I'm finally
getting somewhere.
The properties for instance. See attached picture. This is a dockable pane.
You can float or dock it anywhere you like, It will remember it's position.
It will automatically save and load as part of the settings file.
Things are taking off real quick now,
The parts of Eudora that are DLLs or indeed working static libraries will
plug right in.
On Fri, 21 Dec 2018 at 15:43, Soren Bro sbrothy@users.sourceforge.net
wrote:
But I must warn you that my experience with the MAC, OS/X or Android, or
whatever the cool kids call it nowadays, is not my force. If it's C I will
be able to assess it's health nonetheless.
It's UNIX, more or less. At least the code uses UNIX conventions. Android
is a Java VM running on top of a UNIX shell, but this is the real deal.
So, this is not my major concern. As Mr McLean has made the individual
libraries work, I'm not really worried about the actual functionality of
Eudora. Only the Stingray Toolkit makes me want to paint my east-ward wall
with human blood every two days, or such. Just to keep the
extra-dimensional spiky tentacled horrors at bay. :)
Regards.
Søren
On Fri, Dec 21, 2018 at 9:32 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Of course I know C. Although I code in C++ my absolute favorite is embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, Dec 21, 2018 at 7:16 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
Keep in mind that we're under time pressure.
--
----- 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!)
--
----- 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!)
Lots of stuff is build in for free. For instance fonts. Notive that
thery're automaivally in Danish on my computrt. They would be standard
language on your computer.
Still some language stuff to take care off but it not important for
functionality. Only for effect.
As an aside. After I stopped fighting the CClassView generated
CDockablePane and starting working with what is already there I'm finally
getting somewhere.
The properties for instance. See attached picture. This is a dockable
pane. You can float or dock it anywhere you like, It will remember it's
position. It will automatically save and load as part of the settings file.
Things are taking off real quick now,
The parts of Eudora that are DLLs or indeed working static libraries will
plug right in.
On Fri, 21 Dec 2018 at 15:43, Soren Bro sbrothy@users.sourceforge.net
wrote:
But I must warn you that my experience with the MAC, OS/X or Android, or
whatever the cool kids call it nowadays, is not my force. If it's C I will
be able to assess it's health nonetheless.
It's UNIX, more or less. At least the code uses UNIX conventions. Android
is a Java VM running on top of a UNIX shell, but this is the real deal.
So, this is not my major concern. As Mr McLean has made the individual
libraries work, I'm not really worried about the actual functionality of
Eudora. Only the Stingray Toolkit makes me want to paint my east-ward wall
with human blood every two days, or such. Just to keep the
extra-dimensional spiky tentacled horrors at bay. :)
Regards.
Søren
On Fri, Dec 21, 2018 at 9:32 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Of course I know C. Although I code in C++ my absolute favorite is
embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, Dec 21, 2018 at 7:16 PM Ted Matavka
nmatavka@users.sourceforge.net
wrote:
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more
time,
and willing artists, such a program would truly stand out as something
new.
Regards,
Søren
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
Keep in mind that we're under time pressure.
--
----- 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!)
--
----- 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!)
For the first couple of decades of my career I programmed mostly in assembly language. Even my first email client was written in assembler. Now I have not touched an assembly language in 20 years; even embedded code has been in C. I kinda miss it -- I like working close to the hardware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, exactly. But the evolution of language goes the other way, I guess we
can be thankful for not having to code in assembler, but I miss the power
at my fingertips as I said. One reason I like small embedded systems.
For the first couple of decades of my career I programmed mostly in
assembly language. Even my first email client was written in assembler. Now
I have not touched an assembly language in 20 years; even embedded code has
been in C. I kinda miss it -- I like working close to the hardware.
Funny that, if I ever program, I write in an absurdly high-level language called Lisp. It's been around for a couple of decades (longer than Java for sure, longer even than C or C++) so sometimes it's seen as a bit old-fashioned, and its syntax isn't Algol-like at all (it (looks ((like) this)))), so a lot of programmers get confused when they see Lisp code for the first time.
It's good for scripting, though. Much easier to bash out a quick script in Lisp than something like C, and I definitely don't write "real" programs (I leave that to the professionals).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Funny that, if I ever program, I write in an absurdly high-level language
called Lisp. It's been around for a couple of decades (longer than Java for
sure, longer even than C or C++) so sometimes it's seen as a bit
old-fashioned, and its syntax isn't Algol-like at all (it (looks ((like)
this)))), so a lot of programmers get confused when they see Lisp code for
the first time.
It's good for scripting, though. Much easier to bash out a quick script in
Lisp than something like C, and I definitely don't write "real" programs (I
leave that to the professionals).
Oh. Why not COBOL, FORTRAN or BASIC, or inded assembler while he were at
it? :)
Fortran is an odd language, that's for sure. At the University of
Cambridge, it's not even taught by the Computer Science department; it's
taught by Physics! COBOL wouldn't actually be a bad client to write an
eMail client in; it's the best for "boring" stuff like payroll,
spreadsheets, and yes, eMail.
An interesting thing about LISP is that it really has only one data type:
the one-dimensional array (which, in its inimitably distinctive vocabulary,
it calls a "list"). The string "string" is really just an array of one
object "string", which can be converted into an array of six objects "s"
"t" "r" "i" "n" "g". The integer 42 is also an array of one object.
Multi-dim arrays can be done ((l, i, k, e) (t, h, i, s)). Even weirder,
FORTRAN is almost the same, only the way it operates on those arrays is
less mathematical and more computery. It automatically follows that a LISP
or FORTRAN program to count spaces in a string is trivial.
But if you learn "programming" in England—for example, on a course titled
"Introduction to Programming"—it'll be Haskell if you're at uni, or Python
if you're at school.
--
----- 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!)
This reminds me that I should code as much in ISO C(++) as possible. This
way the code would be crossplatform. Instead of using CFile I should be
using fopen and similar. It´s just difficult when immersed so deep in MFC.
On Sun, 23 Dec 2018 at 17:40, Soren Bro sbrothy@users.sourceforge.net
wrote:
Oh. Why not COBOL, FORTRAN or BASIC, or inded assembler while he were at
it? :)
Fortran is an odd language, that's for sure. At the University of
Cambridge, it's not even taught by the Computer Science department; it's
taught by Physics! COBOL wouldn't actually be a bad client to write an
eMail client in; it's the best for "boring" stuff like payroll,
spreadsheets, and yes, eMail.
An interesting thing about LISP is that it really has only one data type:
the one-dimensional array (which, in its inimitably distinctive vocabulary,
it calls a "list"). The string "string" is really just an array of one
object "string", which can be converted into an array of six objects "s"
"t" "r" "i" "n" "g". The integer 42 is also an array of one object.
Multi-dim arrays can be done ((l, i, k, e) (t, h, i, s)). Even weirder,
FORTRAN is almost the same, only the way it operates on those arrays is
less mathematical and more computery. It automatically follows that a LISP
or FORTRAN program to count spaces in a string is trivial.
But if you learn "programming" in England—for example, on a course titled
"Introduction to Programming"—it'll be Haskell if you're at uni, or Python
if you're at school.
Regards.
On Sun, Dec 23, 2018 at 9:44 PM Pete Maclean
petemaclean@users.sourceforge.net %0Dpetemaclean@users.sourceforge.net
wrote:
I know someone -- another crazy Brit -- who wrote an entire, elaborate
email client entirely in Prolog (another language designed for AI use).
--
----- 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!)
This reminds me that I should code as much in ISO C(++) as possible. This
way the code would be crossplatform. Instead of using CFile I should be
using fopen and similar. It´s just difficult when immersed so deep in MFC.
Agreed. We should be using standardised programming language when
possible. I will also copy you in on a message I sent to Laurie Spiegel.
I don't know if she'll help us or not, but it's got a list of the problems
relating to Mac/UNIX Eudora. Yes, with a little help, we should be able to
get Mac Eudora running on pure UNIX.
Regards.
On Mon, Dec 24, 2018 at 12:14 AM Ted Matavka
nmatavka@users.sourceforge.net
wrote:
On Sun, 23 Dec 2018 at 17:40, Soren Bro sbrothy@users.sourceforge.net
wrote:
Oh. Why not COBOL, FORTRAN or BASIC, or inded assembler while he were at
it? :)
Fortran is an odd language, that's for sure. At the University of
Cambridge, it's not even taught by the Computer Science department; it's
taught by Physics! COBOL wouldn't actually be a bad client to write an
eMail client in; it's the best for "boring" stuff like payroll,
spreadsheets, and yes, eMail.
An interesting thing about LISP is that it really has only one data type:
the one-dimensional array (which, in its inimitably distinctive vocabulary,
it calls a "list"). The string "string" is really just an array of one
object "string", which can be converted into an array of six objects "s"
"t" "r" "i" "n" "g". The integer 42 is also an array of one object.
Multi-dim arrays can be done ((l, i, k, e) (t, h, i, s)). Even weirder,
FORTRAN is almost the same, only the way it operates on those arrays is
less mathematical and more computery. It automatically follows that a LISP
or FORTRAN program to count spaces in a string is trivial.
But if you learn "programming" in England—for example, on a course titled
"Introduction to Programming"—it'll be Haskell if you're at uni, or Python
if you're at school.
Regards.
On Sun, Dec 23, 2018 at 9:44 PM Pete Maclean
petemaclean@users.sourceforge.net %0Dpetemaclean@users.sourceforge.net
wrote:
I know someone -- another crazy Brit -- who wrote an entire, elaborate
email client entirely in Prolog (another language designed for AI use).
--
----- 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!)
--
----- 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!)
What issue is it that we're trying to solve with OpenGL? I don't want to
pour cold water on any bright ideas, so please take all this cum grano
salis; if you're using it for good reason, go right ahead and don't pay any
further attention to me.
Ideally, as I've already expressed, we'd have a cross-platform code tree at
the end of it all, with cross-platform manpower and a single language.
More than anything, this would be for reasons of economy and efficiency.
If that's your motivation for considering OpenGL, perhaps it's a good one.
It is important to note, however, that the code for Mac Eudora isn't as
obsolete as I feared; it's not a Mac Classic project, but it does use an
IDE which is no longer made (viz. CodeWarrior), so we'd have to convert
that to Xcode, and then try to re-compile for Intel (this was built during
the PPC-Intel transition). If we do go that route instead, we WILL have
trouble in a few years, but not yet; Carbon is used pervasively, and it
only compiles on x86 processors, so if the ability to execute x86 code is
gone, so's our codebase. Otherwise, the code seems fairly healthy.
--
----- 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!)
https://www.khronos.org/opengl/wiki/Getting_Started
We may have to "reinvent the deep dish" (Danish idiom. BACK@U) , although,
I'm sure a windows system has been implemented. It is possible though.
Regards.
Hah. What a bummer! Grammatically. :)
On Tue, Dec 18, 2018 at 11:43 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
On Tue, Dec 18, 2018 at 11:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
One of the strongest things about OpenGL (Dunno properly about DirectX but
that seems very Windows-ish.) is actually it´s crossplatform-compatibility.
This looks pretty good. Not surprising when what you´re talking to is the
actual videocard. Not the OS as such.
But crazy? Sure.
Regards.
On Wednesday, December 19, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
One advantage using OpenGL is that it's no longer programmers you search
for, but artists. If they can deliver their designs in 3D (or even 4D!),
using one of the big drawing programs today. (I'm out of sync with that
world. Power3D? AutoCAD?) You can give your users a very vivid corporation
Brand through in how you program will look and feel. It would even be
disturbing to the bigwigs; M$, POSIX, MAX. The blue chips.
They're all reliant on you using their OS. If you bypass it talk the
graphics card itself, they're sorta not really sitting at the table.
Regards.
Søren
On Thu, Dec 20, 2018 at 9:17 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
On Thu, 20 Dec 2018 at 17:20, Soren Bro sbrothy@users.sourceforge.net
wrote:
Yes. And I'm only throwing the idea out there. I fully appreciate the
logistical impossibilities here. I'm just saying... For cross-platform
compliance, skipping the various OSs out there, and talking directly with
the video cards, makes the hosting OS instantly obsolete. Had we more time,
and willing artists, such a program would truly stand out as something new.
Regards,
Søren
On Friday, December 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
On Fri, 21 Dec 2018 at 10:47, Soren Bro sbrothy@users.sourceforge.net
wrote:
Well, it is a good idea, and it might be a future consideration. Right
now, though, I've been wracking my brains so as to figure out how best to
develop HERMES for the Mac within the next year. OpenGL may or may not be
a possibility, but I've been thinking mostly about the old source code.
Tell me when you've got time to kill and I'll send you the Hg command to
retrieve the Mac source tree. You said you did a bit of programming in C?
Not looking to have you on board permanently, but I'd like to know if the
Mac code is workable.
--
----- 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!)
Of course I know C. Although I code in C++ my absolute favorite is embedded
systems, with a clear BIOS C API. Think hand-held laser-scanners or
cash-registers.
Heck, if it wasn't suck a nightmare I'd probably be an assembler fan. Like
a magician, the power of your fingertips gets progressively more powerful
the closer you get to the actual chipset, enslaved by bloodmagic or
"gasea", it's fealty also gets progressively more loyal. :)
PS: Sorry, I'm reading Charles Stross' "Laundry Files" books. They do a
number on your brain, figuratively in the literate meaning of the word. :)
On Fri, Dec 21, 2018 at 7:16 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
But I must warn you that my experience with the MAC, OS/X or Android, or
whatever the cool kids call it nowadays, is not my force. If it's C I will
be able to assess it's health nonetheless.
So, this is not my major concern. As Mr McLean has made the individual
libraries work, I'm not really worried about the actual functionality of
Eudora. Only the Stingray Toolkit makes me want to paint my east-ward wall
with human blood every two days, or such. Just to keep the
extra-dimensional spiky tentacled horrors at bay. :)
Regards.
Søren
On Fri, Dec 21, 2018 at 9:32 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
On Fri, 21 Dec 2018 at 15:43, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
----- 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!)
OK. UNIX is good. I can handle that,
As an aside. After I stopped fighting the CClassView generated
CDockablePane and starting working with what is already there I'm finally
getting somewhere.
The properties for instance. See attached picture. This is a dockable pane.
You can float or dock it anywhere you like, It will remember it's position.
It will automatically save and load as part of the settings file.
Things are taking off real quick now,
The parts of Eudora that are DLLs or indeed working static libraries will
plug right in.
Regards.
On Fri, Dec 21, 2018 at 10:37 PM Ted Matavka nmatavka@users.sourceforge.net
wrote:
Lots of stuff is build in for free. For instance fonts. Notive that
thery're automaivally in Danish on my computrt. They would be standard
language on your computer.
Still some language stuff to take care off but it not important for
functionality. Only for effect.
On Fri, Dec 21, 2018 at 11:55 PM sbrothy@gmail.com wrote:
For the first couple of decades of my career I programmed mostly in assembly language. Even my first email client was written in assembler. Now I have not touched an assembly language in 20 years; even embedded code has been in C. I kinda miss it -- I like working close to the hardware.
Yes, exactly. But the evolution of language goes the other way, I guess we
can be thankful for not having to code in assembler, but I miss the power
at my fingertips as I said. One reason I like small embedded systems.
Regards.
On Fri, Dec 21, 2018 at 11:40 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
Funny that, if I ever program, I write in an absurdly high-level language called Lisp. It's been around for a couple of decades (longer than Java for sure, longer even than C or C++) so sometimes it's seen as a bit old-fashioned, and its syntax isn't Algol-like at all (it (looks ((like) this)))), so a lot of programmers get confused when they see Lisp code for the first time.
It's good for scripting, though. Much easier to bash out a quick script in Lisp than something like C, and I definitely don't write "real" programs (I leave that to the professionals).
Yes Ive touched LISP briefly. I distinctly remember the many paranthesises.
Im told it's particularly suited for AI.
Regards
On Sunday, December 23, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
I know someone -- another crazy Brit -- who wrote an entire, elaborate email client entirely in Prolog (another language designed for AI use).
Oh. Why not COBOL, FORTRAN or BASIC, or inded assembler while he were at
it? :)
Regards.
On Sun, Dec 23, 2018 at 9:44 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
On Sun, 23 Dec 2018 at 17:40, Soren Bro sbrothy@users.sourceforge.net
wrote:
An interesting thing about LISP is that it really has only one data type:
the one-dimensional array (which, in its inimitably distinctive vocabulary,
it calls a "list"). The string "string" is really just an array of one
object "string", which can be converted into an array of six objects "s"
"t" "r" "i" "n" "g". The integer 42 is also an array of one object.
Multi-dim arrays can be done ((l, i, k, e) (t, h, i, s)). Even weirder,
FORTRAN is almost the same, only the way it operates on those arrays is
less mathematical and more computery. It automatically follows that a LISP
or FORTRAN program to count spaces in a string is trivial.
But if you learn "programming" in England—for example, on a course titled
"Introduction to Programming"—it'll be Haskell if you're at uni, or Python
if you're at school.
--
----- 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!)
This reminds me that I should code as much in ISO C(++) as possible. This
way the code would be crossplatform. Instead of using CFile I should be
using fopen and similar. It´s just difficult when immersed so deep in MFC.
Regards.
On Mon, Dec 24, 2018 at 12:14 AM Ted Matavka nmatavka@users.sourceforge.net
wrote:
On Sun, 23 Dec 2018 at 19:37, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
----- 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!)
What issue is it that we're trying to solve with OpenGL? I don't want to
pour cold water on any bright ideas, so please take all this cum grano
salis; if you're using it for good reason, go right ahead and don't pay any
further attention to me.
Ideally, as I've already expressed, we'd have a cross-platform code tree at
the end of it all, with cross-platform manpower and a single language.
More than anything, this would be for reasons of economy and efficiency.
If that's your motivation for considering OpenGL, perhaps it's a good one.
It is important to note, however, that the code for Mac Eudora isn't as
obsolete as I feared; it's not a Mac Classic project, but it does use an
IDE which is no longer made (viz. CodeWarrior), so we'd have to convert
that to Xcode, and then try to re-compile for Intel (this was built during
the PPC-Intel transition). If we do go that route instead, we WILL have
trouble in a few years, but not yet; Carbon is used pervasively, and it
only compiles on x86 processors, so if the ability to execute x86 code is
gone, so's our codebase. Otherwise, the code seems fairly healthy.
On Tue, 18 Dec 2018 at 17:43, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
----- 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!)