<html><head></head><body>
<p>Hi Shaping, <br/>
</p>
<p>I saw your email and thought to respond to what you say.
Hopefully, helpfully.<br/>
</p>
<div class="moz-cite-prefix">On 4/15/20 4:59 AM, Shaping wrote:<br/>
</div>
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)"/>
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<div>
<p class="MsoNormal" style="margin-left:.5in">Just to get in
the right frame of mind, consider that because of the Blub
Paradox (<a href="http://www.paulgraham.com/avg.html" moz-do-not-send="true">http://www.paulgraham.com/avg.html</a>)
<br/>
you are going to have a hard time convincing people to
"change to this language because of Feature X"<br/>
just by saying so. You need to dig deeper. <span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
Pony compiler and runtime need to be studied.</span></p>
</div>
</div>
</blockquote>
What better way than to bring the Pony compiler into Squeak? Build a
Pony runtime inside Squeak, with the vm simulator. Build a VM. Then
people will learn Pony and it would be great!<br/>
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p>I’m
not trying to convince; I’m presenting facts,
observations, and resources for study of the problem and
its solution. Hardware constraints now are intensely
multicore, and everyone knows this. The changing
programming paradigm in apparent. Hardware structure is
forcing that change. Convincing yourself will not be
difficult when you have the facts. You likely do
already, at least on the problem-side. </span></p>
</div>
</div>
</blockquote>
The solution is easy. As different event loops on different cores
will use the same externalizing remote interface to reach other
event loops, we do not need a runtime that can run on all of those
cores. We just need to start the minimal image on the CogVM with
remote capabilities to share workload. The biggest challenge, I
think you would agree is the system/application design that provides
the opportunities to take advantage of parallelism. It kinda fits
the microservices arch. So, we would run 64 instances of squeak to
take the multicore to town.<br/>
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p>The
issue is not whether to use Pony. I don’t like Pony, the
language; it’s okay, even very good, but it’s not
Smalltalk. I like Smalltalk, who concurrency model is
painfully lame. <br/>
</span></p>
</div>
</div>
</blockquote>
<p>Squeak concurrency model.</p>
<p>Installer ss<br/>
project: 'Cryptography';<br/>
install: 'CapabilitiesLocal'<br/>
</p>
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
I like <b><u>Orca</u></b> because it works on many cores
(as many as 64, currently) without a synchronization step
for GC, and has wonderful concurrency abilities. Pony and
Orca were co-designed. The deferred reference counts
managed by Orca run on the messages between the actors
(send/receive tracing). GCs happen in Pony/Orca when each
actor finishes its response to the last received message,
and goes idle. The actor then GCs all objects no longer
referenced by other actors. The runtime scheduler takes
this time needed for each actor’s GCing into account. No
actor waits to GC objects. An actor’s allocated objects’
ref counts are checked at idle-time, and unreferenced
objects are GCed in an ongoing, fluid way, in small,
high-frequency bursts, with very small, predictable tail
latencies, as a result. That’s very interesting if you
need smoothly running apps (graphics), design/program
real-time control systems, or process data at high rates,
as in financial applications at banks and exchanges.</span></p>
</div>
</div>
</blockquote>
So your use of Pony is purely to access the Orca vm? I think you
will find the CogVM quite interesting and performant.
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
issue is how most efficiently to use Orca, which happens
to be working in Pony. Pony is in production in two
internal, speed-demanding, banking apps and in Wallaroo
Labs’ high-rate streaming product. Pony is a convenient
way to study and use a working implementation of Orca.
Ergo, use Pony, even if we only study it as a good example
of how to use Orca. Some tweaks (probably a lot of them)
could allow use of dynamic types. We could roll our own
implementation of Orca for the current Pharo VM, but that
seems like more work than tweaking a working Pony compiler
and runtime. I’m not sure about that. You know the VM
better than I. (I was beginning my study of the
Pharo/OpenSmalltalkVM when I found Pony.)</span></p>
</div>
</div>
</blockquote>
<p>Sounds like you might regret your choice and took the wrong path.
Come back to Squeak! ^,^</p>
<p>Kindly, Robert<br/>
</p>
<blockquote type="cite" cite="mid:012901d61304$2a2541d0$7e6fc570$@uurda.org">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br/>
<br/>
Now I I took a quick look to see what I could learn about
Pony <br/>
and the main interesting thing is its "Reference
Capabilities".<br/>
Indeed, it seems Pony's purpose is the POC for that
research.<br/>
I watched two videos...<br/>
<br/>
[1] Øredev 2017 - Joe McIlvain - Pony - A Language for
Provably Safe Lockless Concurrency<br/>
<a href="https://www.youtube.com/watch?v=9NH4bVfbvYI" moz-do-not-send="true">https://www.youtube.com/watch?v=9NH4bVfbvYI</a>
<br/>
<br/>
[2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent
programs - Codemesh 2017<br/>
<a href="https://www.youtube.com/watch?v=e_bES30tFqI" moz-do-not-send="true">https://www.youtube.com/watch?v=e_bES30tFqI</a>
<br/>
<br/>
So my "quick" assessment is to consider Reference
Capabilities not a Type System <br/>
but a Meta-type System. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes,
ref-caps control sharing of both mutable and immutable
objects.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"> [2] says "They
are not a property of an object, but define how I can look
at an object." To summarize the videos... <br/>
<br/>
[1]@29:15...<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1025" src="cid:part4.4B294671.C17E07A7@pm.me" alt="image.png" class="" width="473" height="165" border="0"/><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1026" src="cid:part5.B5E20FF7.D6153326@pm.me" alt="image.png" class="" width="473" height="234" border="0"/><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br/>
[2]@13:40...<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1027" src="cid:part6.415CAD7C.6193812D@pm.me" alt="image.png" class="" width="473" height="371" border="0"/><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br/>
[2]@24:40...<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1028" src="cid:part7.DAFC981F.D1A4597A@pm.me" alt="image.png" class="" width="473" height="72" border="0"/><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"> <br/>
[2]@28:30...<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><img id="_x0000_i1029" src="cid:part8.8C4694D6.07F93BEB@pm.me" alt="image.png" class="" width="473" height="116" border="0"/><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br/>
So you say...<br/>
> I want to use the Pony concurrency model at the
Smalltalk level. That’s the gist of it. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">>
Otherwise, I want a Smalltalk, not a statically compiled
language.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:1.0in">I believe
you have the wrong end of the the stick promoting that
the VM <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:1.0in">needs to be
redeveloped using Pony to get the Reference Capabilities
<br/>
at the Smalltalk level. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">See
my recent response to Ken in vm-dev. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"> After you
Ahead-Of-Time compile the VM, the compiler<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">is left
behind. The features of the compiler don't
automatically flow through<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">to Smalltalk
level. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Yes.
JIT and AOT are needed. Adjustments need to be made
for dynamic typing, but such adjustments need not
violate invariants needed to provide the ref-cap
concurrency guarantees. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">A third
option could be to extend to the existing "Immutability
capability" of the VM. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ref-caps
control access to both immutable and mutable objects.
Pony ascertains at compile time that only one actor at
a time can hold a reference to a mutable object at
runtime.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The six
Reference Capabilities might be stored in the Spur
Object Header <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">using a
re-purposed Immutability bit plus the two free "green"
bits.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><a href="https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/" moz-do-not-send="true">https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/</a> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
can’t use a single big system heap, and also use the
actor model and many cores productively</span></u><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">. <o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
big heap must go.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">That’s
the crux of what we need to learn at this juncture.
I’m not sure everyone is getting this. I don’t need
to convince you; you can do that for yourself. We
don’t currently have a better choice of programming
model or memory management, if we want maximum speed,
and are paying attention to hard constraints.
Multicore hardware is here to stay. If you know a way
to use your multicore CPUs more efficiently than by
use of actor-based programming and Orca memory
management, please share your facts.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Everyone
needs to understand the big-heap problem in order to
commit to fine-grain, actor-based (and therefore
state-machine-based) programming. We won’t realize
productive multicore programming without an actor
model. We still need new tools to help, as mentioned,
lest our state-machine programming be tedious and
painful, <u>causing us to default to old coding
habits</u>, and not make the needed state-machines.
I’m working on one of those tools. Orca manages
memory as fast as possible in an actor-based
program/runtime, without any synchronization. The
big-heap problem has been solved for the statically
typed case in Pony. The lack of discipline/tools for
building state-machines remains a broad problem. Such
new tools are therefore essential during the change of
programming model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
suggest studying the current Pony/Orca solution (see
the Orca paper linked below), to see how it can be
tweaked to accommodate dynamic types. I’ve not
studied the Pony compiler and runtime enough to be
certain, but they may be closer to what we need, even
if the first rough implementation of a
Smalltalk-with-Orca must be AOT, instead of JIT. We
want both ultimately. We should do first whichever is
easiest to implement and test in small steps. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">"Reference
Capabilities for Dynamic Languages" could be a strong
PhD project. <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It’s
a good idea. Is this needed to make a Smalltalk that
works with Orca? I don’t think so.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Orca
matters more than Pony. But both can be useful to
us. Studying the Orca paper and its implementation in
the Pony compiler and runtime is the easiest way to
understand the constraints imposed by the current
static type system in Pony—and how to change them to
accommodate dynamic types. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Everyone,
please read and study <a href="https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf" moz-do-not-send="true">https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf</a>
if you are interested in building a VM/runtime that
guarantees no data-races, and fully uses all your
machine’s cores, with the least programming effort.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Then
study Pony: <a href="https://www.ponylang.io/" moz-do-not-send="true">https://www.ponylang.io/</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">And
ask questions on Pony Zulip: <a href="https://ponylang.zulipchat.com/" moz-do-not-send="true">https://ponylang.zulipchat.com/</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">(BTW,
Zulip seems easier to use than Discord and e-mail.
Has anyone considered using it for the Pharo/Squeak
lists?)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Shaping<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">On Fri, 10 Apr 2020 at 17:56, Shaping
<<a href="mailto:shaping@uurda.org" moz-do-not-send="true">shaping@uurda.org</a>>
wrote:<br/>
><br/>
> Hi Ken.<br/>
><br/>
> Not to discourage people, but I have not seen cases
where a "strong<br/>
> type system would be able to scale for _real_
Smalltalk applications.<br/>
><br/>
> You’re right. It doesn't. I'm not suggesting
that.<br/>
><br/>
> The type safety is not for app-level Smalltalk
development. It's for building the VM only.<br/>
><br/>
> The six ref-cap ideas for sharing data reliably
between actors are not hard to grasp, but they take some
getting used to, and involve some mental load. I don't
want that much (concurrency-related or any other)
implementation detail in the domain layer, much in the
same vein as: I don’t use Forth because I don’t want to
see stack acrobatics (ROTs and DUPs, etc.) amidst
domain-level state-changes (FirePhotonTorpedo). It’s
distracting. It dilutes focus on the domain work/layer,
and tends to cause mistakes there.<br/>
><br/>
> <br/>
><br/>
> The programmer’s domain logic and the
concurrency-integrity provided by the ref-caps are
different layers of thought and structure. The ref-caps
are, however, mixed freely with domain logic in current
Pony code. I think that’s a mistake. But that’s how it
is now. I think of this layer mixing as an intermediate
design stage of Pony. I want to abstract-out some or
all ref-caps as the VM is built. <br/>
><br/>
> Pony language is not the remarkable thing here. I
see it as a better C or better Rust. It’s very good (as
Algol-60-ish-looking crap-syntaxes go), but that’s not
what this is about. It’s about the actor programming,
the concurrency model, and the guarantees given by use
of the ref-caps. We would still obviously need to
respect the Pony compiler’s determination of where
ref-cap use is correct or not. Your Pony program won’t
compile if you don’t use the ref-caps correctly, and you
don’t get the guarantees or a running program without
the compile. Much easier, therefore, might be to go the
other way by changing Pony to support dynamic types
without violating the invariants that allow the ref-caps
(under the hood, abstracted out) to make the concurrency
guarantees. Work Smalltalk dynamism into Pony, instead
of building a Smalltalk VM with Pony. <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Kindly,
Robert</pre>
</body></html>