| Thread Previous • Date Previous • Date Next • Thread Next |
This is a list of projects that can be worked upon immediately.
requirements
It's necessary to ensure that if said code is written in either C++
or C (the only two languages that can be of use at such an early
stage, sorry), that the following has to be satisfied:
* *ALL CODE* written must be encapsulated within a namespace.
This is to ensure that said components can be easily
classified in documentation.
* *EACH SOURCE DOCUMENT* must have some kind of documentation as
to what a specified method or function does, or the purpose of
a static value. Local variables do not have to be documented,
but all arguments should be, as well the return values.
projects
1. (group)wintermute-core
This project is one that the team will work on in a group, but
for now, there's not too much to represent it. If you feel
that you can propose a good idea of a core infrastructure for
Wintermute, please consider the following:
* wintermute-core has to be able to load, register, query
and interact with plug-ins, and their inverses. The kind
of plug-ins that Wintermute *absolutely *needs for
operation would be:
o wintermute-plug in-output: A base plug-in that
permits other plug-ins to render some kind of
output for Wintermute in a generic format, like
speech synthesis, braille output, stdout, etc.
/This code should be under Wintermute/
o wintermute-plug in-input: A base plug-in that
permits other plug-ins to render some kind of
output for Wintermute in a generic format, like
voice/speech recognition, braille input, stdin, etc.
o wintermute-plug in-test: A plug-in that permits
standard tests of Wintermute's core and a base
system for having other plug-ins integrate their
own testing run-times into Wintermute's testing
utility.
Mind you, this part has to be tackled hand-in-hand
with Wintermute::Plug ins*.
*/The plug in infrastructure should be under
/namespace Wintermute::Plug ins.
* wintermute-core has to be able to run *tests*, check the
integrity of the wintermute-plug in-test and other
possible features to come, although this portion relies
heavily on the capabilities of wintermute-plug in-test.
/The test runtimes should be
under/namespace/Wintermute::Diagnostics./
2. (core) Wintermute::Plug ins
This is perhaps the most vital part of Wintermute's
extensibility. The plug in architecture described should have
generic plug-in exceptions, event handlers, and a system of
loading and registering plug-ins.
To be realistic, the aforementioned projects are going to dictate
the flow of productivity of Wintermute. The whole idea of having an
internal plug in infrastructure permits Wintermute to grow,
literally. In order for Wintermute to reach an autonomous state (a
big goal for AI, transitioning to AGI), the plug-in architecture is
needed. And individual components can determine capability features
by the versioning of other plug-ins.
A list of all needed plug ins for proper execution of Wintermute is
shown in the attached PDF.
I've already began laying out the foundation of wintermute-core. For
those interested, please reply to this mailing list for more
information.
Attachment:
Wintermute Plugin Infrastructure.png
Description: PNG image
Attachment:
signature.asc
Description: OpenPGP digital signature
| Thread Previous • Date Previous • Date Next • Thread Next |
