WEBVTT
00:00:01.839 --> 00:00:04.160
Hello, EmacsConf!
00:00:04.160 --> 00:00:05.279
Thanks very much, first of all,
00:00:05.280 --> 00:00:07.200
to the organizers of the conference
00:00:07.200 --> 00:00:08.800
and to the audience,
00:00:08.801 --> 00:00:10.480
who I hope is out there somewhere,
00:00:10.480 --> 00:00:11.679
for giving me this chance
00:00:11.680 --> 00:00:12.880
to talk about Emacs
00:00:12.881 --> 00:00:16.240
and some of my poking around with Emacs Lisp.
00:00:16.241 --> 00:00:17.680
My name is Eric Abrahamsen.
00:00:17.681 --> 00:00:20.480
I'm not a professional programmer,
00:00:20.481 --> 00:00:23.039
but I use Emacs all day, every day,
00:00:23.040 --> 00:00:24.800
for writing, for translating,
00:00:24.800 --> 00:00:26.160
for project management,
00:00:26.160 --> 00:00:27.920
and most importantly, for email,
00:00:27.921 --> 00:00:30.640
which will be the subject of my talk today.
00:00:30.641 --> 00:00:32.880
So I'm talking about
00:00:32.881 --> 00:00:34.160
object-oriented code
00:00:34.161 --> 00:00:38.320
in Emacs' most famous, possibly oldest,
00:00:38.320 --> 00:00:39.520
definitely most notorious
00:00:39.521 --> 00:00:42.800
news reader / email client,
00:00:42.801 --> 00:00:44.000
so, in particular,
00:00:44.001 --> 00:00:46.000
object-oriented code in Gnus.
00:00:46.001 --> 00:00:50.239
Why object-oriented code?
00:00:50.239 --> 00:00:51.199
The way Gnus works is
00:00:51.200 --> 00:00:52.480
it started off as a news reader,
00:00:52.481 --> 00:00:55.920
so for accessing NNTP servers
00:00:55.921 --> 00:00:57.600
and later on grew a whole bunch
00:00:57.601 --> 00:00:59.760
of new functionality as a mail client,
00:00:59.761 --> 00:01:02.079
so it can talk to IMAP servers,
00:01:02.079 --> 00:01:04.320
Maildir directories,
00:01:04.321 --> 00:01:05.360
folders on your file system,
00:01:05.361 --> 00:01:06.640
all kinds of stuff,
00:01:06.640 --> 00:01:08.320
but it presents a unified interface
00:01:08.321 --> 00:01:08.960
to all those things,
00:01:08.961 --> 00:01:11.040
so it's basically polymorphism,
00:01:11.040 --> 00:01:14.560
one of the the basic fundamental principles
00:01:14.561 --> 00:01:15.680
of object oriented code.
00:01:15.681 --> 00:01:17.600
So it's a good fit.
00:01:17.601 --> 00:01:21.439
Second reason is it already is object-oriented,
00:01:21.440 --> 00:01:25.280
and I'll get into what that means in a second.
00:01:25.281 --> 00:01:28.479
So the background that you should know
00:01:28.480 --> 00:01:30.000
is that most of this code
00:01:30.001 --> 00:01:32.560
was written in the 90s.
00:01:32.560 --> 00:01:34.880
Emacs Lisp has only grown sort of
00:01:34.881 --> 00:01:38.640
official object orientation support libraries
00:01:38.640 --> 00:01:41.200
over the past 10 years or so,
00:01:41.200 --> 00:01:42.799
from about 2010 to the present.
00:01:42.800 --> 00:01:45.920
So what does Gnus do?
00:01:45.921 --> 00:01:49.520
So the basics of object orientation
00:01:49.521 --> 00:01:50.560
in most languages are:
00:01:50.560 --> 00:01:53.439
you define a class of some sort,
00:01:53.440 --> 00:01:55.040
and then you instantiate that class.
00:01:55.041 --> 00:01:57.920
These class instances have two things:
00:01:57.921 --> 00:02:00.719
they have data attributes (or slots,
00:02:00.720 --> 00:02:01.680
or members, or whatever
00:02:01.681 --> 00:02:02.640
you're going to call them),
00:02:02.641 --> 00:02:05.600
and they have methods
00:02:05.601 --> 00:02:08.399
which operate on individual instances.
00:02:08.399 --> 00:02:10.239
So you could say that
00:02:10.240 --> 00:02:11.840
you create or instantiate
00:02:11.841 --> 00:02:12.800
an instance of a class,
00:02:12.801 --> 00:02:14.800
and that instance owns two things.
00:02:14.801 --> 00:02:17.120
That owns its set of attributes,
00:02:17.120 --> 00:02:19.520
and it owns some methods,
00:02:19.521 --> 00:02:23.280
which also work on the instance.
00:02:23.280 --> 00:02:25.680
Both in Gnus' existing code
00:02:25.681 --> 00:02:28.560
and in the more standard object-oriented
00:02:28.561 --> 00:02:31.680
Emacs Lisp libraries, this relationship
00:02:31.681 --> 00:02:34.080
is turned on its head a little bit,
00:02:34.080 --> 00:02:39.599
in that data slots and instance methods
00:02:39.600 --> 00:02:41.760
are defined outside of the class
00:02:41.761 --> 00:02:42.959
or the instances themselves.
00:02:42.959 --> 00:02:45.040
They are top-level definitions.
00:02:45.040 --> 00:02:46.879
We'll get to what that means
00:02:46.879 --> 00:02:48.720
in the newer libraries in a bit,
00:02:48.721 --> 00:02:49.920
but first I want to talk about
00:02:49.921 --> 00:02:51.280
how Gnus does this.
00:02:51.281 --> 00:02:52.160
In order to do that,
00:02:52.161 --> 00:02:54.319
we are going to go deep into
00:02:54.319 --> 00:02:55.760
the darkest corner
00:02:55.761 --> 00:02:58.080
of the Gnus source code tree
00:02:58.081 --> 00:03:01.440
to a library called nnoo.el,
00:03:01.441 --> 00:03:04.080
very cryptically-titled library,
00:03:04.081 --> 00:03:06.800
and when we open it up, we find
00:03:06.800 --> 00:03:09.280
a library with no code comments
00:03:09.281 --> 00:03:11.040
and almost no doc strings.
00:03:11.040 --> 00:03:12.800
Almost as if Lars was a little ashamed--
00:03:12.800 --> 00:03:14.159
not ashamed, but knew he was doing
00:03:14.159 --> 00:03:16.000
something a little bit crazy
00:03:16.000 --> 00:03:18.080
and didn't want anyone to see.
00:03:18.081 --> 00:03:20.560
So this file contains
00:03:20.561 --> 00:03:22.400
the object-oriented mechanism
00:03:22.400 --> 00:03:23.920
whereby you can define
00:03:23.921 --> 00:03:25.760
different kinds of backends for Gnus,
00:03:25.760 --> 00:03:26.799
and then those backends
00:03:26.800 --> 00:03:30.879
can be instantiated as individual servers.
00:03:30.880 --> 00:03:32.480
As you define these backends,
00:03:32.480 --> 00:03:34.319
you're supposed to use two macros,
00:03:34.320 --> 00:03:35.680
which you can see here.
00:03:35.681 --> 00:03:37.280
One is called defvoo,
00:03:37.281 --> 00:03:39.440
and one is called deffoo.
00:03:39.441 --> 00:03:40.400
If you look at the definitions,
00:03:40.401 --> 00:03:41.920
the definitions look pretty simple.
00:03:41.921 --> 00:03:45.440
Here, defvoo basically turns into a defvar
00:03:45.440 --> 00:03:49.040
and foo turns into a defun.
00:03:49.040 --> 00:03:52.239
Along with those basic definitions,
00:03:52.239 --> 00:03:55.760
the library also does some registration,
00:03:55.760 --> 00:03:58.720
memoization, caching of those variables.
00:03:58.720 --> 00:04:00.879
It saves them in the structure for later use,
00:04:00.880 --> 00:04:03.360
so that we know that those are meant to be
00:04:03.360 --> 00:04:04.799
attributes and methods
00:04:04.800 --> 00:04:06.640
that are used with instances,
00:04:06.640 --> 00:04:07.519
with server instances.
00:04:07.520 --> 00:04:08.159
But you can see that
00:04:08.160 --> 00:04:10.000
there's no server instance definition here.
00:04:10.001 --> 00:04:12.159
There's no, like, no nothing.
00:04:12.160 --> 00:04:14.799
These are top-level definitions,
00:04:14.800 --> 00:04:20.239
so really, data attributes for new servers
00:04:20.240 --> 00:04:23.040
and methods or functions
00:04:23.041 --> 00:04:24.639
that operate on those instances
00:04:24.640 --> 00:04:27.840
are completely separate mechanisms.
00:04:27.841 --> 00:04:29.040
They don't really have anything to do
00:04:29.041 --> 00:04:29.520
with each other.
00:04:29.521 --> 00:04:31.680
They don't belong to the same data structures.
00:04:31.680 --> 00:04:34.080
So how do they work?
00:04:34.081 --> 00:04:37.120
Follow me. deffoo and defvoo,
00:04:37.120 --> 00:04:38.960
aka methods and attributes,
00:04:38.961 --> 00:04:41.360
these are all the things I just said.
00:04:41.360 --> 00:04:50.240
So when you define a a backend type in Gnus,
00:04:50.241 --> 00:04:52.400
what you get is this: a definition, a list.
00:04:52.400 --> 00:04:55.520
It'll say, there is such a backend as nnml,
00:04:55.520 --> 00:04:58.880
and these are its data attributes
00:04:58.880 --> 00:05:01.039
that any given instance can have,
00:05:01.040 --> 00:05:04.720
and then these are the functions or methods
00:05:04.721 --> 00:05:06.880
that are defined to operate on
00:05:06.880 --> 00:05:08.240
an instance of this backend,
00:05:08.241 --> 00:05:09.600
so a server that belongs to
00:05:09.601 --> 00:05:12.160
the nnml backend.
00:05:12.161 --> 00:05:13.600
So at least we have this data here.
00:05:13.601 --> 00:05:16.080
That's handy. We don't really touch that.
00:05:16.081 --> 00:05:19.600
That's, like, very, very, very deep Gnus code
00:05:19.601 --> 00:05:20.560
that doesn't really come up
00:05:20.560 --> 00:05:25.199
even as a bug squasher or whatever.
00:05:25.200 --> 00:05:26.160
We don't touch that very often,
00:05:26.161 --> 00:05:26.800
but there they are,
00:05:26.801 --> 00:05:29.199
and that's how they work.
00:05:29.200 --> 00:05:31.039
Now the next thing that obviously
00:05:31.040 --> 00:05:32.080
you want to know is, okay,
00:05:32.080 --> 00:05:33.759
where are... if I've started up Gnus,
00:05:33.760 --> 00:05:35.039
where are my servers?
00:05:35.039 --> 00:05:36.880
Where are these server objects,
00:05:36.881 --> 00:05:40.479
since this is object-oriented programming?
00:05:40.480 --> 00:05:41.520
And the weird thing
00:05:41.521 --> 00:05:43.759
that you will eventually figure out
00:05:43.760 --> 00:05:45.680
(in some cases, after years of poking around)
00:05:45.681 --> 00:05:46.880
in the Gnus source code
00:05:46.880 --> 00:05:48.880
is that servers do not exist
00:05:48.881 --> 00:05:51.360
in an ontological, philosophical sense,
00:05:51.361 --> 00:05:55.280
as objects. The primary data structures of Gnus
00:05:55.281 --> 00:05:58.160
are groups, and in sort of
00:05:58.161 --> 00:06:00.560
an object-oriented hierarchical mindset,
00:06:00.561 --> 00:06:03.039
you'd think, well, groups belong to servers,
00:06:03.040 --> 00:06:05.759
so servers must exist, but they don't.
00:06:05.759 --> 00:06:07.840
Each group... And here you can see
00:06:07.841 --> 00:06:09.360
some examples of groups...
00:06:09.360 --> 00:06:11.199
These are basically the data structures
00:06:11.199 --> 00:06:12.240
that represent a group.
00:06:12.241 --> 00:06:14.160
Each group also has a little entry here
00:06:14.161 --> 00:06:17.039
that tells you what server it belongs to,
00:06:17.039 --> 00:06:20.080
and each group replicates that data,
00:06:20.081 --> 00:06:21.600
saying which server it belongs to.
00:06:21.601 --> 00:06:24.000
So when Gnus is going through
00:06:24.001 --> 00:06:25.280
doing its business,
00:06:25.281 --> 00:06:27.039
trying to figure out updating mail
00:06:27.040 --> 00:06:28.479
from the groups or whatever,
00:06:28.480 --> 00:06:30.960
almost every time, it will cycle through
00:06:30.961 --> 00:06:32.960
all the list of groups.
00:06:32.960 --> 00:06:34.960
It'll look at all the server definitions,
00:06:34.960 --> 00:06:38.160
and it will categorize the groups by server,
00:06:38.160 --> 00:06:40.000
which is just weird,
00:06:40.001 --> 00:06:41.680
because you're sort of looking for...
00:06:41.681 --> 00:06:42.720
okay, where does the server exist?
00:06:42.721 --> 00:06:43.440
It doesn't exist.
00:06:43.441 --> 00:06:46.240
It's put together every time
00:06:46.241 --> 00:06:50.400
out of code elsewhere in the Gnus code base,
00:06:50.400 --> 00:06:53.599
specifically from these group definitions.
00:06:53.600 --> 00:06:54.479
So this is very odd,
00:06:54.480 --> 00:06:56.319
because in some sense...
00:06:56.320 --> 00:06:59.360
Like here, this one, its server is nnml
00:06:59.361 --> 00:07:01.680
and an empty string,
00:07:01.681 --> 00:07:02.880
so there's a certain sense here
00:07:02.881 --> 00:07:04.720
in which this server is not really
00:07:04.721 --> 00:07:06.160
an object at all. What it is
00:07:06.161 --> 00:07:07.120
is a set of instructions
00:07:07.121 --> 00:07:08.560
for how to find messages,
00:07:08.560 --> 00:07:10.319
and this set of instructions is:
00:07:10.320 --> 00:07:12.000
go to the default place
00:07:12.001 --> 00:07:14.000
where the user might have their mail
00:07:14.001 --> 00:07:16.319
and expect to find messages there
00:07:16.320 --> 00:07:18.479
in an nnml format, which is basically
00:07:18.480 --> 00:07:21.759
just one message per file.
00:07:21.760 --> 00:07:22.720
Any number of groups could have
00:07:22.721 --> 00:07:24.400
those same instructions, but they're not...
00:07:24.401 --> 00:07:25.440
It's not really a thing.
00:07:25.440 --> 00:07:26.720
It's really just a...
00:07:26.720 --> 00:07:28.639
It's more of a procedural instruction.
00:07:28.639 --> 00:07:30.160
On the other end of the spectrum,
00:07:30.161 --> 00:07:32.240
you might have an nnimap server,
00:07:32.241 --> 00:07:33.280
which very much is a thing.
00:07:33.281 --> 00:07:36.160
It has its own server, its own port,
00:07:36.161 --> 00:07:38.960
its own authentication system.
00:07:38.961 --> 00:07:40.639
So some of the servers are more like things,
00:07:40.640 --> 00:07:42.400
some of the servers are more like instructions.
00:07:42.400 --> 00:07:45.520
As Gnus works right now,
00:07:45.520 --> 00:07:47.280
most of the servers are treated like
00:07:47.280 --> 00:07:48.879
just instruction sets,
00:07:48.879 --> 00:07:50.879
and there's no place where you can
00:07:50.880 --> 00:07:51.840
go and find them.
00:07:51.841 --> 00:07:53.680
There's no one central variable
00:07:53.681 --> 00:07:56.160
that defines them all. So how do the...
00:07:56.160 --> 00:07:57.759
We'll talk about the methods in a second.
00:07:57.760 --> 00:07:59.520
How do the data attributes work?
00:07:59.520 --> 00:08:02.639
Put very crudely,
00:08:02.639 --> 00:08:04.479
your servers, when they're put together,
00:08:04.479 --> 00:08:06.879
they are kept in a variable,
00:08:06.880 --> 00:08:08.080
and it's called nnoo
00:08:08.080 --> 00:08:08.960
nno
00:08:08.960 --> 00:08:11.120
state a list and there's a concept to
00:08:11.120 --> 00:08:12.960
this of the current server
00:08:12.960 --> 00:08:16.560
so when we go here let's go back to
00:08:16.560 --> 00:08:19.039
our nnno definition a list so when we
00:08:19.039 --> 00:08:20.560
have an nnml
00:08:20.560 --> 00:08:22.240
server say we have one here and it's
00:08:22.240 --> 00:08:24.400
just this blank string
00:08:24.400 --> 00:08:26.639
these are all when you define that in
00:08:26.639 --> 00:08:28.879
your own uh server definition code
00:08:28.879 --> 00:08:31.919
you can put in different values for all
00:08:31.919 --> 00:08:32.399
of these
00:08:32.399 --> 00:08:35.760
various attributes and when noose comes
00:08:35.760 --> 00:08:37.039
when it comes time for news to operate
00:08:37.039 --> 00:08:38.959
on this server in particular ask it to
00:08:38.959 --> 00:08:40.640
you know open a group or get new mail
00:08:40.640 --> 00:08:42.080
what it will do is it will take
00:08:42.080 --> 00:08:45.360
that particular server's data from these
00:08:45.360 --> 00:08:45.920
symbols
00:08:45.920 --> 00:08:47.600
and it will copy all that information
00:08:47.600 --> 00:08:49.600
into the global devfars
00:08:49.600 --> 00:08:51.760
so for the time that you are operating
00:08:51.760 --> 00:08:53.120
on this particular server
00:08:53.120 --> 00:08:55.920
its individual data becomes the values
00:08:55.920 --> 00:08:56.800
of these global
00:08:56.800 --> 00:08:59.360
variables which when you realize what's
00:08:59.360 --> 00:09:00.560
happening is sort of terrifying you
00:09:00.560 --> 00:09:02.080
think oh my god
00:09:02.080 --> 00:09:04.480
but at the same time it's actually kind
00:09:04.480 --> 00:09:05.760
of impressive and it's amazing that it
00:09:05.760 --> 00:09:07.279
works as well as it does
00:09:07.279 --> 00:09:09.120
I'm actually a little bit in awe of the
00:09:09.120 --> 00:09:10.880
of the code in this in this library I
00:09:10.880 --> 00:09:12.560
think it's pretty impressive
00:09:12.560 --> 00:09:15.760
so as you nno change server
00:09:15.760 --> 00:09:18.320
uh this function here these values get
00:09:18.320 --> 00:09:20.080
copied into the global value into the
00:09:20.080 --> 00:09:21.440
global variables and then as you go on
00:09:21.440 --> 00:09:22.399
the next server
00:09:22.399 --> 00:09:24.000
that gets you know cleaned out and
00:09:24.000 --> 00:09:26.399
recopied there are a few
00:09:26.399 --> 00:09:29.680
um a few other slot types
00:09:29.680 --> 00:09:32.000
or attribute types which do because all
00:09:32.000 --> 00:09:33.440
of these attributes see they all start
00:09:33.440 --> 00:09:34.720
with the nml
00:09:34.720 --> 00:09:37.920
or in this case and in folder prefix
00:09:37.920 --> 00:09:40.560
but there are a few slot types that all
00:09:40.560 --> 00:09:41.760
servers need for
00:09:41.760 --> 00:09:43.279
for instance their most recent status
00:09:43.279 --> 00:09:45.920
message a status symbol like open denied
00:09:45.920 --> 00:09:46.640
whatever
00:09:46.640 --> 00:09:48.080
and that data is sort of scattered
00:09:48.080 --> 00:09:49.680
around the rest of the news
00:09:49.680 --> 00:09:51.200
code base in various variables or
00:09:51.200 --> 00:09:53.440
various places
00:09:53.440 --> 00:09:55.440
so that's that sort of just contributes
00:09:55.440 --> 00:09:56.560
to the confusion when you're trying to
00:09:56.560 --> 00:09:57.360
figure out why
00:09:57.360 --> 00:10:00.720
things are going wrong so that is our
00:10:00.720 --> 00:10:03.839
um nnoo which is and
00:10:03.839 --> 00:10:05.440
sort of how the attributes and these
00:10:05.440 --> 00:10:07.360
global variables work
00:10:07.360 --> 00:10:09.120
if we want to talk about defu and the
00:10:09.120 --> 00:10:10.480
methods we
00:10:10.480 --> 00:10:20.800
go to
00:10:20.800 --> 00:10:23.200
and so this is the place where all the
00:10:23.200 --> 00:10:25.600
server level methods are defined
00:10:25.600 --> 00:10:27.200
and what we have here are things like
00:10:27.200 --> 00:10:29.279
here's an example there's closed server
00:10:29.279 --> 00:10:32.640
this closed server is given a
00:10:32.640 --> 00:10:36.320
a server as a an argument
00:10:36.320 --> 00:10:38.079
it looks at the server and basically it
00:10:38.079 --> 00:10:40.560
finds the proper function to call on
00:10:40.560 --> 00:10:42.079
this particular server
00:10:42.079 --> 00:10:45.120
using the function new skip function by
00:10:45.120 --> 00:10:45.600
taking
00:10:45.600 --> 00:10:48.959
the sort of latter half of this function
00:10:48.959 --> 00:10:49.760
symbol
00:10:49.760 --> 00:10:52.079
and pasting it together with the symbol
00:10:52.079 --> 00:10:53.440
that represents the back end so
00:10:53.440 --> 00:10:56.800
if you were calling this on an nni map
00:10:56.800 --> 00:10:59.600
server your skip function would look at
00:10:59.600 --> 00:11:01.279
your imap server look at closed server I
00:11:01.279 --> 00:11:02.240
knew what
00:11:02.240 --> 00:11:07.839
it would come up with
00:11:07.839 --> 00:11:10.240
server sure enough there's an imac close
00:11:10.240 --> 00:11:11.920
server and it'll call this code and then
00:11:11.920 --> 00:11:12.240
it'll
00:11:12.240 --> 00:11:14.000
it'll go and do its other bookkeeping
00:11:14.000 --> 00:11:15.279
another sort of
00:11:15.279 --> 00:11:18.320
surrounding code and so that's not that
00:11:18.320 --> 00:11:19.279
actually works pretty well
00:11:19.279 --> 00:11:22.640
uh as as things go uh defu
00:11:22.640 --> 00:11:24.959
makes a record that this this function
00:11:24.959 --> 00:11:26.800
exists and nus gets function get
00:11:26.800 --> 00:11:28.320
function looks on that cache finds the
00:11:28.320 --> 00:11:29.600
function and calls it
00:11:29.600 --> 00:11:30.959
now what's particularly confusing is
00:11:30.959 --> 00:11:32.560
that you don't actually even have to use
00:11:32.560 --> 00:11:33.360
defu
00:11:33.360 --> 00:11:35.519
so whoever wrote and then mail gear
00:11:35.519 --> 00:11:38.399
which is a weird library
00:11:38.399 --> 00:11:39.920
said to heck with you I'm not using any
00:11:39.920 --> 00:11:41.600
of these
00:11:41.600 --> 00:11:43.120
any of this machinery I'm going to do it
00:11:43.120 --> 00:11:45.839
myself so we have
00:11:45.839 --> 00:11:49.680
def structs to hold uh the instance
00:11:49.680 --> 00:11:52.320
data and then we have just plain old
00:11:52.320 --> 00:11:53.040
defense
00:11:53.040 --> 00:11:55.680
for things like animal your close server
00:11:55.680 --> 00:11:57.279
request close all of these
00:11:57.279 --> 00:11:59.279
these server level uh variables and it
00:11:59.279 --> 00:12:00.320
just turns out that
00:12:00.320 --> 00:12:03.360
news in its belt and suspenders
00:12:03.360 --> 00:12:05.839
approach to uh to coding it'll actually
00:12:05.839 --> 00:12:07.279
just go out if it can't find
00:12:07.279 --> 00:12:10.320
the memoized function it'll just go out
00:12:10.320 --> 00:12:12.160
and say has anybody defined a function
00:12:12.160 --> 00:12:14.240
that looks like this pattern and then
00:12:14.240 --> 00:12:16.000
and then melder says yes I did and then
00:12:16.000 --> 00:12:17.920
we call it and then we go so it's just
00:12:17.920 --> 00:12:19.920
it's fine it works it just adds to the
00:12:19.920 --> 00:12:21.440
confusion why
00:12:21.440 --> 00:12:24.240
why does it work we don't know sometimes
00:12:24.240 --> 00:12:25.440
the only thing worse than not knowing
00:12:25.440 --> 00:12:26.880
why something doesn't work is
00:12:26.880 --> 00:12:30.000
not knowing why something does work um
00:12:30.000 --> 00:12:30.560
and then
00:12:30.560 --> 00:12:31.920
a last little bit I want to touch on
00:12:31.920 --> 00:12:33.680
here is inheritance which is another
00:12:33.680 --> 00:12:35.440
sort of cornerstone of object-oriented
00:12:35.440 --> 00:12:38.480
coding as far as I can tell only uh
00:12:38.480 --> 00:12:40.160
the only inheritance that goes on is in
00:12:40.160 --> 00:12:41.920
something called nn male
00:12:41.920 --> 00:12:45.519
which provides sort of common functions
00:12:45.519 --> 00:12:48.399
for back ends that keep their mail on
00:12:48.399 --> 00:12:49.360
your
00:12:49.360 --> 00:12:52.000
local machine and you can spool it you
00:12:52.000 --> 00:12:53.680
can delete it you can you know you own
00:12:53.680 --> 00:12:55.440
the messages it's not like an nntp
00:12:55.440 --> 00:12:56.160
server
00:12:56.160 --> 00:12:59.040
and so a lot of those male deer nnml
00:12:59.040 --> 00:13:00.160
whatever
00:13:00.160 --> 00:13:02.959
a lot of those have sort of similar code
00:13:02.959 --> 00:13:04.079
which they
00:13:04.079 --> 00:13:07.600
which they share via this nn mail
00:13:07.600 --> 00:13:09.600
you call it an abstract parent class I
00:13:09.600 --> 00:13:12.959
guess so if you have something like nnml
00:13:12.959 --> 00:13:15.440
it has a request scan uh when it goes
00:13:15.440 --> 00:13:16.720
into request scan
00:13:16.720 --> 00:13:18.800
it ends up calling nnmail.newmail and it
00:13:18.800 --> 00:13:21.760
says I am calling this as an nml server
00:13:21.760 --> 00:13:23.279
and here are some of my callback
00:13:23.279 --> 00:13:24.959
functions and my variables that I would
00:13:24.959 --> 00:13:26.000
like you to use
00:13:26.000 --> 00:13:28.000
when you are getting your email so in
00:13:28.000 --> 00:13:30.120
this way the code is sort of you know
00:13:30.120 --> 00:13:33.120
inter-interleaved between the the child
00:13:33.120 --> 00:13:35.680
class and the parent class even though
00:13:35.680 --> 00:13:37.120
we're not talking in terms of classes
00:13:37.120 --> 00:13:39.440
here at all really
00:13:39.440 --> 00:13:42.160
so that's how noose works right now I
00:13:42.160 --> 00:13:42.959
hope that's clear
00:13:42.959 --> 00:13:45.519
it certainly wasn't to me and I still
00:13:45.519 --> 00:13:46.560
have to go refresh my
00:13:46.560 --> 00:13:48.079
memory I'd like to talk a little bit
00:13:48.079 --> 00:13:50.079
about sort of the newer
00:13:50.079 --> 00:13:51.600
libraries that are available now for
00:13:51.600 --> 00:13:54.240
doing object-oriented code
00:13:54.240 --> 00:13:56.959
uh as I mentioned I think earlier nno
00:13:56.959 --> 00:13:59.279
the copyright headers for 1996 so that's
00:13:59.279 --> 00:14:00.320
pretty venerable
00:14:00.320 --> 00:14:02.639
coincidentally around the same time eric
00:14:02.639 --> 00:14:05.519
ludlum started developing e-I-e-I-o
00:14:05.519 --> 00:14:08.320
which is a which is sort of inspired by
00:14:08.320 --> 00:14:09.360
a common lisp's
00:14:09.360 --> 00:14:12.720
common lisp object system um I got a
00:14:12.720 --> 00:14:14.240
very good introduction to that from this
00:14:14.240 --> 00:14:14.959
book
00:14:14.959 --> 00:14:16.399
practical common lisp which I would
00:14:16.399 --> 00:14:18.000
encourage you to look at if you haven't
00:14:18.000 --> 00:14:20.079
which you probably have anyway
00:14:20.079 --> 00:14:22.320
e-I-e-I-o was incorporated into Emacs in
00:14:22.320 --> 00:14:23.920
2010
00:14:23.920 --> 00:14:27.839
so that yeah e-I-e-I-o provides um
00:14:27.839 --> 00:14:30.240
the deaf class statements it provides
00:14:30.240 --> 00:14:32.079
deaf generics deaf methods all that sort
00:14:32.079 --> 00:14:32.639
of stuff
00:14:32.639 --> 00:14:34.800
sort of a common lisp object-oriented
00:14:34.800 --> 00:14:36.320
code
00:14:36.320 --> 00:14:38.399
at some point stephan monier's money
00:14:38.399 --> 00:14:39.760
money another name I haven't pronounced
00:14:39.760 --> 00:14:41.199
it all out
00:14:41.199 --> 00:14:43.839
started either cleaning up that code or
00:14:43.839 --> 00:14:45.120
for one reason or another writing a
00:14:45.120 --> 00:14:46.959
re-implementation of generic functions
00:14:46.959 --> 00:14:48.000
which was added
00:14:48.000 --> 00:14:51.440
uh in 2015 and then throughout this time
00:14:51.440 --> 00:14:51.920
another
00:14:51.920 --> 00:14:54.639
sort of object-oriented style
00:14:54.639 --> 00:14:55.760
declaration is
00:14:55.760 --> 00:14:58.160
defstruct which started off in the cl
00:14:58.160 --> 00:15:00.000
libraries
00:15:00.000 --> 00:15:01.600
implemented with vectors later was
00:15:01.600 --> 00:15:02.959
implemented with records so they're
00:15:02.959 --> 00:15:04.639
easier to target
00:15:04.639 --> 00:15:06.720
anyway that's another option so how
00:15:06.720 --> 00:15:08.399
would we this is I'm probably out of
00:15:08.399 --> 00:15:09.279
time already but
00:15:09.279 --> 00:15:13.839
we're only getting to the part
00:15:13.839 --> 00:15:15.760
the whole point of this is how would we
00:15:15.760 --> 00:15:17.920
rewrite someone news's code to use these
00:15:17.920 --> 00:15:19.920
newer libraries
00:15:19.920 --> 00:15:21.760
if we didn't have to support third party
00:15:21.760 --> 00:15:23.839
libraries this wouldn't be that hard
00:15:23.839 --> 00:15:26.639
but out there noose is really up on uh
00:15:26.639 --> 00:15:28.160
you know backwards compatibility and not
00:15:28.160 --> 00:15:30.240
breaking people's stuff and you know
00:15:30.240 --> 00:15:33.040
multi-decade support for things so there
00:15:33.040 --> 00:15:34.240
are people out there who have written
00:15:34.240 --> 00:15:35.759
third-party libraries
00:15:35.759 --> 00:15:38.480
um defining new backends for you can use
00:15:38.480 --> 00:15:40.000
like hacker news or whatever as
00:15:40.000 --> 00:15:41.759
a as a server so we want to be able to
00:15:41.759 --> 00:15:43.199
support those if you didn't have to
00:15:43.199 --> 00:15:44.240
support those it'd be fine you'd
00:15:44.240 --> 00:15:46.079
re-implement you'd use generic functions
00:15:46.079 --> 00:15:47.440
you'd use either structure classes
00:15:47.440 --> 00:15:48.560
whatever but we got a
00:15:48.560 --> 00:15:51.040
it's a little bit tricky to support
00:15:51.040 --> 00:15:52.000
these other people's
00:15:52.000 --> 00:15:54.320
libraries so one of the things we can do
00:15:54.320 --> 00:15:56.079
is rewrite the defu
00:15:56.079 --> 00:15:59.279
so if you remember defu is the thing
00:15:59.279 --> 00:16:00.079
that uh
00:16:00.079 --> 00:16:03.120
or sorry uh defu
00:16:03.120 --> 00:16:04.800
is the thing that defines methods that
00:16:04.800 --> 00:16:07.040
operate on object answers
00:16:07.040 --> 00:16:10.160
instances and we can uh rewrite that to
00:16:10.160 --> 00:16:10.639
use
00:16:10.639 --> 00:16:13.440
cldef generic and that's this is fairly
00:16:13.440 --> 00:16:14.240
fairly simple
00:16:14.240 --> 00:16:15.440
it looks like a lot of code it's not a
00:16:15.440 --> 00:16:17.759
lot of good for instance we have the
00:16:17.759 --> 00:16:20.320
new closed server code that we looked at
00:16:20.320 --> 00:16:21.199
earlier
00:16:21.199 --> 00:16:22.720
and we have this phone call and the new
00:16:22.720 --> 00:16:24.560
skip function so this would look
00:16:24.560 --> 00:16:28.720
like using generic functions and methods
00:16:28.720 --> 00:16:30.240
it would look like this we'd have
00:16:30.240 --> 00:16:32.959
a generic def generic which is just a
00:16:32.959 --> 00:16:34.560
sort of a declaration
00:16:34.560 --> 00:16:36.320
and a doc string and then we have those
00:16:36.320 --> 00:16:37.680
implementations
00:16:37.680 --> 00:16:40.320
so we can see what the original code
00:16:40.320 --> 00:16:42.399
does here is it first says okay what
00:16:42.399 --> 00:16:44.720
type is our our is our argument here and
00:16:44.720 --> 00:16:45.839
if it's a string
00:16:45.839 --> 00:16:48.560
then go and get the proper s the proper
00:16:48.560 --> 00:16:50.160
method definition
00:16:50.160 --> 00:16:52.480
from that string so the way we do that
00:16:52.480 --> 00:16:53.920
with methods is we
00:16:53.920 --> 00:16:56.000
we say if the server is a string so if
00:16:56.000 --> 00:16:57.440
it matches this type
00:16:57.440 --> 00:16:58.720
then what we're going to do is just
00:16:58.720 --> 00:17:00.320
recall we're going to call this function
00:17:00.320 --> 00:17:02.160
all over again
00:17:02.160 --> 00:17:05.199
using uh basically the same code here
00:17:05.199 --> 00:17:06.400
the same code that takes a string and
00:17:06.400 --> 00:17:07.600
gets the object so
00:17:07.600 --> 00:17:10.640
this does this can add extra function
00:17:10.640 --> 00:17:11.600
calls
00:17:11.600 --> 00:17:12.880
depending on how you've written the rest
00:17:12.880 --> 00:17:14.880
of your code um but this is sort of the
00:17:14.880 --> 00:17:16.640
canonical way of doing this
00:17:16.640 --> 00:17:19.679
uh using methods then our next part here
00:17:19.679 --> 00:17:20.559
is
00:17:20.559 --> 00:17:22.000
nishkit function we're going to get a
00:17:22.000 --> 00:17:24.559
function called closed server
00:17:24.559 --> 00:17:26.079
the difference here is that all these
00:17:26.079 --> 00:17:27.360
functions are all going to be called
00:17:27.360 --> 00:17:28.000
close
00:17:28.000 --> 00:17:29.360
news close server they're not going to
00:17:29.360 --> 00:17:31.120
be called news like nni my
00:17:31.120 --> 00:17:32.799
closed server and ntp close server
00:17:32.799 --> 00:17:34.400
they're all going to have the same name
00:17:34.400 --> 00:17:36.160
and what we do is uh we have an around
00:17:36.160 --> 00:17:37.440
method
00:17:37.440 --> 00:17:40.640
for any server that is a const which is
00:17:40.640 --> 00:17:43.679
which is as close as we care to get uh
00:17:43.679 --> 00:17:45.520
for you know zeroing in on the type that
00:17:45.520 --> 00:17:46.799
we're looking for
00:17:46.799 --> 00:17:48.559
we put in a round method on that so that
00:17:48.559 --> 00:17:50.480
we can call the next method which we'll
00:17:50.480 --> 00:17:51.679
call the more specific
00:17:51.679 --> 00:17:53.440
method and then we have our other
00:17:53.440 --> 00:17:55.600
bookkeeping code to clean up you know
00:17:55.600 --> 00:17:57.280
set up tear down code we'll go around
00:17:57.280 --> 00:17:58.640
that
00:17:58.640 --> 00:18:00.080
and then in one of the back-end
00:18:00.080 --> 00:18:02.080
definitions for instance in an imap
00:18:02.080 --> 00:18:04.320
we have another news closed server thing
00:18:04.320 --> 00:18:05.760
this looks at the server
00:18:05.760 --> 00:18:08.880
and it says is this server a list that
00:18:08.880 --> 00:18:10.799
starts with a symbol and an imap and if
00:18:10.799 --> 00:18:12.480
it is then we're almost guaranteed that
00:18:12.480 --> 00:18:13.679
this is what we wanted
00:18:13.679 --> 00:18:15.840
and then this is where we would insert
00:18:15.840 --> 00:18:17.600
all the rest of the code from anonymous
00:18:17.600 --> 00:18:18.960
closed server
00:18:18.960 --> 00:18:20.799
where we'd re-redefine that to look like
00:18:20.799 --> 00:18:22.880
this so it's not that hard
00:18:22.880 --> 00:18:26.080
theoretically so what we would do
00:18:26.080 --> 00:18:28.720
is take the defu macro macro and then
00:18:28.720 --> 00:18:29.679
rewrite that
00:18:29.679 --> 00:18:32.240
so that it actually defines a cl def
00:18:32.240 --> 00:18:33.039
method like
00:18:33.039 --> 00:18:35.520
one of these now there's a couple of
00:18:35.520 --> 00:18:36.320
these things
00:18:36.320 --> 00:18:38.960
unfortunately it's not that easy get rid
00:18:38.960 --> 00:18:41.200
of you
00:18:41.200 --> 00:18:43.490
a couple of these things
00:18:43.490 --> 00:18:46.400
[Music]
00:18:46.400 --> 00:18:49.039
that don't use their server as the first
00:18:49.039 --> 00:18:49.919
argument
00:18:49.919 --> 00:18:52.400
or any of the arguments or it's an
00:18:52.400 --> 00:18:53.280
optional argument
00:18:53.280 --> 00:18:54.720
and we need the server to be in there to
00:18:54.720 --> 00:18:56.640
dispatch on its type
00:18:56.640 --> 00:18:58.799
if the server doesn't show up as a as a
00:18:58.799 --> 00:19:00.080
required
00:19:00.080 --> 00:19:01.760
argument we're not going to be able to
00:19:01.760 --> 00:19:03.600
locate the the proper
00:19:03.600 --> 00:19:07.440
function call so in the case of
00:19:07.440 --> 00:19:10.640
noose request group here we start with
00:19:10.640 --> 00:19:12.080
the group it's the group that matters
00:19:12.080 --> 00:19:12.720
and we get
00:19:12.720 --> 00:19:14.960
the newscommand method as an optional
00:19:14.960 --> 00:19:16.240
argument
00:19:16.240 --> 00:19:18.559
so that's not cool we don't want that so
00:19:18.559 --> 00:19:20.480
what we need instead is something that
00:19:20.480 --> 00:19:21.360
looks like this
00:19:21.360 --> 00:19:23.840
what we're going to do with uh this is
00:19:23.840 --> 00:19:25.360
gonna be just terrible terrible code but
00:19:25.360 --> 00:19:26.640
hopefully it won't get used very often
00:19:26.640 --> 00:19:28.160
it's gonna be really embarrassing
00:19:28.160 --> 00:19:30.559
um defu what's what definitely was gonna
00:19:30.559 --> 00:19:31.520
have to do is
00:19:31.520 --> 00:19:33.200
say okay is this a function that doesn't
00:19:33.200 --> 00:19:34.559
have the server as the first argument
00:19:34.559 --> 00:19:35.360
and if it does
00:19:35.360 --> 00:19:36.960
it's gonna say oh it's news request
00:19:36.960 --> 00:19:38.400
group what happens has to happen with
00:19:38.400 --> 00:19:39.280
news request group
00:19:39.280 --> 00:19:40.799
is we take the news command method and
00:19:40.799 --> 00:19:43.200
we're going to move it up to the front
00:19:43.200 --> 00:19:46.240
to the first argument here and it's
00:19:46.240 --> 00:19:47.520
either going to be
00:19:47.520 --> 00:19:48.720
it's either going to be given or it's
00:19:48.720 --> 00:19:50.840
going to be nil because it's it is
00:19:50.840 --> 00:19:52.080
optional
00:19:52.080 --> 00:19:54.320
okay I briefly edited the space time
00:19:54.320 --> 00:19:55.760
continuum there to conceal the fact that
00:19:55.760 --> 00:19:56.400
I had
00:19:56.400 --> 00:19:57.679
actually not finished writing the code
00:19:57.679 --> 00:19:59.440
that I was supposed to write anyway
00:19:59.440 --> 00:20:02.159
um so now we have once we've reordered
00:20:02.159 --> 00:20:02.960
the
00:20:02.960 --> 00:20:04.320
the arguments to the function then we
00:20:04.320 --> 00:20:05.760
have to check our various possible
00:20:05.760 --> 00:20:06.880
values one is
00:20:06.880 --> 00:20:08.640
uh that the server was not passed in in
00:20:08.640 --> 00:20:10.080
which case we recall
00:20:10.080 --> 00:20:12.400
request group with the server um the
00:20:12.400 --> 00:20:13.840
other is that it's just a string in
00:20:13.840 --> 00:20:15.360
which case we do that and then this is
00:20:15.360 --> 00:20:16.559
sort of the the normal
00:20:16.559 --> 00:20:18.559
the normal case that we would expect to
00:20:18.559 --> 00:20:20.720
cons so that's not that bad it's not you
00:20:20.720 --> 00:20:21.039
know
00:20:21.039 --> 00:20:23.760
it's not beautiful um I would be sort of
00:20:23.760 --> 00:20:24.480
ashamed to
00:20:24.480 --> 00:20:26.159
let anybody see that particular macro
00:20:26.159 --> 00:20:28.000
but I think that it would work okay
00:20:28.000 --> 00:20:30.640
now the more difficult thing is going to
00:20:30.640 --> 00:20:31.440
be
00:20:31.440 --> 00:20:34.640
the data variables so
00:20:34.640 --> 00:20:37.600
the equivalent of def vu because our two
00:20:37.600 --> 00:20:39.360
options for defining classes here are
00:20:39.360 --> 00:20:41.039
def struct and def class both of which
00:20:41.039 --> 00:20:41.919
required you
00:20:41.919 --> 00:20:45.280
to define the slots inside this macro
00:20:45.280 --> 00:20:46.960
itself
00:20:46.960 --> 00:20:49.039
so defu is top level um how do we get
00:20:49.039 --> 00:20:51.280
the top level this top level macro
00:20:51.280 --> 00:20:55.039
uh to insert slot names into these
00:20:55.039 --> 00:20:56.240
definitions it's
00:20:56.240 --> 00:20:58.960
it's possible that it'll be um that I
00:20:58.960 --> 00:21:00.240
could monkey patch
00:21:00.240 --> 00:21:03.039
uh an existing struct or an existing
00:21:03.039 --> 00:21:04.799
class to add a new slot into it that
00:21:04.799 --> 00:21:05.280
sounds
00:21:05.280 --> 00:21:07.760
ugly the other option would be to give
00:21:07.760 --> 00:21:09.600
it a server variable slot which is just
00:21:09.600 --> 00:21:11.520
a generalized bucket
00:21:11.520 --> 00:21:13.760
that holds anything that gets defined
00:21:13.760 --> 00:21:15.520
via def loop
00:21:15.520 --> 00:21:16.720
I don't like either of those solutions
00:21:16.720 --> 00:21:18.799
but I'm I don't see any other
00:21:18.799 --> 00:21:22.480
any other way of doing that so we re
00:21:22.480 --> 00:21:25.520
rewrite the nno declare macro to either
00:21:25.520 --> 00:21:27.440
be a destructor or a def class
00:21:27.440 --> 00:21:29.840
and we rewrite the def boom macro to
00:21:29.840 --> 00:21:31.039
somehow
00:21:31.039 --> 00:21:33.039
associate that variable name the symbol
00:21:33.039 --> 00:21:34.480
with the with the resulting class
00:21:34.480 --> 00:21:36.159
definition
00:21:36.159 --> 00:21:37.760
then the last question is do we use
00:21:37.760 --> 00:21:39.600
structure classes
00:21:39.600 --> 00:21:41.600
they both got their their strengths and
00:21:41.600 --> 00:21:43.200
their weaknesses
00:21:43.200 --> 00:21:46.480
the nice thing is that I mean I've got
00:21:46.480 --> 00:21:47.520
how many servers you're going to have
00:21:47.520 --> 00:21:49.600
really I've got I think less than 10
00:21:49.600 --> 00:21:51.919
uh truly deranged mine might have as as
00:21:51.919 --> 00:21:52.960
many as
00:21:52.960 --> 00:21:55.440
50 let's double that to 100 100 of
00:21:55.440 --> 00:21:56.480
anything is not going to matter it
00:21:56.480 --> 00:21:58.400
doesn't matter what we use
00:21:58.400 --> 00:22:00.159
death structures are simpler they're
00:22:00.159 --> 00:22:02.720
lighter weight they're defined on top of
00:22:02.720 --> 00:22:05.600
the direct the c records so you know
00:22:05.600 --> 00:22:06.960
that's nice
00:22:06.960 --> 00:22:08.559
the slots don't carry very much
00:22:08.559 --> 00:22:10.320
information with them there's no type
00:22:10.320 --> 00:22:11.760
information there's no doc string for
00:22:11.760 --> 00:22:14.480
the slots themselves
00:22:14.480 --> 00:22:16.559
they can also only do single inheritance
00:22:16.559 --> 00:22:17.919
which some might say
00:22:17.919 --> 00:22:21.120
was an advantage def class each slot
00:22:21.120 --> 00:22:22.640
gets a lot more information associated
00:22:22.640 --> 00:22:24.000
with it with it which I think can be
00:22:24.000 --> 00:22:24.480
nice
00:22:24.480 --> 00:22:27.120
it can do multiple inheritance if you're
00:22:27.120 --> 00:22:28.799
going to go there
00:22:28.799 --> 00:22:30.720
they are heavier weight in particular
00:22:30.720 --> 00:22:32.640
their printed representation is gross
00:22:32.640 --> 00:22:34.080
it's enormous
00:22:34.080 --> 00:22:35.840
so if you see one show up in a back
00:22:35.840 --> 00:22:37.520
trace or in your messages buffer can
00:22:37.520 --> 00:22:38.240
really
00:22:38.240 --> 00:22:39.520
it can really blow that up and make it
00:22:39.520 --> 00:22:41.360
hard to read this of course won't be an
00:22:41.360 --> 00:22:43.200
issue because our code won't have any
00:22:43.200 --> 00:22:46.240
errors in it um my argument for multiple
00:22:46.240 --> 00:22:48.320
inheritance here is that I can imagine
00:22:48.320 --> 00:22:51.280
new servers falling into sort of like a
00:22:51.280 --> 00:22:52.720
little two by two matrix of
00:22:52.720 --> 00:22:56.240
of parent classes one being news versus
00:22:56.240 --> 00:22:56.799
mail
00:22:56.799 --> 00:23:00.320
so news the messages belong to somebody
00:23:00.320 --> 00:23:00.720
else
00:23:00.720 --> 00:23:02.080
you can't touch them you can't delete
00:23:02.080 --> 00:23:03.840
them mail meaning
00:23:03.840 --> 00:23:06.000
the messages are under your command
00:23:06.000 --> 00:23:08.960
either a local mail dealer a remote imap
00:23:08.960 --> 00:23:11.039
you're allowed to spool them copy them
00:23:11.039 --> 00:23:12.640
delete them at will
00:23:12.640 --> 00:23:13.919
and then the other sort of line of the
00:23:13.919 --> 00:23:16.400
matrix would be a local file system
00:23:16.400 --> 00:23:19.760
versus some kind of a you know server
00:23:19.760 --> 00:23:20.559
port
00:23:20.559 --> 00:23:23.280
remote access and that second the server
00:23:23.280 --> 00:23:24.960
port remote access thing might require
00:23:24.960 --> 00:23:26.880
authentication it might require a keep
00:23:26.880 --> 00:23:28.559
alive for a connection
00:23:28.559 --> 00:23:30.159
um it's there's going to be a process
00:23:30.159 --> 00:23:31.600
there rather than just file system
00:23:31.600 --> 00:23:32.400
commands
00:23:32.400 --> 00:23:33.840
so I could see if I was going to do
00:23:33.840 --> 00:23:35.360
multiple inheritance that's what I would
00:23:35.360 --> 00:23:36.240
do those two
00:23:36.240 --> 00:23:39.039
those two possible parent classes anyway
00:23:39.039 --> 00:23:40.400
that's as far as I've gotten
00:23:40.400 --> 00:23:41.520
I thought that I would be able to write
00:23:41.520 --> 00:23:43.279
more of this code before I did this talk
00:23:43.279 --> 00:23:44.720
but instead I spent the whole time
00:23:44.720 --> 00:23:46.720
messing with video codecs but that's
00:23:46.720 --> 00:23:48.320
where we're at and I'm going to cut
00:23:48.320 --> 00:23:49.440
myself off now
00:23:49.440 --> 00:23:50.960
I hope there are questions I hope I'm
00:23:50.960 --> 00:23:53.440
there to to answer your questions
00:23:53.440 --> 00:23:55.919
and thanks very much again to everyone
00:23:55.919 --> 00:23:57.120
involved
00:23:57.120 --> 00:23:59.279
bye
