ARGON
Check-in [dd84df30e7]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:XENON added
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:dd84df30e7d4e30c026a5d58a67c281b4ba3e26c
User & Date: alaric 2013-07-16 20:47:52
Context
2015-07-08
08:51
"Phiosphy" type (thanks to Oskar Schirmer for spotting it!) check-in: 536f2beab9 user: alaric tags: trunk
2013-07-16
20:47
XENON added check-in: dd84df30e7 user: alaric tags: trunk
2013-06-27
15:42
Thoughts on content-addressible storage check-in: 9ed1933bce user: alaric tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to README.wiki.

342
343
344
345
346
347
348



















349
350
351
352
353
354
355
<dt>WOLFRAM</dt> <dd>We now have a simple single-node ARGON system, so
userland developments can commence. However, we can now implement
WOLFRAM and start patching it into all the unused hooks left for it in
the rest of the system, in order to enable full clustered
operation.</dd>

</dl>




















<h1>TODOs and ideas</h1>

<h2>This Site</h2>

  *  intro pages to do: CARBON, AURUM, FLUORINE, IODINE, NEON








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
<dt>WOLFRAM</dt> <dd>We now have a simple single-node ARGON system, so
userland developments can commence. However, we can now implement
WOLFRAM and start patching it into all the unused hooks left for it in
the rest of the system, in order to enable full clustered
operation.</dd>

</dl>

<h2>[./intro/xenon.wiki|XENON]</h2>

However, implementing a full ARGON system is quite a lot of work. A
full HYDROGEN implementation (even with poor performance) is probably
a man-year or more, and everything else builds upon that.

As a testbed for the concepts behind ARGON, and as a way to make use
of them in the non-ARGON world of existing software development, and
(in the long run) as a way for non-ARGON software to interact with
ARGON (sort of the inverse of FLUORINE), I propose XENON:
implementations of parts of ARGON in traditional programming
languages.

As my main programming language of choice is
[http://www.call-cc.org/|Chicken Scheme], I will probably do most of
the development in that; but network and data interoperability
components such as IRON and MERCURY should probably also be
implemented in other languages.

<h1>TODOs and ideas</h1>

<h2>This Site</h2>

  *  intro pages to do: CARBON, AURUM, FLUORINE, IODINE, NEON

Changes to intro/helium.wiki.

1
2
3
4
5
6

7
8
9
10
11
12
13
HELIUM is the thread scheduler and memory manager; the core mediator
of access to the fundamental shared resources of processor time and
memory space. It will use the processor state control and signal
handling interfaces in HYDROGEN to schedule threads, and to allocate
per-thread heaps from a global heap. It depends only on HYDROGEN
itself, so must be written as low-level HYDROGEN source code.


ARGON has a somewhat different execution model to UNIX. Under UNIX, or
indeed anything even vaguely like POSIX, you tend to have long-lived
processes which spend much of their time blocked waiting for user
input or incoming network requests. All consuming memory, and all
requiring starting at boot time and stopping at exit time, and all
requiring monitoring and restarting should they fail.



|
|
|
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
HELIUM is the thread scheduler and memory manager; the core mediator
of access to the fundamental shared resources of processor time and
memory space. It will use the processor state control and signal
handling interfaces in [./hydrogen.wiki|HYDROGEN] to schedule threads,
and to allocate per-thread heaps from a global heap. It depends only
on HYDROGEN itself, so must be written as low-level HYDROGEN source
code.

ARGON has a somewhat different execution model to UNIX. Under UNIX, or
indeed anything even vaguely like POSIX, you tend to have long-lived
processes which spend much of their time blocked waiting for user
input or incoming network requests. All consuming memory, and all
requiring starting at boot time and stopping at exit time, and all
requiring monitoring and restarting should they fail.

Added intro/xenon.wiki.









































































































































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
XENON is not a part of the ARGON abstract specification - it's not
even a component of an implementation of ARGON. Instead, it is a suite
of libaries written in other programming languages, either
implementing useful ARGON concepts that can exist in isolation, or to
interoperate with actual ARGON nodes.

Most of them will be in [http://www.call-cc.org/|Chicken Scheme] as
that's my programming language of choice, but implementations in other
languages will be useful, too - particularly for IRON and MERCURY.

The components I propose are:

<dl>

<dt>The system console abstraction from
[./hydrogen.wiki|HYDROGEN]</dt>
<dd>Long-running daemon software such as network services tend to
require logging, monitoring, and management of some kind, and most end
up implementing their own as an after-thought. The HYDROGEN console
interface is designed to provide a high-level interface to this, and
could be implemented as a library providing the abstract interface,
passing output on to a list of handlers. Prompts for input will be
broadcast to the handlers, and the first handler to "claim" the
request will cause it to be cancelled on all the others; and
asynchronous command inputs from any of them will be merged together
to feed to the application.

The default handlers are a console-based one (using ANSI escapes) and
a Web interface, as well as an sexpr-over-tcp-socket protocol that can
be used to run handlers in a separate process. Finally, a handler that
logs output to files configurably, and can run arbitrary shell
commands (also configured in the same file) upon system status
transitions, completes the set.</dd>

<dt>[./iron.wiki|IRON]</dt>
<dd>An implementation of IRON for Scheme would be most useful. The
representation used in-memory should use existing Scheme types such as
vectors and lists where possible. IRON symbols are a little trickier;
Scheme symbols should probably be mapped to the default namespace, and
namespaced IRON symbols mapped to Scheme record types, as should IRON
records. The implementation will consist of tools to manage the
in-memory representation of such IRON types with no direct Scheme
equivalent, and writer/reader implementations for the textual and
binary encodings of IRON. Implementations of IRON in C will be
somewhat trickier, due to the requirement for an implementation of the
full type system, ideally including garbage collection.</dd>

<dt>[./iridium.wiki|IRIDIUM] and [./mercury|MERCURY]</dt>
<dd>An implementation of the IRIDIUM protocol (using the IRON binary
reader/writer) will provide a useful toolkit for network protocol
construction, especially when used as the basis for a full MERCURY
implementation. Of course, what counts as a cluster and what counts as
an entity will be up to the applications that use it; users of the
library will need to provide cluster cryptographic keys and a
versioned list of nodes, and will be able to use arbitrary values of
their own choosing as entity IDs.</dd>

<dt>[./chrome.wiki|CHROME]</dt>
<dd>Given an IRON implementation, a basic CHROME interpreter can be
written. Indeed, a CHROME to HYDROGEN compiler written in CHROME could
be run on the interpreter in order to bootstrap CHROME onto
HYDROGEN. But the interpreter could be used to experiment with the
practicalities of the CHROME language, and rapidly iterate the design;
a hand-coded interpreter written in HYDROGEN will probably be harder
to tinker with.</dd>

<dt>The task scheduling from [./helium.wiki|HELIUM] and
[./lithium.wiki|LITHIUM]</dt>
<dd>Parts of these two can be used to build a thread/job pooling
mechanism in the spirit of Apple's
[https://en.wikipedia.org/wiki/Grand_Central_Dispatch|Grand Central
Dispatch]; a managed for queues of tasks (implemented as Scheme
closures), with metadata, and a set of threads to run them.</dd>

<dt>[./carbon.wiki|CARBON]</dt>
<dd>Using an IRON implementation, CARBON knowledge bases (both in
memory and accessed via MERCURY) and inference could be implemented in
Scheme. Again, this might be useful in its own right (especially
coupled with a TUNGSTEN-esque persistent store, perhaps built on
SQLite), as well as providing a prototyping environment for CARBON
itself.</dd>


</dl>