From 4fe33e23ab8023b56aaf7986e3edd6e80a21fb62 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Jan 2011 22:30:41 +0100 Subject: news/2011-01: New. --- news/2011-01.mdwn | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 news/2011-01.mdwn diff --git a/news/2011-01.mdwn b/news/2011-01.mdwn new file mode 100644 index 00000000..62a77e74 --- /dev/null +++ b/news/2011-01.mdwn @@ -0,0 +1,67 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + + +A month of the Hurd: *TODO* / *TODO* / *TODO*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + + + + +Watch these places for news: + + * GNU + + * + + * + + * + + * + + * + + * + + Also Git log. + + * () + + * () + + Better use the Git log. + + * + + * Debian + + * + + * + + * Arch Hurd + + * + + * + + * () + +"""]] -- cgit v1.2.3 From 410952b69384774db595369e4f1ad55727688d5f Mon Sep 17 00:00:00 2001 From: "root@hurd.gnu" Date: Thu, 24 Mar 2011 13:17:26 +0000 Subject: added bug-hurd entries --- news/2011-01.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/news/2011-01.mdwn b/news/2011-01.mdwn index 62a77e74..3b27a545 100644 --- a/news/2011-01.mdwn +++ b/news/2011-01.mdwn @@ -23,6 +23,16 @@ else=" + + +* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) +* Samuel Thibault: Bootable USB installer (but not running from USB): +* Preparing for GSoC 2011 +* Etenil and others improved the help output of the crucial settrans command: +* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). +* Svante Signell [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again :) +* + Watch these places for news: -- cgit v1.2.3 From e518686bffd6beeae9a4847aec73348e58ee7fa5 Mon Sep 17 00:00:00 2001 From: "arne@draketo.de" Date: Thu, 24 Mar 2011 15:11:02 +0000 Subject: abbreviate porting as more porting :) --- news/2011-01.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/news/2011-01.mdwn b/news/2011-01.mdwn index 3b27a545..eee70743 100644 --- a/news/2011-01.mdwn +++ b/news/2011-01.mdwn @@ -31,7 +31,8 @@ else=" * Etenil and others improved the help output of the crucial settrans command: * Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). * Svante Signell [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again :) -* +* Svante Signell got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) and also got many more packages building again. + Watch these places for news: -- cgit v1.2.3 From 64bf386c3e1a2037f3eb79f733536b54a5e3b187 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 24 Mar 2011 15:23:08 +0000 Subject: skipping news 2011-01 --HG-- rename : news/2011-01.mdwn => news/2011-02.mdwn --- news/2011-01.mdwn | 78 ------------------------------------------------------- news/2011-02.mdwn | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+), 78 deletions(-) delete mode 100644 news/2011-01.mdwn create mode 100644 news/2011-02.mdwn diff --git a/news/2011-01.mdwn b/news/2011-01.mdwn deleted file mode 100644 index eee70743..00000000 --- a/news/2011-01.mdwn +++ /dev/null @@ -1,78 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - - - -A month of the Hurd: *TODO* / *TODO* / *TODO*. -[[!if test="included()" then="""[[!toggle id=full_news -text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" -else=" -[[!paste id=full_news]]"]] - -[[!cut id="full_news" text=""" - - - - - -* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) -* Samuel Thibault: Bootable USB installer (but not running from USB): -* Preparing for GSoC 2011 -* Etenil and others improved the help output of the crucial settrans command: -* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). -* Svante Signell [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again :) -* Svante Signell got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) and also got many more packages building again. - - - -Watch these places for news: - - * GNU - - * - - * - - * - - * - - * - - * - - Also Git log. - - * () - - * () - - Better use the Git log. - - * - - * Debian - - * - - * - - * Arch Hurd - - * - - * - - * () - -"""]] diff --git a/news/2011-02.mdwn b/news/2011-02.mdwn new file mode 100644 index 00000000..eee70743 --- /dev/null +++ b/news/2011-02.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + + +A month of the Hurd: *TODO* / *TODO* / *TODO*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + + + + + +* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) +* Samuel Thibault: Bootable USB installer (but not running from USB): +* Preparing for GSoC 2011 +* Etenil and others improved the help output of the crucial settrans command: +* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). +* Svante Signell [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again :) +* Svante Signell got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) and also got many more packages building again. + + + +Watch these places for news: + + * GNU + + * + + * + + * + + * + + * + + * + + Also Git log. + + * () + + * () + + Better use the Git log. + + * + + * Debian + + * + + * + + * Arch Hurd + + * + + * + + * () + +"""]] -- cgit v1.2.3 From 3261c36229bfca9e8d4b1b9f679f54bad539f877 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 24 Mar 2011 15:47:48 +0000 Subject: news nicer wording --- news/2011-02.mdwn | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/news/2011-02.mdwn b/news/2011-02.mdwn index eee70743..e33f6009 100644 --- a/news/2011-02.mdwn +++ b/news/2011-02.mdwn @@ -13,7 +13,7 @@ Will be set by tschwinge when publishing. [[!meta date="YYYY-MM-DD HH:MM UTC"]] --> -A month of the Hurd: *TODO* / *TODO* / *TODO*. +A month of the Hurd: porting / *TODO* / *TODO*. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" else=" @@ -21,17 +21,16 @@ else=" [[!cut id="full_news" text=""" - - + * Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) -* Samuel Thibault: Bootable USB installer (but not running from USB): -* Preparing for GSoC 2011 -* Etenil and others improved the help output of the crucial settrans command: -* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). -* Svante Signell [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again :) -* Svante Signell got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) and also got many more packages building again. +* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again and got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) along with fixing build problems of many other packages. +* Samuel Thibault explained how to use the live CD to install Hurd from a USB stick (but not rwrite to USB): +* And we started preparing for GSoC 2011 - if you are interested in contributing, why not drop by +* Also Etenil and others improved the help output of the crucial settrans command: + +And last but not least, we got [mentioned by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). -- cgit v1.2.3 From bd4a611c1248a1a3a4111ae75c0e605aca96e44a Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 24 Mar 2011 16:59:15 +0100 Subject: news: polish --- news/2011-02.mdwn | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/news/2011-02.mdwn b/news/2011-02.mdwn index e33f6009..41563724 100644 --- a/news/2011-02.mdwn +++ b/news/2011-02.mdwn @@ -24,17 +24,15 @@ else=" -* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) -* Svante Signell [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment again and got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) along with fixing build problems of many other packages. -* Samuel Thibault explained how to use the live CD to install Hurd from a USB stick (but not rwrite to USB): -* And we started preparing for GSoC 2011 - if you are interested in contributing, why not drop by -* Also Etenil and others improved the help output of the crucial settrans command: +* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) and [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment and got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) - along with fixing build problems of many other packages. +* Samuel Thibault explained how to use the LiveCD to install Hurd from a USB stick (but not write to USB, as GNU Mach is still missing USB support): while +* the Arch Hurd folks wrote a [Year of Arch Hurd](http://www.barrucadu.co.uk/year-of-arch-hurd), wrapping up their successes, including GHAMP (GNU/Hurd, Apache, MySQL, and PHP), Xorg and their [Arch Hurd LiveCD](http://www.archhurd.org/gethurd.php#livecd). +* Also we started preparing for GSoC 2011 - if you are interested in contributing, why not drop by +* And Etenil and others improved the help output of the crucial settrans command: -And last but not least, we got [mentioned by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). +And finally we got [mentioned by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). - - -Watch these places for news: + + """]] -- cgit v1.2.3 From ad0ca6474f679a2c3fa9e977b337ca2516efe76a Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 24 Mar 2011 17:32:11 +0100 Subject: better title --- news/2011-02.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/news/2011-02.mdwn b/news/2011-02.mdwn index 41563724..9f2a23a0 100644 --- a/news/2011-02.mdwn +++ b/news/2011-02.mdwn @@ -13,7 +13,7 @@ Will be set by tschwinge when publishing. [[!meta date="YYYY-MM-DD HH:MM UTC"]] --> -A month of the Hurd: porting / *TODO* / *TODO*. +A month of the Hurd: Porting, Arch Hurd 2010 and GSoC 2011. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" else=" -- cgit v1.2.3 From 550b72d5645b45e25eb8e8b77fba6e1b6283e3cd Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 24 Mar 2011 18:12:46 +0100 Subject: news: better wording --- news/2011-02.mdwn | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/news/2011-02.mdwn b/news/2011-02.mdwn index 9f2a23a0..ee23e913 100644 --- a/news/2011-02.mdwn +++ b/news/2011-02.mdwn @@ -24,13 +24,17 @@ else=" -* Svante Signell: [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) and [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment and got libgc1c2 building by just [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) - along with fixing build problems of many other packages. -* Samuel Thibault explained how to use the LiveCD to install Hurd from a USB stick (but not write to USB, as GNU Mach is still missing USB support): while +* During the last two months, Svante Signell ported [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) and [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment and got libgc1c2 building by simply [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) - along with fixing build problems of many other packages. + +* Samuel Thibault [explained](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00077.html) how to use the LiveCD to install Hurd from a USB stick (but not write to USB, as GNU Mach is still missing USB support) and + * the Arch Hurd folks wrote a [Year of Arch Hurd](http://www.barrucadu.co.uk/year-of-arch-hurd), wrapping up their successes, including GHAMP (GNU/Hurd, Apache, MySQL, and PHP), Xorg and their [Arch Hurd LiveCD](http://www.archhurd.org/gethurd.php#livecd). -* Also we started preparing for GSoC 2011 - if you are interested in contributing, why not drop by -* And Etenil and others improved the help output of the crucial settrans command: -And finally we got [mentioned by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). +* Also Etenil and others [improved the help output](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00011.html) of the crucial settrans command, which is used throughout the Hurd from mounting file systems to setting up the network. + +* And we started [preparing](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00000.html) for GSoC 2011 - if you are interested in contributing, why not drop by? Many project ideas can be found at [[community/gsoc/project_ideas]]. + +Finally we got a nice [mention by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing (too) good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). - -A month of the Hurd: Porting, Arch Hurd 2010 and GSoC 2011. -[[!if test="included()" then="""[[!toggle id=full_news -text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" -else=" -[[!paste id=full_news]]"]] - -[[!cut id="full_news" text=""" - - - - -* During the last two months, Svante Signell ported [x86info](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00030.html) and [fixed dhcp](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) with help from Samuel Thibault, bringing the Hurd [closer to full d-i support](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00016.html). Also he [got emacs working again](http://lists.debian.org/debian-hurd/2011/01/msg00025.html), giving the Hurd a full GNU environment and got libgc1c2 building by simply [copying the symbols file](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) - along with fixing build problems of many other packages. - -* Samuel Thibault [explained](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00077.html) how to use the LiveCD to install Hurd from a USB stick (but not write to USB, as GNU Mach is still missing USB support) and - -* the Arch Hurd folks wrote a [Year of Arch Hurd](http://www.barrucadu.co.uk/year-of-arch-hurd), wrapping up their successes, including GHAMP (GNU/Hurd, Apache, MySQL, and PHP), Xorg and their [Arch Hurd LiveCD](http://www.archhurd.org/gethurd.php#livecd). - -* Also Etenil and others [improved the help output](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00011.html) of the crucial settrans command, which is used throughout the Hurd from mounting file systems to setting up the network. - -* And we started [preparing](http://lists.gnu.org/archive/html/bug-hurd/2011-02/msg00000.html) for GSoC 2011 - if you are interested in contributing, why not drop by? Many project ideas can be found at [[community/gsoc/project_ideas]]. - -Finally we got a nice [mention by xkcd](http://www.explainxkcd.com/2011/01/07/good-code/) as an example of writing (too) good code (though the resolution does not really do the Hurd justice, as it ignores that it got into a state in which these news can be written in the Hurd itself, even though it has very few active developers. If you want to see how much difference *you* can make, just ask Svante). - - - -"""]] diff --git a/news/2011-q1.mdwn b/news/2011-q1.mdwn new file mode 100644 index 00000000..103f559b --- /dev/null +++ b/news/2011-q1.mdwn @@ -0,0 +1,57 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2011-04-05 21:30 UTC"]] + +A quarter of the Hurd, Q1 of 2011: *GSoC*, and *new faces*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +We're again participating in the [[Google Summer of Code's 2011 +edition|community/gsoc]]. If you know someone who knows that her neighbor +would be interested in getting mentored (by us) and paid (by Google) for +working on a [[GNU/Hurd task|community/gsoc/project_ideas]], please hurry up: +the *student application period* will end this Friday, 2011-04-08. + +There's further progress to be reported on the package porting front: +additionally to the usual suspects, Svante Signell +[has](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00028.html) +actively [started](http://lists.debian.org/debian-hurd/2011/02/msg00021.html) +with [contributing](http://lists.debian.org/debian-hurd/2011/02/msg00036.html) +by [fixing](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) +or [porting](http://lists.debian.org/debian-hurd/2011/01/msg00025.html) his +[favorite](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) packages +[to](http://lists.debian.org/debian-hurd/2011/01/msg00051.html) GNU/Hurd. +Welcome, Svante! + +Amongst other fixes, Diego Nieto Cid submitted his work for using [XKB's +keymaps for the Hurd +console](http://lists.gnu.org/archive/html/bug-hurd/2011-03/threads.html#00053). +Of course, he was not the only one to contribute fixes; there's always our +bunch of folks who appear every other month, or week, and send in some +contribution. Also, as we ask our GSoC applicants to submit patches in order +to substantiate their application, we've seen some additional ones due to that. +([[And you can, too.|contributing]]) + +The Arch Hurd folks published their [Year of Arch Hurd +report](http://www.barrucadu.co.uk/year-of-arch-hurd), wrapping up their +progress, including GHAMP (GNU/Hurd, Apache, MySQL, and PHP), X.org, and their +[Arch Hurd LiveCD](http://www.archhurd.org/gethurd.php#livecd). We had +published our [[YotH 2010|2010]], too. + +Finally we got a nice [recognition (or did they mean...) by +xkcd](http://xkcd.com/844/), *How to Write Good Code*, subtitled *You can +either hang out in the Android Loop or the HURD loop*. Go figure! ;-) + +"""]] -- cgit v1.2.3 From 8c6b5c10c616c59e0ea5628255b89e002b5e4e8c Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Wed, 6 Apr 2011 14:56:48 +0200 Subject: begun my GSoC application for PyHurd. --- .../ArneBab/2011-04-06-application-pyhurd.txt | 94 ++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt new file mode 100644 index 00000000..db7b1f65 --- /dev/null +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt @@ -0,0 +1,94 @@ +Python Bindings for the Hurd (PyHurd) +========================== + +## Contact information + +- Name: Arne Babenhauserheide +- E-Mail Address: arne_bab@web.de +- IRC-nick: ArneBab @ freenode +- Jabber-ID: arne@jabber.fsfe.org +- Phone-number: +49 621 43772742 +- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt + +## Who I am + +I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) + +## Project + +For this years GSoC I want to turn the currently rudimentary Python Bindings of the Hurd into a complete Python-library for low-level Hurd and Mach hacking with high level functionality to allow for easy creation of complex applications. Particularly it should make it possible to utilize the whole Python standard library for translators. + +## Preliminary Schedule + +… TODO + +## Detailed answers + +### What I have to learn, and what I already know + +I need to dive into the detailed interfaces of the Hurd to get a better understanding of the exact requirements for a well usable Python interface, especially for higher level functionality, and read up more on working with Cython. + +I already know Python and I did design my share of interfaces for my own hobby projects ([TextRPG][], [Fungus][], [evolve-keyboard-layout][] and others). + +[TextRPG]: https://bitbucket.org/ArneBab/textrpg/ +[Fungus]: https://bitbucket.org/ArneBab/fungus +[evolve-keyboard-layout]: https://bitbucket.org/ArneBab/evolve-keyboard-layout + +Also I know the functionality and design of the Hurd from a user perspective and can code in C and C++. + +### Why did you choose this project idea? What do you consider most appealing about it? + +FIrstoff: It is about making it possible for me to hack on the Hurd using my favorite programming language. + +Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. + +### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? + +I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. + +In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. + +### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? + +The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. + +Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. + +And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). + +But mainly: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/…/*.deb + +And that’s only the beginning. + +### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) + +Yes :) + +### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? + +Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. + +### When does your university term end, when are your exams, and when does the next term begin? + +I have a clean timetable for the summer: No exams anymore. + +### How much time do you intend to spend on your GSoC project per day/week during the summer months? + +I plan to spend at least 40 hours per week on the PyHurd. + +### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? + +Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. + +### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? + +My main plan to keep it maintained is to comment it cleanly, and naturally to keep using the Hurd and PyHurd itself, so any breakage will bother me personally. + +Also i want to get it merged into the main git repositories, so it is directly accessible for later developers. + +### Anything else you want to add to your application? + +Alterrnately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. The third component needed for this is [[moving the Hurd libs from cthreads to pthreads|community/gsoc/project_ideas/pthreads]], but since that is not as closely connected to Python, I prefer PyHurd and fixing the testsuite over the pthread migration. -- cgit v1.2.3 From 98b6916640606d6201876f71cdb16afe2d5051f6 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Wed, 6 Apr 2011 15:00:24 +0200 Subject: FIX: wrong extension. --- .../ArneBab/2011-04-06-application-pyhurd.mdwn | 94 ++++++++++++++++++++++ .../ArneBab/2011-04-06-application-pyhurd.txt | 94 ---------------------- 2 files changed, 94 insertions(+), 94 deletions(-) create mode 100644 community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn delete mode 100644 community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn new file mode 100644 index 00000000..db7b1f65 --- /dev/null +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -0,0 +1,94 @@ +Python Bindings for the Hurd (PyHurd) +========================== + +## Contact information + +- Name: Arne Babenhauserheide +- E-Mail Address: arne_bab@web.de +- IRC-nick: ArneBab @ freenode +- Jabber-ID: arne@jabber.fsfe.org +- Phone-number: +49 621 43772742 +- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt + +## Who I am + +I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) + +## Project + +For this years GSoC I want to turn the currently rudimentary Python Bindings of the Hurd into a complete Python-library for low-level Hurd and Mach hacking with high level functionality to allow for easy creation of complex applications. Particularly it should make it possible to utilize the whole Python standard library for translators. + +## Preliminary Schedule + +… TODO + +## Detailed answers + +### What I have to learn, and what I already know + +I need to dive into the detailed interfaces of the Hurd to get a better understanding of the exact requirements for a well usable Python interface, especially for higher level functionality, and read up more on working with Cython. + +I already know Python and I did design my share of interfaces for my own hobby projects ([TextRPG][], [Fungus][], [evolve-keyboard-layout][] and others). + +[TextRPG]: https://bitbucket.org/ArneBab/textrpg/ +[Fungus]: https://bitbucket.org/ArneBab/fungus +[evolve-keyboard-layout]: https://bitbucket.org/ArneBab/evolve-keyboard-layout + +Also I know the functionality and design of the Hurd from a user perspective and can code in C and C++. + +### Why did you choose this project idea? What do you consider most appealing about it? + +FIrstoff: It is about making it possible for me to hack on the Hurd using my favorite programming language. + +Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. + +### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? + +I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. + +In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. + +### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? + +The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. + +Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. + +And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). + +But mainly: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/…/*.deb + +And that’s only the beginning. + +### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) + +Yes :) + +### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? + +Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. + +### When does your university term end, when are your exams, and when does the next term begin? + +I have a clean timetable for the summer: No exams anymore. + +### How much time do you intend to spend on your GSoC project per day/week during the summer months? + +I plan to spend at least 40 hours per week on the PyHurd. + +### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? + +Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. + +### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? + +My main plan to keep it maintained is to comment it cleanly, and naturally to keep using the Hurd and PyHurd itself, so any breakage will bother me personally. + +Also i want to get it merged into the main git repositories, so it is directly accessible for later developers. + +### Anything else you want to add to your application? + +Alterrnately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. The third component needed for this is [[moving the Hurd libs from cthreads to pthreads|community/gsoc/project_ideas/pthreads]], but since that is not as closely connected to Python, I prefer PyHurd and fixing the testsuite over the pthread migration. diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt deleted file mode 100644 index db7b1f65..00000000 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.txt +++ /dev/null @@ -1,94 +0,0 @@ -Python Bindings for the Hurd (PyHurd) -========================== - -## Contact information - -- Name: Arne Babenhauserheide -- E-Mail Address: arne_bab@web.de -- IRC-nick: ArneBab @ freenode -- Jabber-ID: arne@jabber.fsfe.org -- Phone-number: +49 621 43772742 -- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt - -## Who I am - -I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) - -## Project - -For this years GSoC I want to turn the currently rudimentary Python Bindings of the Hurd into a complete Python-library for low-level Hurd and Mach hacking with high level functionality to allow for easy creation of complex applications. Particularly it should make it possible to utilize the whole Python standard library for translators. - -## Preliminary Schedule - -… TODO - -## Detailed answers - -### What I have to learn, and what I already know - -I need to dive into the detailed interfaces of the Hurd to get a better understanding of the exact requirements for a well usable Python interface, especially for higher level functionality, and read up more on working with Cython. - -I already know Python and I did design my share of interfaces for my own hobby projects ([TextRPG][], [Fungus][], [evolve-keyboard-layout][] and others). - -[TextRPG]: https://bitbucket.org/ArneBab/textrpg/ -[Fungus]: https://bitbucket.org/ArneBab/fungus -[evolve-keyboard-layout]: https://bitbucket.org/ArneBab/evolve-keyboard-layout - -Also I know the functionality and design of the Hurd from a user perspective and can code in C and C++. - -### Why did you choose this project idea? What do you consider most appealing about it? - -FIrstoff: It is about making it possible for me to hack on the Hurd using my favorite programming language. - -Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. - -### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? - -I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. - -In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. - -### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? - -The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. - -Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. - -And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). - -But mainly: - - settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / - dpkg -i ftp://ftp.gnu.org/…/*.deb - -And that’s only the beginning. - -### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) - -Yes :) - -### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? - -Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. - -### When does your university term end, when are your exams, and when does the next term begin? - -I have a clean timetable for the summer: No exams anymore. - -### How much time do you intend to spend on your GSoC project per day/week during the summer months? - -I plan to spend at least 40 hours per week on the PyHurd. - -### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? - -Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. - -### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? - -My main plan to keep it maintained is to comment it cleanly, and naturally to keep using the Hurd and PyHurd itself, so any breakage will bother me personally. - -Also i want to get it merged into the main git repositories, so it is directly accessible for later developers. - -### Anything else you want to add to your application? - -Alterrnately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. The third component needed for this is [[moving the Hurd libs from cthreads to pthreads|community/gsoc/project_ideas/pthreads]], but since that is not as closely connected to Python, I prefer PyHurd and fixing the testsuite over the pthread migration. -- cgit v1.2.3 From dc69fcdaa1c13bdb26cac2fcf9999868e7e8dc75 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Wed, 6 Apr 2011 15:01:24 +0200 Subject: obfuscate the phone number… MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index db7b1f65..52e2810c 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -7,7 +7,7 @@ Python Bindings for the Hurd (PyHurd) - E-Mail Address: arne_bab@web.de - IRC-nick: ArneBab @ freenode - Jabber-ID: arne@jabber.fsfe.org -- Phone-number: +49 621 43772742 +- Phone-number: XXXXXXXXX - GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt ## Who I am -- cgit v1.2.3 From e94adc465ba37a05d3286b38aaba98105f807171 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Wed, 6 Apr 2011 15:04:44 +0200 Subject: added initial fix heading --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 52e2810c..dd7745bc 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -22,6 +22,10 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of … TODO +## Initial Fix + +… TODO + ## Detailed answers ### What I have to learn, and what I already know -- cgit v1.2.3 From 596b1af9d8cd8668699000d3aca53feb4ef07067 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Wed, 6 Apr 2011 15:06:21 +0200 Subject: note --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index dd7745bc..5e8f1cc3 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -46,6 +46,8 @@ FIrstoff: It is about making it possible for me to hack on the Hurd using my fav Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. +And I helped getting the project running and have been intrigued by how far it can be pushed. + ### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. -- cgit v1.2.3 From f85b983ee7cfbff5a12ada424e9a848882991231 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 6 Apr 2011 20:54:58 +0200 Subject: mailing_lists/unmoderated: Also for first message after subscribing. --- mailing_lists/unmoderated.mdwn | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mailing_lists/unmoderated.mdwn b/mailing_lists/unmoderated.mdwn index 4bef130e..385f2615 100644 --- a/mailing_lists/unmoderated.mdwn +++ b/mailing_lists/unmoderated.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] In fact the lists *are* moderated for users that post from not-subscribed email addresses. However, this moderation should be transparent to the poster, you @@ -14,6 +15,8 @@ only might notice some additional delay until your message shows up on the list, as it has to be handled manually. Note that this is a one-time delay, as the address will be added to a white-list, so that further messages from the same sending address will get through immediatelly. +The same holds for people who are sending their first message after subscribing +to a list. These two measures greatly help to keep the lists' spam level low. So, to initiate a discussion you do not need to subscribe to the mailing list in question. And people are very much encouraged to maintain the CC -- cgit v1.2.3 From 34bbd550a3434f6b1dca30b53a8e5d4c82051aa4 Mon Sep 17 00:00:00 2001 From: sudoman Date: Wed, 6 Apr 2011 18:58:56 +0000 Subject: fixed broken Wikipedia link --- mailing_lists.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn index f89a6e72..ff4dab9f 100644 --- a/mailing_lists.mdwn +++ b/mailing_lists.mdwn @@ -24,7 +24,7 @@ do so. If in doubt, don't; just choose the single most appropriate list. When replying to others, please don't top-post and trim the existing text to quote only the sections you're actually replying to. See [[!wikipedia Posting_style]] for further reading, especially [[!wikipedia -Posting_style#Inline_replying]]. +Posting_style#Interleaved_style]]. Also see these general notes about [[community/communication]]. -- cgit v1.2.3 From f2c94d05a680b95fe83422b40518d11add77313d Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 06:19:20 +0200 Subject: updated the GSoC proposal. --- .../weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 5e8f1cc3..2b066f15 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -20,11 +20,22 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of ## Preliminary Schedule -… TODO +*still very rough* + +0. (before GSoC) Read up on the current C-interface to the Hurd and Cython. Especially grok the Hurd hacking guide. Add docstrings to all existing source files explaining what they do. Add auto-generated API-docs. Deliverable: Easy to understand API-docs of the current PyHurd, a simple way to generate them from the sources. 2 Weeks. +1. Check the API. + 1. Implement a Hello World translator, naivly implementing the necessary Mach parts, as example to test the current API. + 2. redesign and realize an updated low-level API. + 3. design a pythonic high-level API for translators. +2. Realize a pythonic trivfs library and an example translator using it. +3. Mid-Term: trivfs works. Push the code to https://github.com/ArneBab/PyHurd +4. Implement more complex and specialized translator libraries, along with example translators. +5. Re-implement some hurd specific utils in pyhurd such as settrans. +6. Push the final code to https://github.com/ArneBab/PyHurd ## Initial Fix -… TODO +Initial Fix: Making PyHurd build again under Cython 0.14.1. Sent as patch series to bug-hurd@gnu.org ## Detailed answers @@ -46,7 +57,7 @@ FIrstoff: It is about making it possible for me to hack on the Hurd using my fav Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. -And I helped getting the project running and have been intrigued by how far it can be pushed. +And I helped getting the project running and am intrigued by how far it can be pushed. ### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? -- cgit v1.2.3 From a7e1c08e2be8089c2cd6247ad6a7b1b097c0613c Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 07:50:19 +0200 Subject: removed pthreads from the needed projects for PyHurd --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 2b066f15..662f7a96 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -108,4 +108,4 @@ Also i want to get it merged into the main git repositories, so it is directly a ### Anything else you want to add to your application? -Alterrnately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. The third component needed for this is [[moving the Hurd libs from cthreads to pthreads|community/gsoc/project_ideas/pthreads]], but since that is not as closely connected to Python, I prefer PyHurd and fixing the testsuite over the pthread migration. +Alternately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. -- cgit v1.2.3 From 4ef21612a75f57aef11c587f5568498427353bf8 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 11:20:37 +0200 Subject: GSoC PyHurd application: Note about an idea for a really simple API. --- .../ArneBab/2011-04-06-application-pyhurd.mdwn | 10 ++- .../2011-04-06-application-python-test.mdwn | 92 ++++++++++++++++++++++ 2 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 662f7a96..420b1cab 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -108,4 +108,12 @@ Also i want to get it merged into the main git repositories, so it is directly a ### Anything else you want to add to your application? -Alternately I would also like to work on [[fixing Python testsuite breakages|community/gsoc/project_ideas/perl_python]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. +I’d love to work on PyHurd, because it grips me more and more. A high level API might get as simple as + + from translator.source.text import * + from translator.representation.tree import * + def source_text_changed(text): … (adapt tree object) + def repres_tree_changed(tree): … (adapt text object) + → 2-way connecting + writeonly is then done by simply leaving out the definition for the source__changed. + source is the node below and repres is the translated node diff --git a/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn new file mode 100644 index 00000000..8bc338f4 --- /dev/null +++ b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn @@ -0,0 +1,92 @@ +Improving Python support (fixing testsuite failures) +========================== + +## Contact information + +- Name: Arne Babenhauserheide +- E-Mail Address: arne_bab@web.de +- IRC-nick: ArneBab @ freenode +- Jabber-ID: arne@jabber.fsfe.org +- Phone-number: XXXXXXXXX +- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt + +## Who I am + +I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) + +## Project + +For this years GSoC I want to fix all testsuite errors python on the Hurd, which on the one hand ensures, that we have no unexpected errors in Python applications and on the other hand is a dependency for a full featured PyHurd. + +## Preliminary Schedule + +*from simple fixes to complex ones.* + +… TODO as soon as the testsuite finished and the results are stored → grep + decide. + +## Initial Fix + +… TODO + +## Detailed answers + +### What I have to learn, and what I already know + +I need to incrementally learn details of the implementation of Python and the Hurd while I move from one testsuite breakage to the next. + +I know Python quite well and I know the rough workings of the Hurd and can code in C and C++. + +### Why did you choose this project idea? What do you consider most appealing about it? + +I want the PyHurd project to succeed, and I love Python and the concepts behind the Hurd. So I want full Python support on the Hurd. Every testsuite breakage is a possible stumbling point for Python programs, which is very hard to debug for a Python programmer, as it lies within the platform (Python on Hurd) and not in his/her own code. + +### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? + +I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. + +In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. + +### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? + +The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. + +Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. + +And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). + +But mainly: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/…/*.deb + +And that’s only the beginning. + +### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) + +Yes :) + +### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? + +Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. + +### When does your university term end, when are your exams, and when does the next term begin? + +I have a clean timetable for the summer: No exams anymore. + +### How much time do you intend to spend on your GSoC project per day/week during the summer months? + +I plan to spend at least 40 hours per week on the PyHurd. + +### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? + +Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. + +### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? + +I plan to get the Python and the Hurd fixes upstream, in the case of Python by pushing all code to a clone of the official Python repository¹ and trying to get the Python community to accept the changes, and in the case of fixes in the Hurd by getting it integrated in the main repositories as soon as possible. + +¹: http://bitbucket.org/ArneBab/cpython + +### Anything else you want to add to your application? + +Alterrnately I would also like to work on [[Python bindings for the Hurd|community/gsoc/project_ideas/language_bindings]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. -- cgit v1.2.3 From 368f18a883aea2fd427db75a4fe44b78969445f5 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 11:21:18 +0200 Subject: polish --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 420b1cab..5be6baa9 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -108,7 +108,7 @@ Also i want to get it merged into the main git repositories, so it is directly a ### Anything else you want to add to your application? -I’d love to work on PyHurd, because it grips me more and more. A high level API might get as simple as +I’d love to work on PyHurd, because it grips me more and more. For example a high level API might get as simple as from translator.source.text import * from translator.representation.tree import * -- cgit v1.2.3 From fd5b568b614fb930517681c0dfc630d499c6398e Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 13:04:10 +0200 Subject: GSoC pyhurd: At the end as many cool translators as possible. --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 5be6baa9..47d16f3a 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -31,7 +31,8 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of 3. Mid-Term: trivfs works. Push the code to https://github.com/ArneBab/PyHurd 4. Implement more complex and specialized translator libraries, along with example translators. 5. Re-implement some hurd specific utils in pyhurd such as settrans. -6. Push the final code to https://github.com/ArneBab/PyHurd +6. With the remaining time, create as many cool translators as possible :) +7. Push the final code to https://github.com/ArneBab/PyHurd ## Initial Fix @@ -114,6 +115,6 @@ I’d love to work on PyHurd, because it grips me more and more. For example a h from translator.representation.tree import * def source_text_changed(text): … (adapt tree object) def repres_tree_changed(tree): … (adapt text object) - → 2-way connecting + → 2-way connectingk,5 writeonly is then done by simply leaving out the definition for the source__changed. source is the node below and repres is the translated node -- cgit v1.2.3 From 4c63187abaef32037edad63c6b82b31763584bff Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 13:56:56 +0200 Subject: gsoc2011 (java): Initial import of the proposal --- user/jkoenig/gsoc2011_classes.dia | 2227 +++++++++++++++++++++++++++++++++++ user/jkoenig/gsoc2011_classes.png | Bin 0 -> 59337 bytes user/jkoenig/gsoc2011_proposal.mdwn | 567 +++++++++ 3 files changed, 2794 insertions(+) create mode 100644 user/jkoenig/gsoc2011_classes.dia create mode 100644 user/jkoenig/gsoc2011_classes.png create mode 100644 user/jkoenig/gsoc2011_proposal.mdwn diff --git a/user/jkoenig/gsoc2011_classes.dia b/user/jkoenig/gsoc2011_classes.dia new file mode 100644 index 00000000..1aa3ef6c --- /dev/null +++ b/user/jkoenig/gsoc2011_classes.dia @@ -0,0 +1,2227 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + #User-defined classes# + + + + + + + + + + + + + + + + + + + + #HelloIo# + + + ## + + + #Implements a file which always contains "Hello, World!\n"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #write# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #data# + + + #char[]# + + + ## + + + ## + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + + + #read# + + + ## + + + #char[]# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #amount# + + + #int# + + + ## + + + ## + + + + + + + + + + #seek# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #whence# + + + #int# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + #MIG-generated classes# + + + + + + + + + + + + + + + + + + + + #IoServer# + + + ## + + + #Implements a message handler using a given IO object as a backend# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IoServer# + + + ## + + + ## + + + + + + ## + + + + + + + + + + + + + + + + + #back# + + + #Io# + + + ## + + + ## + + + + + + + + + + #handle# + + + ## + + + #Message# + + + + + + ## + + + + + + + + + + + + + + + + + #message# + + + #Message# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Io# + + + #interface# + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #write# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #data# + + + #char[]# + + + ## + + + ## + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + + + #read# + + + ## + + + #char[]# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #amount# + + + #int# + + + ## + + + ## + + + + + + + + + + #seek# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #whence# + + + #int# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IoUser# + + + ## + + + #Implements the Io interface by performing RPC# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IoUser# + + + ## + + + ## + + + + + + ## + + + + + + + + + + + + + + + + + #port# + + + #MachPort# + + + ## + + + ## + + + + + + + + + + #write# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #data# + + + #char[]# + + + ## + + + ## + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + + + #read# + + + ## + + + #char[]# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #amount# + + + #int# + + + ## + + + ## + + + + + + + + + + #seek# + + + ## + + + #int# + + + + + + ## + + + + + + + + + + + + + + + + + #offset# + + + #int# + + + ## + + + ## + + + + + + + + #whence# + + + #int# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + ## + + + + + + + + + ## + + + + + + + + + + + + ## + + + ## + + + + + + + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + #libports-like library# + + + + + + + + + + + + + + + + + + + + #Server# + + + #interface# + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #handle# + + + ## + + + #Message# + + + + + + ## + + + + + + + + + + + + + + + + + #msg# + + + #Message# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Demux# + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #addServer# + + + ## + + + ## + + + + + + ## + + + + + + + + + + + + + + + + + #s# + + + #Server# + + + ## + + + ## + + + + + + + + + + #handle# + + + ## + + + #Message# + + + + + + ## + + + + + + + + + + + + + + + + + #msg# + + + #Message# + + + ## + + + ## + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + ## + + + ## + + + + + + + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Plus some kind of port set +support and a way to start +a server thread.# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #io.defs# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #mig# + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + ## + + + + + + + + diff --git a/user/jkoenig/gsoc2011_classes.png b/user/jkoenig/gsoc2011_classes.png new file mode 100644 index 00000000..7149b813 Binary files /dev/null and b/user/jkoenig/gsoc2011_classes.png differ diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn new file mode 100644 index 00000000..666733c1 --- /dev/null +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -0,0 +1,567 @@ + +# Java for Hurd (and vice vera) + +Contact information: + + * Full name: Jérémie Koenig + * Email: jk@jk.fr.eu.org + * IRC: jkoenig on Freenode and OFTC + +## Introductions + +I am a first year M.Sc. student +in Computer Science at University of Strasbourg (France). +My interests include capability-based security, +programming languages and formal methods (in particular, proof-carrying code). + +### Previous involvement + +Although I have known the Hurd for some time, +I did not contribute until last summer, +during which I participated to Google Summer of Code +as a student for the Debian project. +I worked on porting Debian-Installer to Hurd. +This project was mostly a success, +although we still have to use a special mirror for installation +with a few modified packages +and tweaked priorities +to work around some uninstallable packages +with Priority: standard. + +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 +such as `procps` or `htop`. + +Although I have not had as much time +as I would have liked to dedicate to the Hurd +since that time, +I have continued to maintain the mirror in question, +and I have started to work +on implementing POSIX threads signal semantics in glibc. + +### Project-related skills and interests + +I have used Java mostly for university assignements. +This includes non-trivial projects +using threads and distributed programming frameworks +such as Java RMI or CORBA. +I have also used it to experiment with +Google App Engine +(web applications) +and Google Web Toolkit +(a compiler from Java to Javascript which helps with AJAX code), +and I have some limited experience with JNI +(the Java Native Interface, to link Java with C code). + +My knowledge of the Hurd and Debian GNU/Hurd is reasonable, +as the Debian-Installer and procfs projects +gave me the opportunity to fiddle with many parts of the system. + + +## Improve Java support + +### Justification + +Java is a popular language and platform used by many desktop and web +applications (mostly on the server side). As a consequence, competitive Java +support is important for any general-purpose operating system. + +### Current situation + +Java is currently supported on Hurd with the GNU Java suite: + + * GCJ, the GNU Compiler for Java, is part of GCC and can compile Java + source code to Java bytecode, and both source code and bytecode to + native code; + * libgcj is the implementation of the Java runtime which GCJ uses. It is + based on GNU Classpath. It includes a bytecode interpreter which enables + Java applications compiled to native code to dynamically load and execute + Java bytecode from class files. + * The gij command is a wrapper around the above-mentioned virtual machine + functionality of libgcj and can be used as a replacement for the java + command. + +However, GCJ does not work flawlessly on Hurd.r +For instance, some parts of libgcj relies on +the POSIX threads signal semantics, which are not yet implemented. +In particular, this makes ant hang waiting for child processes, +which makes some packages fail to build on Hurd +(“ant” is the “make” of the Java world). + +### Tasks + + * **Finish implementing POSIX thread semantics** in glibc (high priority). + According to POSIX, signal dispositions should be global to a process, + while signal blocking masks should be thread-specific. Signals sent to the + process as a whole are to be delivered to any thread which does not block + them. By contrast, Hurd has per-thread signal dispositions and signals + sent to a process are delivered to the main thread only. I have been + working on refactoring the glibc signal code and implementing the POSIX + semantics as a per-thread option. However, due to lack of time I have not + yet been able to test and debug my code properly. Finishing this work + would be my first task. + * **Fix further problems with GCJ on Hurd** (high priority). While I’m not + aware of any other problems with GCJ at the moment, I suspect some might + turn up as I progress with the other tasks. Fixing these problems would + also be a high-priority task. + * **Port OpenJDK 6** (medium priority). While GCJ is fine, it is not yet + 100% complete. It is also slower than OpenJDK on architectures where a + just-in-time compiler is available. Porting OpenJDK would therefore + improve Java support on Hurd in scope and quality. Besides, it would also + be a good way to test GCJ, which is used for bootstrapping by the Debian + OpenJDK packages. Also note that OpenJDK 6 is now the default Java + Runtime Environment on all released Linux-based Debian architectures; + bringing Hurd in line with this would probably be a good thing. + * **Port Eclipse and other Java applications** (low priority). Eclipse is a + popular, state-of-the-art IDE and tool suite used for Java and other + languages. It is a dependency of the Joe-E verifier (see part 3 of this + proposal). Porting Eclipse would be a good opportunity to test GCJ and + OpenJDK. + + +## Create Java bindings for the Hurd interfaces + +### Justification + +Java is a popular language, used for many applications and often taught to +introduce object-oriented programming. The fact that Java is a +garbage-collected language makes it easier to use, especially for the less +experienced programmers. Besides, the object-oriented nature of Java is a +natural fit for the capability-based design of Hurd. + +Advantages over other garbage-collected, object-oriented languages include +performance, type safety and the possibility to compile a Java translator to +native code and link it statically using GCJ, should anyone want to use a +translator written in Java for booting. Note that Java is being used in this +manner for embedded development. + +Java bindings would lower the bar for newcomers +to begin experimenting with what makes Hurd unique +without being faced right away with the complexity of +low-level systems programming. + +### Approach + +One approach used previously to interface programming languages with the Hurd +has been to create bindings for helper libraries such as libtrivfs. Instead, +for Java I would like to take a lower-level approach by providing access to +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. +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. + +### Design goals + +FIXME: a completer + + * Give maximum flexibility to the Java code while maintaining the memory + safety of Java, and using a minimum amount of C code. + * Provide higher-level interfaces as well, ... + * Hurd objects would map to Java objects. + * Local objects can be accessed directly, + remote objects can be accessed transparently over IPC. + +### Bindings for Mach system calls + +In this low-level approach, my intention is to enable Java code to use Mach +system calls (in particular, mach_msg) more or less directly. This would +ensure full access to the system from Java code, but it raises a number of +issues: + + * the Java code must be able to manipulate Mach-level entities, such as port + rights or page-aligned buffers mapped outside of the garbage-collected + heap (for out-of-line transfers); + * putting together IPC messages requires control of the low-level + representation of data. + +In order to address these concerns, classes would be encapsulating these +low-level entities so that they can be referenced through normal, safe objects +from standard Java code. Bindings for Mach system calls can then be provided +in terms of these classes. Their implementation would use C code through the +Java Native Interface (JNI). + +More specifically, this functionality would be provided by the `org.gnu.mach` +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 + C code to represent port rights received through IPC. The `deallocate()` + mehod 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. + * `Buffer` would represent a page-aligned buffer allocated outside of the + Java heap, to be transferred (or having been received) as out-of-line + memory. The JNI code would would provide methods to read and write data at + an arbitrary offset (but within bounds) and would use `vm_allocate()` and + `vm_deallocate()` in the same spirit as for `MachPort` objects. + * `Message` would allow Java code to put together Mach messages. The + 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 + 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. + * `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`, + `Buffer` and `Message` objects when appropriate. The associated C code + would access the contents of such objects directly in order to perform the + required unsafe operations, such as constructing `MachPort` and `Buffer` + objects directly from port names and C pointers. + +Note that careful consideration should be given to the interfaces of these +classes to avoid “safety leaks” which would compromise the safety guarantees +provided by Java. Potential problematic scenarios include the following +examples: + + * It must not be possible to write an integer at some position in a + `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 + 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. + +Finally, access should be provided to the initial ports and file descriptors +in `_hurd_ports` and `FIXME`, for instance through static methods such as +`getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as +`org.gnu.hurd.InitPorts`. + +A realistic example of code based on such interfaces would be: + + import org.gnu.mach.MsgType; + import org.gnu.mach.MachPort; + import org.gnu.mach.Buffer; + import org.gnu.mach.Message; + import org.gnu.mach.Syscall; + import org.gnu.hurd.InitPorts; + + public class Hello + { + public static main(String argv[]) + /* Parent class for all Mach-related exceptions */ + throws org.gnu.mach.MachException + { + /* Allocate a reply port */ + MachPort reply = new MachPort(); + + /* Allocate an out-of-line buffer */ + Buffer data = new Buffer(MsgType.CHAR, 13); + data.writeString(0, "Hello, World!"); + + /* Craft an io_write message */ + Message msg = new Message(1024); + msg.setRemotePort(InitPorts.getdport(1)); + msg.setLocalPort(reply, Message.Type.MAKE_SEND_ONCE); + msg.setId(21000); + msg.addBuffer(data); + + /* Make the call, MACH_MSG_SEND | MACH_MSG_RECEIVE */ + Syscall.machMsg(msg, true, true, reply); + + /* Extract the returned value */ + msg.assertId(21100); + int retCode = msg.readInt(0); + int amount = msg.readInt(1); + } + } + +### Generating Java stubs with MIG + +Once the basic machinery is in place to interface with Mach, Java programs +have more or less equal access to the system functionality without resorting +to more JNI code. However, as illustrated above, this access is far from +convenient. + +As a solution I would modify MIG to add the option to output Java code. MIG +would emit a Java interface, a client class able to implement the interface +given a Mach port send right, an a server class which would be able to handle +incoming messages. The class diagram below, although it is by no means +complete or exempt of any problem, illustrates the general idea: + +[[gsoc2011_classes.png]] + +This structure is somewhat reminiscent of Java RMI or similar systems, +which aim to provide more or less transparent access to remote objects. +The exact way the Java code would be generated still needs to be determined, +but basically: + + * An interface, corresponding to the header files generated by MIG, would + enumerate the operations listed in a given .defs files. Method names would + be transformed to adhere to Java conventions (for instance, + `some_random_identifier` would become `someRandomIdentifier`). + * A user class, corresponding to the `*User.c` files, + 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 + `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, + and would avoid pre-existing code from breaking when new operations are + introduced.) + +In order to help with the implementation of servers, some kind of library +would be needed to associate Mach receive rights with server objects and to +handle incoming messages on dedicated threads, in the spirit of libports. +This would probably require support for port sets at the level of the Mach +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. +Upon reception of a send right, +a `FooUser` object would be created +and associated with the corresponding `MachPort` object. +If the received send right corresponds to a local port +to which a server object has been associated, +this object would be used instead. +This way, +subsequent operations on the received send right +would be handled as direct method calls +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 + 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 + to be determined. Ideally this would be automated and not hardcoded + too much. + * Initially, reply port parameters would be ignored. However they may be + needed for some applications. + +So the details would need to be flushed out during the community bonding +period and as the implementation progresses. However I’m confident that a +satisfactory solution can be designed. + +Using these new features, the example above could be rewritten as: + + import org.gnu.hurd.InitPorts; + import org.gnu.hurd.Io; + import org.gnu.hurd.IoUser; + + class Hello { + static void main(String argv[]) throws ... + { + Io stdout = new IoUser(InitPorts.getdport(1)); + String hello = “Hello, World!\n”; + + int amount = stdout.write(hello.getBytes(), -1); + + /* (A retCode corresponding to an error + would be signalled as an exception.) */ + } + } + +An example of server implementation would be: + + import org.gnu.hurd.Io; + import java.util.Arrays; + + class HelloIo implements Io { + final byte[] contents = “Hello, World!\n”.getBytes(); + + int write(byte[] data, int offset) { + return SOME_ERROR_CODE; + } + + byte[] read(int offset, int amount) { + return Arrays.copyOfRange(contents, offset, + offset + amount - 1); + } + + /* ... */ + } + +A new server object could then be created with `new IoServer(new HelloIo())`, +and associated with some receive right at the level of the ports management +library. + +### Base classes for common types of translators + +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 +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, +or could define a simpler interface +which would then be used by adapter classes +to implement the required ones. + +I would draw inspiration from libtrivfs and libnetfs +to design and implement similar solutions for Java. + +### Packaging and long-term maintenance + +The Java libraries resulting from this work +(including any MIG support classes), +as well as the class files built from the MIG-generated code +for the Mach and Hurd interface definition files, +would be provided as single `hurd-java` package for +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, +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, +and consequently the modifications to MIG +(which would at least conceptually depend on the Mach Java package) +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, +maintenance would primarily consist in +fixing bugs as they are reported, +and adding new features as they are requested. +A large number of such requests +would mean the package is useful, +so I expect that the overall amount of work +would be correlated with the willingness of more people +to help with maintenance +should I become overwhelmed or get hit by a bus. + + +## Timeline + +The dates listed are deadlines for the associated tasks. + + * *Community bonding period.* + Discuss, refine and complete the design of the Java bindings + (in particular the MIG and "libports" parts) + * *May 23.* + Coding starts. + * *May 30.* + Finish implementing pthread signal semantics. + * *June 5.* + Port OpenJDK + * *June 19 (two weeks).* + Fix the remaining problems with GCJ and/or OpenJDK, + possibly port Eclipse or other big Java packages. + * *June 26.* + Create the bindings for Mach. + * *July 3.* + Work on some kind of basic Java libports + to handle receive rights. + * *July 10.* + Test, write some documentation and examples. + * *July 24 (two weeks).* + Add the Java target to MIG. + * *July 31.* + Test, write some documentation and examples. + * *August 7.* + Try to write a basic but non-trivial translator + to evaluate the performance and ease of use of the result, + rectify any rough edges this would uncover. + * *Last two weeks.* + Polish the code, + do the packaging. + + +## Conclusion + + + + +## Appendix: potential applications of object-capability languages + +The work discussed is this last part would have +fewer immediate benefits for the Hurd project +and has more of a research orientation. +It is also unlikely that there would be any time remaining +to work on it at the end of the summer. +(Though it could work as some kind of reward +if I somehow managed to do a prefect job of all the rest +within the allocated time :-) ). +As a consequence, +I don't really consider this a part of my application. + +This being said, +to some extent the project discussed here +will informed the way I design the Java bindings, +since it depends on them +and I intend to work on this at some point in the future. +I also believe it touches on some interesting ideas, +and a Summer of Code application is probably +as good an occasion as any to discuss them. + +### Justification + +The primary advantage of multi-server operating systems is the ability to +break what used to be the kernel into small pieces which can be isolated +from each others. This makes sense from an engineering perspective, as +smaller components can be swapped with different implementations and reduce +the impact of bugs. +A capability-based approach also ensures that the +authority wielded by components is clear and reduced to the minimum required +for them to function. +These properties are crucial to the Hurd's agenda of user freedom, +since in order to allow them to plug their own code into the system +[FIXME: développer] + +However, this flexibility has a cost. In a system where the isolation of +components relies on running them inside different address spaces, +communication between them must be done through IPC calls. +This introduces a trade-off between the size of the modules +and performance as well as practicality, +which imposes a limit to the granularity with which the system +can be decomposed and the principle of least authority applied +(to the code within a given process, a Mach port is ambient authority). + +Another issue is that of the threading structure of the system as a whole. +In systems based on a monolithic kernel, user threads execute the kernel +code themselves, which is then intrinsically concurrent. By contrast, in a +system based on a “client-server” paradigm, each server must be explicitly +multi-threaded if it is to serve requests concurrently. + +### Object-capability languages + +An object-capability language is an object-oriented language which is +restricted enough so that object references are themselves capabilities. + +One such language is Joe-E (FIXME: lien), +which is an object-capability subset of Java: +global state and static methods are mostly forbidden; +careful white-listing of the objects and methods +provided by the Java standard library +ensures that compliant code cannot not access ambient autority. +Ways in which object references can be transferred +are restricted to the most obvious ones +(for instance, exceptions are carefully restricted). + +As a result, untrusted Joe-E code can be executed without any further +isolation and its autority can be controlled by carefully limiting the +object references which are passed to it. +This would allow to load and execute translators written in Joe-E +in a single address space. + +### Bundling translators into a single process + +[mechanisme pour transmettre le code Joe-E +et les port initiaux au serveur] +[émulation des différentes tâches] + +### Challenges and further work + +[proof-carrying code / typed assembly, +resource accounting (passer en revue la conception de Viengoos?)] + -- cgit v1.2.3 From d0c962939e6aba58465265a2202fcbbb992836f9 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 14:31:25 +0200 Subject: gsoc2011 (java): add some links --- user/jkoenig/gsoc2011_proposal.mdwn | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 666733c1..5d40a97f 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -73,11 +73,13 @@ support is important for any general-purpose operating system. Java is currently supported on Hurd with the GNU Java suite: - * GCJ, the GNU Compiler for Java, is part of GCC and can compile Java + * [GCJ](http://gcc.gnu.org/java/), + the GNU Compiler for Java, is part of GCC and can compile Java source code to Java bytecode, and both source code and bytecode to native code; - * libgcj is the implementation of the Java runtime which GCJ uses. It is - based on GNU Classpath. It includes a bytecode interpreter which enables + * libgcj is the implementation of the Java runtime which GCJ uses. + It is based on [GNU Classpath](http://www.gnu.org/software/classpath/). + It includes a bytecode interpreter which enables Java applications compiled to native code to dynamically load and execute Java bytecode from class files. * The gij command is a wrapper around the above-mentioned virtual machine @@ -134,9 +136,13 @@ natural fit for the capability-based design of Hurd. Advantages over other garbage-collected, object-oriented languages include performance, type safety and the possibility to compile a Java translator to -native code and link it statically using GCJ, should anyone want to use a -translator written in Java for booting. Note that Java is being used in this -manner for embedded development. +native code and +[link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj) +using GCJ, should anyone want to use a +translator written in Java for booting. Note that Java is +[being](http://oss.readytalk.com/avian/) +[used](http://www.linuxjournal.com/article/8757) +in this manner for embedded development. Java bindings would lower the bar for newcomers to begin experimenting with what makes Hurd unique @@ -278,6 +284,12 @@ A realistic example of code based on such interfaces would be: } } +Should this paradigm prove insufficient, +more ideas could be borrowed from the +[`org.vmmagic`](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf) +package used by [Jikes RVM](http://jikesrvm.org/), +a research Java virtual machine itself written in Java. + ### Generating Java stubs with MIG Once the basic machinery is in place to interface with Mach, Java programs @@ -293,7 +305,9 @@ complete or exempt of any problem, illustrates the general idea: [[gsoc2011_classes.png]] -This structure is somewhat reminiscent of Java RMI or similar systems, +This structure is somewhat reminiscent of +[Java RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation) +or similar systems, which aim to provide more or less transparent access to remote objects. The exact way the Java code would be generated still needs to be determined, but basically: -- cgit v1.2.3 From f339908d26851950ed204172765fd89e56e79b52 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 14:38:26 +0200 Subject: gsoc2011 (java): add a 'draft' comment at the beginning --- user/jkoenig/gsoc2011_proposal.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 5d40a97f..620ac95b 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -1,6 +1,8 @@ # Java for Hurd (and vice vera) +*[Draft] I'll finish this later today and send an email to bug-hurd when I'm done* + Contact information: * Full name: Jérémie Koenig -- cgit v1.2.3 From cf9e38dec8d9a08166cd23607cb7fedd277396f9 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Fri, 8 Apr 2011 15:32:12 +0200 Subject: GSoC PyHurd application: Ideas for translators. --- community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index 47d16f3a..8e887e41 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -29,9 +29,9 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of 3. design a pythonic high-level API for translators. 2. Realize a pythonic trivfs library and an example translator using it. 3. Mid-Term: trivfs works. Push the code to https://github.com/ArneBab/PyHurd -4. Implement more complex and specialized translator libraries, along with example translators. +4. Implement more complex and specialized translator libraries, along with example translators. This should recreate the Hurd libraries for Python. Ideally seperate the libraries, so programmes can simply import the convenience functionality they need. 5. Re-implement some hurd specific utils in pyhurd such as settrans. -6. With the remaining time, create as many cool translators as possible :) +6. With the remaining time, create as many interesting translators as possible. Ideas include all compression formats supported by Python, markdown to HTML translators to be accessed with nsmux (file.mdwn,,html), automatic version tracking directories and overlay stores which store changes to nonchanging files like squaschfs, but also simple translators like translator-based write-locking of files by not catching write-accesses. 7. Push the final code to https://github.com/ArneBab/PyHurd ## Initial Fix -- cgit v1.2.3 From 5876a9f012898f8b1e5e60f53fb8b026c8d351e9 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 15:51:55 +0200 Subject: gsoc2011 (java): split the appendix into another page --- user/jkoenig/gsoc2011_proposal.mdwn | 94 ++++--------------------------------- user/jkoenig/objcap.mdwn | 85 +++++++++++++++++++++++++++++++++ 2 files changed, 93 insertions(+), 86 deletions(-) create mode 100644 user/jkoenig/objcap.mdwn diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 620ac95b..d53c094f 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -62,6 +62,14 @@ My knowledge of the Hurd and Debian GNU/Hurd is reasonable, as the Debian-Installer and procfs projects gave me the opportunity to fiddle with many parts of the system. +Initially, +I started working on this project because I wanted to use Joe-E +(a subset of Java) +to investigate the potential +[[applications of object-capability languages|objcap]] +in a Hurd context. +I also believe that imrpoving Java support on Hurd +would be an important milestone. ## Improve Java support @@ -495,89 +503,3 @@ The dates listed are deadlines for the associated tasks. ## Conclusion - - - -## Appendix: potential applications of object-capability languages - -The work discussed is this last part would have -fewer immediate benefits for the Hurd project -and has more of a research orientation. -It is also unlikely that there would be any time remaining -to work on it at the end of the summer. -(Though it could work as some kind of reward -if I somehow managed to do a prefect job of all the rest -within the allocated time :-) ). -As a consequence, -I don't really consider this a part of my application. - -This being said, -to some extent the project discussed here -will informed the way I design the Java bindings, -since it depends on them -and I intend to work on this at some point in the future. -I also believe it touches on some interesting ideas, -and a Summer of Code application is probably -as good an occasion as any to discuss them. - -### Justification - -The primary advantage of multi-server operating systems is the ability to -break what used to be the kernel into small pieces which can be isolated -from each others. This makes sense from an engineering perspective, as -smaller components can be swapped with different implementations and reduce -the impact of bugs. -A capability-based approach also ensures that the -authority wielded by components is clear and reduced to the minimum required -for them to function. -These properties are crucial to the Hurd's agenda of user freedom, -since in order to allow them to plug their own code into the system -[FIXME: développer] - -However, this flexibility has a cost. In a system where the isolation of -components relies on running them inside different address spaces, -communication between them must be done through IPC calls. -This introduces a trade-off between the size of the modules -and performance as well as practicality, -which imposes a limit to the granularity with which the system -can be decomposed and the principle of least authority applied -(to the code within a given process, a Mach port is ambient authority). - -Another issue is that of the threading structure of the system as a whole. -In systems based on a monolithic kernel, user threads execute the kernel -code themselves, which is then intrinsically concurrent. By contrast, in a -system based on a “client-server” paradigm, each server must be explicitly -multi-threaded if it is to serve requests concurrently. - -### Object-capability languages - -An object-capability language is an object-oriented language which is -restricted enough so that object references are themselves capabilities. - -One such language is Joe-E (FIXME: lien), -which is an object-capability subset of Java: -global state and static methods are mostly forbidden; -careful white-listing of the objects and methods -provided by the Java standard library -ensures that compliant code cannot not access ambient autority. -Ways in which object references can be transferred -are restricted to the most obvious ones -(for instance, exceptions are carefully restricted). - -As a result, untrusted Joe-E code can be executed without any further -isolation and its autority can be controlled by carefully limiting the -object references which are passed to it. -This would allow to load and execute translators written in Joe-E -in a single address space. - -### Bundling translators into a single process - -[mechanisme pour transmettre le code Joe-E -et les port initiaux au serveur] -[émulation des différentes tâches] - -### Challenges and further work - -[proof-carrying code / typed assembly, -resource accounting (passer en revue la conception de Viengoos?)] - diff --git a/user/jkoenig/objcap.mdwn b/user/jkoenig/objcap.mdwn new file mode 100644 index 00000000..e4cd20e8 --- /dev/null +++ b/user/jkoenig/objcap.mdwn @@ -0,0 +1,85 @@ + +# Potential applications of object-capability languages + +The work discussed is this last part would have +fewer immediate benefits for the Hurd project +and has more of a research orientation. +It is also unlikely that there would be any time remaining +to work on it at the end of the summer. +(Though it could work as some kind of reward +if I somehow managed to do a prefect job of all the rest +within the allocated time :-) ). +As a consequence, +I don't really consider this a part of my application. + +This being said, +to some extent the project discussed here +will informed the way I design the Java bindings, +since it depends on them +and I intend to work on this at some point in the future. +I also believe it touches on some interesting ideas, +and a Summer of Code application is probably +as good an occasion as any to discuss them. + +### Justification + +The primary advantage of multi-server operating systems is the ability to +break what used to be the kernel into small pieces which can be isolated +from each others. This makes sense from an engineering perspective, as +smaller components can be swapped with different implementations and reduce +the impact of bugs. +A capability-based approach also ensures that the +authority wielded by components is clear and reduced to the minimum required +for them to function. +These properties are crucial to the Hurd's agenda of user freedom, +since in order to allow them to plug their own code into the system +[FIXME: développer] + +However, this flexibility has a cost. In a system where the isolation of +components relies on running them inside different address spaces, +communication between them must be done through IPC calls. +This introduces a trade-off between the size of the modules +and performance as well as practicality, +which imposes a limit to the granularity with which the system +can be decomposed and the principle of least authority applied +(to the code within a given process, a Mach port is ambient authority). + +Another issue is that of the threading structure of the system as a whole. +In systems based on a monolithic kernel, user threads execute the kernel +code themselves, which is then intrinsically concurrent. By contrast, in a +system based on a “client-server” paradigm, each server must be explicitly +multi-threaded if it is to serve requests concurrently. + +### Object-capability languages + +An object-capability language is an object-oriented language which is +restricted enough so that object references are themselves capabilities. + +One such language is Joe-E (FIXME: lien), +which is an object-capability subset of Java: +global state and static methods are mostly forbidden; +careful white-listing of the objects and methods +provided by the Java standard library +ensures that compliant code cannot not access ambient autority. +Ways in which object references can be transferred +are restricted to the most obvious ones +(for instance, exceptions are carefully restricted). + +As a result, untrusted Joe-E code can be executed without any further +isolation and its autority can be controlled by carefully limiting the +object references which are passed to it. +This would allow to load and execute translators written in Joe-E +in a single address space. + +### Bundling translators into a single process + +[mechanisme pour transmettre le code Joe-E +et les port initiaux au serveur] +[émulation des différentes tâches] + +### Challenges and further work + +[proof-carrying code / typed assembly, +resource accounting (passer en revue la conception de Viengoos?)] + + -- cgit v1.2.3 From 3fd06c9149344aafa928d8db454991a35cd7e875 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 16:01:42 +0200 Subject: gsoc2011 (java): add a summary --- user/jkoenig/gsoc2011_proposal.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index d53c094f..92bed1b4 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -16,6 +16,15 @@ in Computer Science at University of Strasbourg (France). My interests include capability-based security, programming languages and formal methods (in particular, proof-carrying code). +### Proposal summary + +This project would consist in improving Java support on Hurd. +The first part would consist in +fixing bugs and porting Java-related packages. +The second part would consist in +creating low-level Java bindings for the Hurd interfaces, +as well as libraries to make translator development easier. + ### Previous involvement Although I have known the Hurd for some time, -- cgit v1.2.3 From b02cb9177df853ffef97e73f98a31b4204479747 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 16:31:13 +0200 Subject: gsoc2011 (java): miscellaneous fixes --- user/jkoenig/gsoc2011_proposal.mdwn | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 92bed1b4..d9617ab5 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -14,7 +14,8 @@ Contact information: I am a first year M.Sc. student in Computer Science at University of Strasbourg (France). My interests include capability-based security, -programming languages and formal methods (in particular, proof-carrying code). +programming languages and formal methods +(in particular, object-capability languages and proof-carrying code). ### Proposal summary @@ -27,8 +28,7 @@ as well as libraries to make translator development easier. ### Previous involvement -Although I have known the Hurd for some time, -I did not contribute until last summer, +I started contributing to Hurd last summer, during which I participated to Google Summer of Code as a student for the Debian project. I worked on porting Debian-Installer to Hurd. @@ -72,14 +72,16 @@ as the Debian-Installer and procfs projects gave me the opportunity to fiddle with many parts of the system. Initially, -I started working on this project because I wanted to use Joe-E +I started working on this project because I wanted to use +[Joe-E](http://code.google.com/p/joe-e/) (a subset of Java) to investigate the potential [[applications of object-capability languages|objcap]] in a Hurd context. -I also believe that imrpoving Java support on Hurd +I also believe that improving Java support on Hurd would be an important milestone. + ## Improve Java support ### Justification @@ -87,6 +89,8 @@ would be an important milestone. Java is a popular language and platform used by many desktop and web applications (mostly on the server side). As a consequence, competitive Java support is important for any general-purpose operating system. +Better Java support would also be a prerequisite +for the second part of my proposal. ### Current situation @@ -442,8 +446,8 @@ to design and implement similar solutions for Java. ### Packaging and long-term maintenance -The Java libraries resulting from this work -(including any MIG support classes), +The Java libraries resulting from this work, +including any MIG support classes as well as the class files built from the MIG-generated code for the Mach and Hurd interface definition files, would be provided as single `hurd-java` package for -- cgit v1.2.3 From cd48e7119c3634550411daa66c3a617082d39630 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 16:31:41 +0200 Subject: gsoc2011 (java): improve the structure of the proposal --- user/jkoenig/gsoc2011_proposal.mdwn | 54 ++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 13 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index d9617ab5..e8f7679b 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -146,6 +146,14 @@ which makes some packages fail to build on Hurd proposal). Porting Eclipse would be a good opportunity to test GCJ and OpenJDK. +### Deliverables + + * The glibc pthreads patch and any other fixes on the Hurd side + would be submitted upstream + * Patches against Debian source packages + required to make them build on Hurd would be submitted + to the [Debian bug tracking system](http://bugs.debian.org/). + ## Create Java bindings for the Hurd interfaces @@ -172,7 +180,33 @@ to begin experimenting with what makes Hurd unique without being faced right away with the complexity of low-level systems programming. -### Approach +### Tasks summary + + * Implement Java bindings for Mach + * Implement a libports-like library for Java + * Modify MIG to output Java code + * Implement libfoofs-like Java libraries + +### Design principles + +The principles I would use to guide the design +of these Java bindings would be the following ones: + * The system should be hooked into at a low level, + to ensure that Java is a "first class citizen" + as far as the access to the Hurd's interfaces is concerned. + * At the same time, the memory safety of Java should be maintained + and extended to Mach primitives such as port names and + out-of-line memory regions. + * Higher-level interfaces should be provided as well + in order to make translator development + as easy as possible. + * A minimum amount of JNI code (ie. C code) should be used. + Most of the system should be built using Java itself + on top of a few low-level primitives. + * Hurd objects would map to Java objects. + * Using the same interfaces, + objects corresponding to local ports would be accessed directly, + and remote objects would be accessed over IPC. One approach used previously to interface programming languages with the Hurd has been to create bindings for helper libraries such as libtrivfs. Instead, @@ -186,17 +220,6 @@ 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. -### Design goals - -FIXME: a completer - - * Give maximum flexibility to the Java code while maintaining the memory - safety of Java, and using a minimum amount of C code. - * Provide higher-level interfaces as well, ... - * Hurd objects would map to Java objects. - * Local objects can be accessed directly, - remote objects can be accessed transparently over IPC. - ### Bindings for Mach system calls In this low-level approach, my intention is to enable Java code to use Mach @@ -444,7 +467,12 @@ to implement the required ones. I would draw inspiration from libtrivfs and libnetfs to design and implement similar solutions for Java. -### Packaging and long-term maintenance +### Deliverables + + * A hurd-java package would contain the Java code developped + in the context of this project. + * Modifications to MIG would be submitted upstream, + or a patched MIG package would be made available. The Java libraries resulting from this work, including any MIG support classes -- cgit v1.2.3 From ba3c75a2496401fc189006db19ea75fede28907d Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 17:45:01 +0200 Subject: gsoc2011 (java): random improvements --- user/jkoenig/gsoc2011_proposal.mdwn | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index e8f7679b..7179ff87 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -171,8 +171,8 @@ native code and [link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj) using GCJ, should anyone want to use a translator written in Java for booting. Note that Java is -[being](http://oss.readytalk.com/avian/) -[used](http://www.linuxjournal.com/article/8757) +[being](http://www.linuxjournal.com/article/8757) +[used](http://oss.readytalk.com/avian/) in this manner for embedded development. Java bindings would lower the bar for newcomers @@ -471,6 +471,8 @@ to design and implement similar solutions for Java. * A hurd-java package would contain the Java code developped 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. * Modifications to MIG would be submitted upstream, or a patched MIG package would be made available. @@ -519,27 +521,28 @@ The dates listed are deadlines for the associated tasks. Finish implementing pthread signal semantics. * *June 5.* Port OpenJDK - * *June 19 (two weeks).* + * *June 12.* Fix the remaining problems with GCJ and/or OpenJDK, possibly port Eclipse or other big Java packages. - * *June 26.* + * *June 19.* Create the bindings for Mach. - * *July 3.* + * *June 26.* Work on some kind of basic Java libports to handle receive rights. - * *July 10.* + * *July 3.* Test, write some documentation and examples. - * *July 24 (two weeks).* + * *July 17 (two weeks).* Add the Java target to MIG. - * *July 31.* + * *July 24.* Test, write some documentation and examples. - * *August 7.* + * *August 7 (two weeks).* + Implement a modular libfoofs to help with translator development. Try to write a basic but non-trivial translator to evaluate the performance and ease of use of the result, rectify any rough edges this would uncover. - * *Last two weeks.* - Polish the code, - do the packaging. + * *August 22. (last two weeks)* + Polish the code and packaging, + finish writing the documentation. ## Conclusion -- cgit v1.2.3 From 31044d5cfa4f861f510fc0fe130f5a82fae48b6a Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 17:45:08 +0200 Subject: gsoc2011 (java): conclusion --- user/jkoenig/gsoc2011_proposal.mdwn | 47 +++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 7179ff87..5e5d2735 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -547,3 +547,50 @@ The dates listed are deadlines for the associated tasks. ## Conclusion +This project is arguably ambitious. +However, I have been thinking about it for some time now +and I'm confident I would be able to accomplish most of it. + +In the event multiple language bindings projects +would be accepted, +some work could probably be done in common. +In particular, +[ArneBab](http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/2011-04-06-application-pyhurd/) +seems to favor a low-level approach for his Python bindings as I do for Java, +and I would be happy to discuss API design and coordinate MIG changes with him. +I would also have an extra month after the end of the GSoC period +before I go back to school, +which I would be able to use to finish the project +if there is some remaining work. +(Last year's rewrite of procfs was done during this period.) + +As for the project's benefits, +I believe that good support for Java +is a must-have for the Hurd. +Java bindings would also further the Hurd's agenda +of user freedom by extending this freedom to more people: +I expect the set of developers +who would be able to write Java code against a well-written libfoofs +is much larger than +those who master the intricacies of low-level systems C programming. +From a more strategic point of view, +this would also help recruit new contributors +by providing an easier path to learning the inner workings of the Hurd. + +Further developments +which would build on the results of this project +include my planned [[experiment with Joe-E|objcap]] +(which I would possibly take on as a university project next year). +Another possibility would be to reimplement some parts +of the Java standard library +directly in terms of the Hurd interfaces +instead of using the POSIX ones through glibc. +This would possibly improve the performance +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. +I hope that you will share this sentiment +and give me the opportunity to spend another summer working on Hurd. + -- cgit v1.2.3 From 67c45ea1f4eef284234d69ffad5fd7548f289a84 Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 18:02:47 +0200 Subject: gsoc2011 (java): add answers to the remaining question from the template --- user/jkoenig/gsoc2011_proposal.mdwn | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 5e5d2735..fe05e2c0 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -81,6 +81,28 @@ in a Hurd context. I also believe that improving Java support on Hurd would be an important milestone. +### Organisational matters + +I am subscribed to bug-hurd@g.o and +I do have a permanent internet connexion. + +I would be able to attend the regular IRC meetings, +and otherwise communicate with my mentor +through any means they would prefer +(though I expect email and IRC would be the most practical). +Since I'm already familiar with the Hurd, +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, +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. + +I don't have any other plans for the summer +and would not make any if my project were to be accepted. + ## Improve Java support -- cgit v1.2.3 From cd0c5d6044001a248c522b55c637a8610567644d Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 18:06:30 +0200 Subject: gsoc2011 (java): fix --- user/jkoenig/gsoc2011_proposal.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index fe05e2c0..d746aa4e 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -309,7 +309,8 @@ examples: operations should be provided by the `Syscall` class instead. Finally, access should be provided to the initial ports and file descriptors -in `_hurd_ports` and `FIXME`, for instance through static methods such as +in `_hurd_ports` and provided by the `getdport()` function, +for instance through static methods such as `getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as `org.gnu.hurd.InitPorts`. -- cgit v1.2.3 From ffc40b2f72fa1a44f492122d50678af0cfbf9b7f Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 18:39:21 +0200 Subject: gsoc2011 (java): mention alternative JVM languages --- user/jkoenig/gsoc2011_proposal.mdwn | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index d746aa4e..b5932006 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -181,21 +181,26 @@ which makes some packages fail to build on Hurd ### Justification -Java is a popular language, used for many applications and often taught to +Java is used for many applications and often taught to introduce object-oriented programming. The fact that Java is a garbage-collected language makes it easier to use, especially for the less -experienced programmers. Besides, the object-oriented nature of Java is a +experienced programmers. Besides, its object-oriented nature is a natural fit for the capability-based design of Hurd. +The JVM is also used as a target for many other languages, +all of which would benefit from the access provided by these bindings. Advantages over other garbage-collected, object-oriented languages include performance, type safety and the possibility to compile a Java translator to native code and [link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj) using GCJ, should anyone want to use a -translator written in Java for booting. Note that Java is +translator written in Java for booting. +Note that Java is [being](http://www.linuxjournal.com/article/8757) [used](http://oss.readytalk.com/avian/) in this manner for embedded development. +Since GCJ can take bytecode as its input, +this expect this possibility would apply to any JVM-based language. Java bindings would lower the bar for newcomers to begin experimenting with what makes Hurd unique -- cgit v1.2.3 From 7d86797cb4decbcbf612651e0ad98d1088e9b91d Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 18:48:50 +0200 Subject: gsoc2011 (java): spell-checking --- user/jkoenig/gsoc2011_proposal.mdwn | 38 ++++++++++++++++++------------------- 1 file 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. -- cgit v1.2.3 From 6712fac46834ed661d34b3df37e1f6b18b226b8c Mon Sep 17 00:00:00 2001 From: Jeremie Koenig Date: Fri, 8 Apr 2011 20:16:46 +0200 Subject: gsoc2011 (java): last touch --- user/jkoenig/gsoc2011_proposal.mdwn | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index 46ebf945..eeaa5aaa 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -1,8 +1,6 @@ # Java for Hurd (and vice versa) -*[Draft] I'll finish this later today and send an email to bug-hurd when I'm done* - Contact information: * Full name: Jérémie Koenig @@ -103,6 +101,11 @@ and my waking hours would be flexible. I don't have any other plans for the summer and would not make any if my project were to be accepted. +Full disclosure: +I also submitted a proposal to the Jikes RVM project +(which is a research-oriented Java Virtual Machine, +itself written in Java) +for implementing a new garbage collector into the MMTk subsystem. ## Improve Java support -- cgit v1.2.3