mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-19 03:00:25 +02:00
bye bye
This commit is contained in:
Thien-Thi Nguyen
parent
3c5c187e69
commit
4ad7842321
9 changed files with 0 additions and 644 deletions
|
|
@ -1,24 +0,0 @@
|
||||||
2000-05-30 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* tasks.text: Use outline-mode. Added section for tasks in need
|
|
||||||
of attention.
|
|
||||||
|
|
||||||
2000-05-29 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* tasks.text: New file.
|
|
||||||
|
|
||||||
2000-05-25 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* README: New file.
|
|
||||||
|
|
||||||
* build/snarf-macros.text: New file.
|
|
||||||
|
|
||||||
2000-05-20 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* policy/goals.text, policy/principles.text, policy/plans.text:
|
|
||||||
New files.
|
|
||||||
|
|
||||||
2000-03-21 Mikael Djurfeldt <mdj@thalamus.nada.kth.se>
|
|
||||||
|
|
||||||
* policy/names.text: New file.
|
|
||||||
|
|
||||||
|
|
@ -1,9 +0,0 @@
|
||||||
Directories:
|
|
||||||
|
|
||||||
policy Guile policy documents
|
|
||||||
|
|
||||||
build information related to the build/installation process
|
|
||||||
|
|
||||||
Files:
|
|
||||||
|
|
||||||
tasks.text Guile project task list
|
|
||||||
|
|
@ -1,82 +0,0 @@
|
||||||
This file states the goals of Guile.
|
|
||||||
|
|
||||||
* Goals of Guile
|
|
||||||
|
|
||||||
Guile is many things to many people. It has multiple ways to approach
|
|
||||||
it: as a C library that provides an extension language, as a
|
|
||||||
programming language in its own right, as a interface to the operating
|
|
||||||
system, as an interactive shell, or as a platform that integrates many
|
|
||||||
independent subsystems.
|
|
||||||
|
|
||||||
These different roles have a lot in common, but there are also some
|
|
||||||
opposing forces that need to be balanced.
|
|
||||||
|
|
||||||
Not everything of what is outlined below has been realized yet. The
|
|
||||||
things that are missing will receive high priority from the
|
|
||||||
maintainers of Guile. One thing that is not mentioned below because
|
|
||||||
it goes without saying is documentation. It is of course a goal of
|
|
||||||
Guile to have high quality documentation.
|
|
||||||
|
|
||||||
More information about the current status of Guile and planned changed
|
|
||||||
can be found in the file "plans.text".
|
|
||||||
|
|
||||||
** Guile as an extension language library
|
|
||||||
|
|
||||||
Guile's primary aim is to provide a good extension language which is
|
|
||||||
easy to add to an application written in C on a UNIX machine. This
|
|
||||||
means that it must export the features of a higher level language in a
|
|
||||||
way that makes it easy not to break them from C code.
|
|
||||||
|
|
||||||
For example, one important feature of Guile is automatic garbage
|
|
||||||
collection. The C interface to the garbage collector makes it easy to
|
|
||||||
use its services for the data structures of the application itself.
|
|
||||||
|
|
||||||
** Guile as a programming language
|
|
||||||
|
|
||||||
It is an aim to support easy programming using Guile. This includes
|
|
||||||
providing the powerful features of the programming language Scheme,
|
|
||||||
like garbage collection, dynamic types, hygienic macros and higher
|
|
||||||
order functions.
|
|
||||||
|
|
||||||
This also includes things that go beyond standard Scheme, like a
|
|
||||||
module system to manage multiple name spaces, a system for object
|
|
||||||
oriented programming, support for comfortable multi-threading, and
|
|
||||||
internationalization features like Unicode support.
|
|
||||||
|
|
||||||
To make it useful, Guile offers good performance.
|
|
||||||
|
|
||||||
** Guile as an interface to the operating system
|
|
||||||
|
|
||||||
Guile supports most of the POSIX system calls. Most of Scsh is
|
|
||||||
available to Guile users and Guile programs. Beyond POSIX, Guile also
|
|
||||||
makes available important system libraries like the graphical toolkit
|
|
||||||
Gtk+.
|
|
||||||
|
|
||||||
** Guile as an interactive shell
|
|
||||||
|
|
||||||
Guile provides a command line interface with readline support. The
|
|
||||||
interactive features of the programming language allow you to
|
|
||||||
incrementally alter a running system. A integrated debugger allows
|
|
||||||
you to analyze such a running system in great detail.
|
|
||||||
|
|
||||||
Guile provides online documentation for most of its features.
|
|
||||||
|
|
||||||
Guile can also be controlled from Emacs. This allows you to update
|
|
||||||
the definition of a function or some other object in a Guile process
|
|
||||||
with the touch of a few keys. You have access to the documentation in
|
|
||||||
a context sensitive way. It also integrates the debugger nicely into
|
|
||||||
your editing environment.
|
|
||||||
|
|
||||||
** Guile as an integration platform
|
|
||||||
|
|
||||||
With all the features describes above, Guile allows the implementation
|
|
||||||
of well behaved modules. When most of an application is implemented
|
|
||||||
as modules with generality and re-usability in mind, Guile will be the
|
|
||||||
platform where the integration and reusing will take place.
|
|
||||||
|
|
||||||
Thus, Guile makes it easy to factor your application into well
|
|
||||||
separated modules and then finish it off by combining them with a thin
|
|
||||||
layer of Scheme code.
|
|
||||||
|
|
||||||
Guile has support for writing modules in C or other compiled
|
|
||||||
languages.
|
|
||||||
|
|
@ -1,127 +0,0 @@
|
||||||
[This is currently a collection of information in an unedited state.
|
|
||||||
Someone will change this soon.]
|
|
||||||
|
|
||||||
The C names for Scheme primitives *always* obey a fixed name
|
|
||||||
translation scheme:
|
|
||||||
|
|
||||||
scm_XXX where XXX is translated from the Scheme name, except that
|
|
||||||
|
|
||||||
- becomes _
|
|
||||||
! becomes _x
|
|
||||||
? becomes _p
|
|
||||||
% becomes sys_
|
|
||||||
|
|
||||||
If there's a C variant of something provided at the Scheme level (like
|
|
||||||
the current scm_internal_dynamic_wind), it has the prefix scm_c_
|
|
||||||
instead of scm_.
|
|
||||||
|
|
||||||
A function named scm_c_FOO serves the same purpose as the function
|
|
||||||
named scm_FOO, except that its interface is tailored for use from C,
|
|
||||||
while scm_FOO is tailored for use from Scheme, and is probably
|
|
||||||
exported as a Scheme primitive.
|
|
||||||
|
|
||||||
For example, scm_FOO might expect Scheme procedures as arguments,
|
|
||||||
while scm_c_FOO might take C function pointers and a passthrough
|
|
||||||
value.
|
|
||||||
|
|
||||||
|
|
||||||
If there's a C function with global scope which is only intended to be
|
|
||||||
used internally in libguile, it has the prefix scm_i_.
|
|
||||||
|
|
||||||
String literals with global scope has the prefix scm_s_. (Greg
|
|
||||||
introduced the prefix s_scm_ but this has to change to scm_s_ since
|
|
||||||
s_scm_ trespasses the user's namespace.)
|
|
||||||
|
|
||||||
Not correct: Those names have module-local scope and does not trespass
|
|
||||||
user name space.
|
|
||||||
|
|
||||||
Keywords with global scope has the prefix scm_k_.
|
|
||||||
|
|
||||||
Symbols with global scope has the prefix scm_sym_.
|
|
||||||
|
|
||||||
Variable bindings with global scope has the prefix scm_var_.
|
|
||||||
|
|
||||||
Names, in general, have an internal left-to-right order of increasing
|
|
||||||
specificity: scm_ is least specific. It is often followed by some
|
|
||||||
type, like `stack', and, finally, the operation. Example:
|
|
||||||
scm_stack_length.
|
|
||||||
|
|
||||||
There are exceptions, though:
|
|
||||||
|
|
||||||
* If a name is already established at the Scheme level, this defines
|
|
||||||
the C name through the translation scheme.
|
|
||||||
|
|
||||||
* According to the rule, we should have `SCM_SMOB_DATA_SET', but we
|
|
||||||
instead have `SCM_SET_SMOB_DATA'. Generally, `set' should be placed
|
|
||||||
as far left as possible:
|
|
||||||
|
|
||||||
`port-filename' scm_port_filename
|
|
||||||
`set-port-filename!' scm_set_port_filename_x
|
|
||||||
|
|
||||||
SCM_SMOB_DATA
|
|
||||||
SCM_SET_SMOB_DATA
|
|
||||||
|
|
||||||
* Guile has a lot of history with lots of different strange names.
|
|
||||||
Perhaps a major name overhaul can be done at the same time as we go
|
|
||||||
through Guile's interfaces to checks soundness and theoretical
|
|
||||||
properties such as type safety. We *should* be a bit careful with
|
|
||||||
name changes in order not to break existing application code.
|
|
||||||
|
|
||||||
> Further, I'd love it if macros to create scheme values from C values would
|
|
||||||
> be named SCM_MAKE_... more consitently. Currently, we have SCM_MAKICHAR
|
|
||||||
> (OK, this one's been made deprecated), SCM_MAKINUM and others.
|
|
||||||
|
|
||||||
I agree.
|
|
||||||
|
|
||||||
> Also, some macros are used for symbols or keywords. The best solution
|
|
||||||
> would be to use a similar naming scheme for these also.
|
|
||||||
>
|
|
||||||
> It's good to talk about improving guile's API. A clean, consistent and
|
|
||||||
> beautiful api is, in my belief, important for guile's attractivity, and
|
|
||||||
> makes learning it easier.
|
|
||||||
|
|
||||||
Yes!
|
|
||||||
|
|
||||||
There are still some open points:
|
|
||||||
|
|
||||||
scm_c_XXX :
|
|
||||||
Only used for C-level variants of a scm_XXX schene primitive, or
|
|
||||||
rather to be used for everything that is not a scheme primitive?
|
|
||||||
|
|
||||||
scm_i_XXX :
|
|
||||||
Only for internal _functions_ or rather for everything that is
|
|
||||||
internal? For example, scm_sym_ is for symbols that may be used by
|
|
||||||
users, while scm_i_sym_ is used for guile internally? Otherwise we
|
|
||||||
can't distinguish between C variables holding symbols that are part of
|
|
||||||
the official API and internally used C variables holding symbols.
|
|
||||||
|
|
||||||
what about boolean variables/constants? scm_bool_? This would fit nicely
|
|
||||||
with the current macro names SCM_BOOL_T and SCM_BOOL_F.
|
|
||||||
|
|
||||||
what about number variables/constants? scm_num_? There is at least a
|
|
||||||
SCM_MAKINUM(0) somewhere...
|
|
||||||
|
|
||||||
scm_s_, scm_k_, scm_sym_, scm_var_:
|
|
||||||
What about macro variants of these? At least, some symbols and
|
|
||||||
constants are represented as macros.
|
|
||||||
|
|
||||||
Macros in general:
|
|
||||||
Should internally used macros be called SCM_I_xxx, thus following the
|
|
||||||
above scheme?
|
|
||||||
|
|
||||||
How do scheme-level names translate if there are macros that do the
|
|
||||||
same thing? set-car! --> SCM_SETCAR, thus, the '!' is dropped and the
|
|
||||||
intermediate '-' is dropped. However, this is not done
|
|
||||||
consistently: sometimes intermediate '-' are _not_ dropped.
|
|
||||||
|
|
||||||
Currently it seem that:
|
|
||||||
|
|
||||||
- becomes sometimes _ and sometimes nothing
|
|
||||||
! becomes nothing
|
|
||||||
? becomes P for single-word xxx, _P otherwise
|
|
||||||
% becomes I don't know what.
|
|
||||||
|
|
||||||
|
|
||||||
I would prefer if both worlds (functions/variables and macros) were using
|
|
||||||
similar schemes as far as possible. (I even dislike the _P/P
|
|
||||||
distinction, but I know that I am strange :-)
|
|
||||||
|
|
@ -1,278 +0,0 @@
|
||||||
This file describes the current status and future plans for Guile development.
|
|
||||||
|
|
||||||
* Status
|
|
||||||
|
|
||||||
To give you an idea how far we are from the things described above,
|
|
||||||
here is the status of some topics. Guile used to suck, but it doesn't
|
|
||||||
any more.
|
|
||||||
|
|
||||||
** Documentation
|
|
||||||
|
|
||||||
XXX - Losta stuff, and talk also about updating the web page.
|
|
||||||
|
|
||||||
** Object oriented programming
|
|
||||||
|
|
||||||
Guile's object system is GOOPS. XXX - Some notes about
|
|
||||||
characteristics and motivations.
|
|
||||||
|
|
||||||
** Multithreading
|
|
||||||
|
|
||||||
At the moment, Guile supports co-operative threading on several
|
|
||||||
platforms. We do *not* support true kernel threads at present, not
|
|
||||||
because we don't think that would be way cool, but because it's
|
|
||||||
really, really hard. We're taking continually taking steps towards
|
|
||||||
that goal, however.
|
|
||||||
|
|
||||||
Current status is that necessary basic changes to the garbage
|
|
||||||
collector and the signal handling has been done. (Few are aware of
|
|
||||||
it, but the SCM_DEFER_INTS/SCM_ALLOW_INTS macros no longer have any
|
|
||||||
effect!)
|
|
||||||
|
|
||||||
The major remaining work is to protect common resources using mutecis.
|
|
||||||
|
|
||||||
*** Using Guile's COOP threads in a POSIX threaded application
|
|
||||||
|
|
||||||
A recent change has made it possible to mix use of Guile's COOP
|
|
||||||
threads and POSIX threads in a single application. This is useful,
|
|
||||||
since some GNOME libraries links with pthreads by default. (Guile
|
|
||||||
still has to run in a single POSIX thread, and the two thread systems
|
|
||||||
needs to use independent sets of thread synchronization mechanisms,
|
|
||||||
however.)
|
|
||||||
|
|
||||||
** Graphical toolkit
|
|
||||||
|
|
||||||
You can access Gtk+ from Guile by using the (separate) guile-gtk
|
|
||||||
package. The basic machinery of guile-gtk is mostly done but
|
|
||||||
individual features of Gtk+ are missing. Adding these features is
|
|
||||||
mostly the job of taking a look whether they are safe to export in
|
|
||||||
unmodified form and when that is the case, writing a couple of easy
|
|
||||||
lines of descriptions for the feature. This is mostly busy work.
|
|
||||||
|
|
||||||
XXX - guile-tcltk?
|
|
||||||
|
|
||||||
* Near Future
|
|
||||||
|
|
||||||
What is planned for the near future.
|
|
||||||
|
|
||||||
** Breakpoints and single-stepping in the debugger
|
|
||||||
|
|
||||||
Guile now has a debugger (try `(debug)'). We are planning to
|
|
||||||
implement breakpoints and single-stepping, and then announce the
|
|
||||||
debugger in README file and documentation.
|
|
||||||
|
|
||||||
** A new module system
|
|
||||||
|
|
||||||
Integration of Jost Boekemeiers environment implementation. Greg
|
|
||||||
Badros has promised to try to integrate them.
|
|
||||||
|
|
||||||
On top of that, a new module system will be implemented, but:
|
|
||||||
1) We're not settled yet,
|
|
||||||
2) we're really trying to settle it, and
|
|
||||||
3) we're discovering why the rest of the Scheme scene isn't
|
|
||||||
settled on this issue either.
|
|
||||||
|
|
||||||
There will be a C API to the new module system.
|
|
||||||
|
|
||||||
** Factorization of Guile into function libraries
|
|
||||||
|
|
||||||
Although Guile is meant to support composing a system from modules
|
|
||||||
well, it does not make use of this principle itself. The core is
|
|
||||||
quite monolithic and includes a lot of things that could be separated
|
|
||||||
out.
|
|
||||||
|
|
||||||
We will be moving such things as networking, posix and regular
|
|
||||||
expression support to separate modules instead of having them all in
|
|
||||||
the root namespace.
|
|
||||||
|
|
||||||
** Faster startup
|
|
||||||
|
|
||||||
We will make Guile start up quicker. Guile's current slow startup is
|
|
||||||
primarily due to 1. inefficient code in a time-critical place in the
|
|
||||||
current module system, and, 2. that too much code is loaded at
|
|
||||||
startup.
|
|
||||||
|
|
||||||
** Translators
|
|
||||||
|
|
||||||
XXX - ???
|
|
||||||
|
|
||||||
*** C-like syntax for Scheme
|
|
||||||
*** elisp
|
|
||||||
*** tcl
|
|
||||||
*** python
|
|
||||||
|
|
||||||
* The Guile wishlist
|
|
||||||
|
|
||||||
** Revision and stabilization of interfaces
|
|
||||||
|
|
||||||
Along with the updating the documentation, we should clean up the
|
|
||||||
interfaces of Guile.
|
|
||||||
|
|
||||||
It should be well defined which existing Scheme procedures and C
|
|
||||||
functions and macros are supported as part of the "Guile language" and
|
|
||||||
which are temporary procedures used in the implementation of Guile or
|
|
||||||
historical remnants.
|
|
||||||
|
|
||||||
** Full R5RS compliance
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** SRFIs
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Reorganization of the numeric code
|
|
||||||
|
|
||||||
Numeric tower
|
|
||||||
|
|
||||||
3. Introduce a subclass of <generic> called <arithmetic-generic>.
|
|
||||||
|
|
||||||
Such objects contain 7 pointers to C functions handling the argument
|
|
||||||
combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM),
|
|
||||||
(INUM, REAL) and (REAL, REAL).
|
|
||||||
|
|
||||||
When an <arithmetic-generic> is applied, it first uses simple
|
|
||||||
if-statements to dispatch onto one of these "primitive methods".
|
|
||||||
If that fails, it behaves as an ordinary generic, i.e., it does
|
|
||||||
type dispatch.
|
|
||||||
|
|
||||||
4. Turn all standard Guile arithmetic, and comparison operators into
|
|
||||||
<arithmetic-generic>s and break up numbers.c into independent
|
|
||||||
modules.
|
|
||||||
|
|
||||||
After this, we can easily add new types to the numeric tower. The new
|
|
||||||
types will be handled a little bit slower than INUMs and REALs, but I
|
|
||||||
think it will be fast enough.
|
|
||||||
|
|
||||||
Some fundamental changes have already been done that make floating
|
|
||||||
point calculations more efficient.
|
|
||||||
|
|
||||||
** Low-level support for hygienic macros
|
|
||||||
|
|
||||||
Instead of a well integrated support for hygieneic macros, Guile
|
|
||||||
provides three redundant ways of defining unhygienic macros:
|
|
||||||
`procedure->macro', `defmacro' (with `defmacro-public'), and,
|
|
||||||
`define-macro' (which lacks a "public" version). There is a
|
|
||||||
syntax-case macro module (hygienic), but that macro system is written
|
|
||||||
in Scheme and makes loading time extend even further beyond it's
|
|
||||||
current unacceptable level.
|
|
||||||
|
|
||||||
Guile macros are not compatible with Guile's module system. If you
|
|
||||||
export a macro, you need to explicitly export all bindings which it
|
|
||||||
uses. This needs to be fixed.
|
|
||||||
|
|
||||||
It might be benefitial to separate memoization and execution to better
|
|
||||||
support macro expansion and compile time optimizations. The result of
|
|
||||||
the macro expansion and memoization pass could be permanentaly stored
|
|
||||||
on disk to reduce the load time of large programs. This would also
|
|
||||||
make the integration of a real compiler easier. See next point.
|
|
||||||
|
|
||||||
** Compiler
|
|
||||||
|
|
||||||
Hobbit doesn't support all of the Guile language, produces inefficient
|
|
||||||
code, and is a very unstructured program which can't be developed
|
|
||||||
further.
|
|
||||||
|
|
||||||
It iss very important that the compiler and interpreter agree as much
|
|
||||||
as possible on the language they're implementing. Users should be
|
|
||||||
able to write code, run it in the interpreter, and then just switch
|
|
||||||
over to the compiler and have everything work just as it did before.
|
|
||||||
|
|
||||||
To make this possible, the compiler and interpreter should share as
|
|
||||||
much code as possible. For example, the module system should be
|
|
||||||
designed to support both. They should use the same parser and the
|
|
||||||
same macro expander.
|
|
||||||
|
|
||||||
** CORBA
|
|
||||||
|
|
||||||
The way many of the major applications in the GNOME/Gtk+ world are
|
|
||||||
moving is this:
|
|
||||||
|
|
||||||
Core application code is written in C or some other similarly
|
|
||||||
low-level langauge.
|
|
||||||
|
|
||||||
However, internally it consists of Bonobo components.
|
|
||||||
|
|
||||||
Bonobo components should in theory be accessible from any language
|
|
||||||
(someone really ought to write ORBit-guile) and can be recomposed in
|
|
||||||
ways other how the application originally intended.
|
|
||||||
|
|
||||||
Thus, Gimp and Gnumeric will eventually in effect provide pieces that
|
|
||||||
can be used from Guile (and other langauges) and recombined; however,
|
|
||||||
these components will be written to the Bonobo API, not the Guile API,
|
|
||||||
and will require a CORBA mapping for the target language to work.
|
|
||||||
|
|
||||||
There are advantages and disadvantages to doing things this way as
|
|
||||||
compared to writing Guile modules; but in either case we must be
|
|
||||||
prepared to play in this brave new world of components by ensuring
|
|
||||||
Guile has the proper tools available, because I don't think we are
|
|
||||||
going to convince the GNOME people that Guile modules provide all they
|
|
||||||
want from a component model.
|
|
||||||
|
|
||||||
** POSIX threads support
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Faster GC
|
|
||||||
|
|
||||||
We hope so. If someone came up with a running GC that's faster than
|
|
||||||
what we've got now, that would be extremely interesting. But this
|
|
||||||
isn't a primary focus.
|
|
||||||
|
|
||||||
** Test suite
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Internationalization/multilingualization
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Integration of Guile into GNU programs
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
*** Emacs
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
*** The Gimp
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Soft typing
|
|
||||||
|
|
||||||
XXX - combine with compiler section?
|
|
||||||
|
|
||||||
** Importing changes from SCM
|
|
||||||
|
|
||||||
XXX
|
|
||||||
|
|
||||||
** Guile module repository
|
|
||||||
|
|
||||||
One is to provide a better public face for Guile, and encourage people
|
|
||||||
to contribute useful extensions. This can be achieved by providing a
|
|
||||||
repository and managed namespace along the lines of CPAN.
|
|
||||||
|
|
||||||
** More frequent releases
|
|
||||||
|
|
||||||
We will try to make Guile releases more frequently.
|
|
||||||
|
|
||||||
------------------- XXX - add the following to HACKING?
|
|
||||||
|
|
||||||
** The CVS repository
|
|
||||||
|
|
||||||
*** The current CVS version of Guile should always compile
|
|
||||||
|
|
||||||
The current CVS version of Guile should always compile and not contain
|
|
||||||
major bugs.
|
|
||||||
|
|
||||||
*** Applying patches
|
|
||||||
|
|
||||||
A Guile developer should always fully understand the code in a patch
|
|
||||||
which he applies, and is responsible for the quality of the applied
|
|
||||||
patch.
|
|
||||||
|
|
||||||
*** Experimental code
|
|
||||||
|
|
||||||
Experimental code should be kept in the local working copy or
|
|
||||||
committed onto a branch. The only exception is when some kind of
|
|
||||||
feedback is needed from other developers or users.
|
|
||||||
124
devel/tasks.text
124
devel/tasks.text
|
|
@ -1,124 +0,0 @@
|
||||||
* People
|
|
||||||
|
|
||||||
neil Neil Jerram <neil@ossau.uklinux.net>
|
|
||||||
gjb Greg J. Badros <gjb@cs.washington.edu>
|
|
||||||
thi thi <ttn@revel.glug.org>
|
|
||||||
peter Peter C. Norton <spacey@lenin.nu>
|
|
||||||
mvo Marius Vollmer <mvo@zagadka.ping.de>
|
|
||||||
mdj Mikael Djurfeldt <djurfeldt@nada.kth.se>
|
|
||||||
livshin Michael Livshin <mlivshin@bigfoot.com>
|
|
||||||
gregh Greg Harvey <Greg.Harvey@thezone.net>
|
|
||||||
niibe NIIBE Yutaka <gniibe@chroot.org>
|
|
||||||
dirk Dirk Herrmann <dirk@ida.ing.tu-bs.de>
|
|
||||||
rlb Rob Browning <rlb@cs.utexas.edu>
|
|
||||||
ryanw Ryan Weaver <ryanw@infohwy.com>
|
|
||||||
|
|
||||||
* Assigned core tasks
|
|
||||||
|
|
||||||
(? = has shown interest, but has not yet taken on the task)
|
|
||||||
|
|
||||||
** reference manual
|
|
||||||
|
|
||||||
neil
|
|
||||||
|
|
||||||
** docstrings
|
|
||||||
|
|
||||||
gjb
|
|
||||||
|
|
||||||
** Guile FAQ
|
|
||||||
|
|
||||||
thi
|
|
||||||
|
|
||||||
** Guile WWW pages at GNU
|
|
||||||
|
|
||||||
peter
|
|
||||||
|
|
||||||
** Guile project list
|
|
||||||
|
|
||||||
thi
|
|
||||||
|
|
||||||
** Guile Debian package maintainer
|
|
||||||
|
|
||||||
rlb
|
|
||||||
|
|
||||||
** Guile RPM package manager
|
|
||||||
|
|
||||||
ryanw
|
|
||||||
|
|
||||||
** integration of Jost's environments
|
|
||||||
|
|
||||||
gjb
|
|
||||||
|
|
||||||
** generational garbage collection
|
|
||||||
|
|
||||||
gregh
|
|
||||||
livshin
|
|
||||||
|
|
||||||
** POSIX thread support
|
|
||||||
|
|
||||||
niibe
|
|
||||||
|
|
||||||
*** factorizing thread support out of libguile
|
|
||||||
|
|
||||||
niibe
|
|
||||||
dirk
|
|
||||||
|
|
||||||
*** Protecting common resources using mutecis from the new interface.
|
|
||||||
|
|
||||||
maciej?
|
|
||||||
|
|
||||||
*** Removing the dynamic roots
|
|
||||||
|
|
||||||
*** Revise the fluid implementation
|
|
||||||
|
|
||||||
Trying to use the thread library's support for thread local data
|
|
||||||
(get/setspecific).
|
|
||||||
|
|
||||||
*** Implementing the GC thread synchronization (all threads: go to sleep!)
|
|
||||||
|
|
||||||
One suitable synchronization point is probably SCM_TICK.
|
|
||||||
|
|
||||||
Note also that threads which are in I/O or timeout should be regarded
|
|
||||||
as stopped and that we need synchronization points *after* each I/O or
|
|
||||||
timeout, so that they really stop afterward if Guile is still in GC.
|
|
||||||
|
|
||||||
*** Implementing the libguileposix threads glue library
|
|
||||||
|
|
||||||
This corresponds to the libguilecoop library implemented during the
|
|
||||||
thread factorization.
|
|
||||||
|
|
||||||
** GOOPS
|
|
||||||
|
|
||||||
*** integration into libguile
|
|
||||||
|
|
||||||
mdj
|
|
||||||
|
|
||||||
*** developing better representation for GOOPS objects
|
|
||||||
|
|
||||||
livshin
|
|
||||||
|
|
||||||
*** rewrite method cache management in C
|
|
||||||
|
|
||||||
thi
|
|
||||||
|
|
||||||
*** rewrite core macros (define-class et al) in C
|
|
||||||
|
|
||||||
thi
|
|
||||||
|
|
||||||
*** GOOPS C API
|
|
||||||
|
|
||||||
mvo
|
|
||||||
dirk
|
|
||||||
|
|
||||||
* Core tasks in need of attention
|
|
||||||
|
|
||||||
** GOOPS
|
|
||||||
|
|
||||||
*** Orbit CORBA interface
|
|
||||||
|
|
||||||
Talk to mdj
|
|
||||||
|
|
||||||
|
|
||||||
Local Variables:
|
|
||||||
mode: outline
|
|
||||||
End:
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue