summaryrefslogtreecommitdiff
path: root/user
diff options
context:
space:
mode:
authorJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 18:48:50 +0200
committerJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 18:48:50 +0200
commit7d86797cb4decbcbf612651e0ad98d1088e9b91d (patch)
tree4a70b26656e323cf22b594ce1369b5da3fc50f0d /user
parentffc40b2f72fa1a44f492122d50678af0cfbf9b7f (diff)
gsoc2011 (java): spell-checking
Diffstat (limited to 'user')
-rw-r--r--user/jkoenig/gsoc2011_proposal.mdwn38
1 files changed, 19 insertions, 19 deletions
diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn
index b5932006..46ebf945 100644
--- a/user/jkoenig/gsoc2011_proposal.mdwn
+++ b/user/jkoenig/gsoc2011_proposal.mdwn
@@ -1,5 +1,5 @@
-# Java for Hurd (and vice vera)
+# Java for Hurd (and vice versa)
*[Draft] I'll finish this later today and send an email to bug-hurd when I'm done*
@@ -43,7 +43,7 @@ Shortly afterwards,
I rewrote the procfs translator
to fix some issues with memory leaks,
make it more reliable,
-and improve comptibility with Linux-based tools
+and improve compatibility with Linux-based tools
such as `procps` or `htop`.
Although I have not had as much time
@@ -55,7 +55,7 @@ on implementing POSIX threads signal semantics in glibc.
### Project-related skills and interests
-I have used Java mostly for university assignements.
+I have used Java mostly for university assignments.
This includes non-trivial projects
using threads and distributed programming frameworks
such as Java RMI or CORBA.
@@ -95,7 +95,7 @@ I don't expect I would require too much time from them.
My exams end on May 20 so I would be able to start coding
right at the beginning of the GSoC period.
-Next year's term would probably begin around september 15,
+Next year's term would probably begin around September 15,
so that would not be an issue either.
I expect I would work around 40 hours per week,
and my waking hours would be flexible.
@@ -242,7 +242,7 @@ Mach primitives and extending MIG to generate Java code from the interface
description files.
This approach would be initially more involved, and would introduces several
-issues related to overcoming the "impedence mismatch" between Java and Mach.
+issues related to overcoming the "impedance mismatch" between Java and Mach.
However, once an initial implementation is done it would be easier to maintain
in the long run and we would be able to provide Java bindings for a large
percentage of the Hurd’s interfaces.
@@ -271,9 +271,9 @@ package, which would contain at least the following classes:
* `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors
would act as an interface for the `mach_port_allocate()` system call.
- `MachPort` objects would also be instanciated from other parts of the JNI
+ `MachPort` objects would also be instantiated from other parts of the JNI
C code to represent port rights received through IPC. The `deallocate()`
- mehod would call `mach_port_deallocate()` and replace the encapsulated
+ method would call `mach_port_deallocate()` and replace the encapsulated
port name with `MACH_PORT_DEAD`. We would recommend that users call it
when a port is no longer used, but the finalizer would also deallocate the
port when the `MachPort` object is garbage collected.
@@ -286,11 +286,11 @@ package, which would contain at least the following classes:
constructor would allocate a `byte[]` member array of a given size.
Additional methods would be provided to fill in or query the information
in the message header and additional data items, including `MachPort` and
- `Buffer` objects which would be translated to the correponding port names
+ `Buffer` objects which would be translated to the corresponding port names
and out-of-line pointers.
A global map from port names to the corresponding `MachPort` object
would probably be needed to ensure that there is a one-to-one
- correspondance.
+ correspondence.
* `Syscall` would provide static JNI methods for performing system calls not
covered by the above classes, such as `mach_msg()` or
`mach_thread_self()`. These methods would accept or return `MachPort`,
@@ -308,7 +308,7 @@ examples:
`Message` object, and to read it back as a `MachPort` or `Buffer` object,
since this would allow unsafe access to arbitrary memory addresses and
mach port names.
- * Providing the `mach_task_self()` system call would also provide acces to
+ * Providing the `mach_task_self()` system call would also provide access to
arbitrary addresses and ports by using the `vm_*` family of RPC operations
with the returned `MachPort` object. This means that the relevant task
operations should be provided by the `Syscall` class instead.
@@ -394,7 +394,7 @@ but basically:
would implement this interface by doing RPC over a given MachPort object.
* A server class, corresponding to `*Server.c`, would be able to handle
incoming messages using a user-provided implementation of the interface.
- (Possibly, a skelton class providing methods which would raise
+ (Possibly, a skeleton class providing methods which would raise
`NotImplementedException`s would be provided as well.
Users would derive from this class and override the relevant methods.
This would allow them not to implement some operations,
@@ -409,7 +409,7 @@ primitives described in the previous section.
When possible, operations involving the transmission of send rights
of some kind would be expressed in terms of the MIG-generated interfaces
-intead of `MachPort` objects.
+instead of `MachPort` objects.
Upon reception of a send right,
a `FooUser` object would be created
and associated with the corresponding `MachPort` object.
@@ -424,10 +424,10 @@ instead of going through RPC mechanisms.
Some issues will still need to be solved regarding how MIG will convert
interface description files to Java interfaces. For instance:
- * `.defs` files are not explicitely associated with a type. For instance in
+ * `.defs` files are not explicitly associated with a type. For instance in
the example above, MIG would have to somehow infer that io_t corresponds
to `this` in the `Io` interface.
- * More generally, a correspondance between MIG and Java types would have
+ * More generally, a correspondence between MIG and Java types would have
to be determined. Ideally this would be automated and not hardcoded
too much.
* Initially, reply port parameters would be ignored. However they may be
@@ -484,7 +484,7 @@ library.
Once MIG can target Java code, and a libports equivalent is available,
creating new translators in Java would be greatly facilitated. However,
-we would probably want to introduce basic implementations of filesystem
+we would probably want to introduce basic implementations of file system
translators in the spirit of libtrivfs or libnetfs. They could take the form
of base classes implementing the relevant MIG-generated interfaces which
would then be derived by users,
@@ -497,7 +497,7 @@ to design and implement similar solutions for Java.
### Deliverables
- * A hurd-java package would contain the Java code developped
+ * A hurd-java package would contain the Java code developed
in the context of this project.
* The Java code would be documented using javadoc
and a tutorial for writing translators would be written as well.
@@ -513,7 +513,7 @@ Debian GNU/Hurd.
This package would be separate from both Hurd and Mach,
so as not to impose unreasonable build dependencies on them.
-I expect I would be able to act as its maintainer in the forseeable future,
+I expect I would be able to act as its maintainer in the foreseeable future,
either as an individual or as a part of the Hurd team.
Hopefully,
my code would be claimed by the Hurd project as their own,
@@ -524,7 +524,7 @@ could be integrated upstream.
Since by design,
the Java code would use only a small number of stable interfaces,
it would not be subject to excessive amounts of bitrot.
-Consequenty,
+Consequently,
maintenance would primarily consist in
fixing bugs as they are reported,
and adding new features as they are requested.
@@ -618,7 +618,7 @@ of some Java applications (though probably not by much),
and would otherwise be a good project
for someone trying to get acquainted with Hurd.
-Overall, I beleive this project would be fun, interesting and useful.
+Overall, I believe this project would be fun, interesting and useful.
I hope that you will share this sentiment
and give me the opportunity to spend another summer working on Hurd.