gsoc2011 (java): spell-checking

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.