[[!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]]."]]"""]] Some [[tschwinge]] comments regarding your proposal. Which is very good, if I may say so again! :-) Of course, everyone is invited to contribute here! I want to give the following methodology a try, instead of only having email/IRC discussions -- for the latter are again and again showing a tendency to be dumped and deposited into their respective archives, and be forgotten there. Of course, email/IRC discussions have their usefulness too, so we're not going to replace them totally. For example, for conducting discussions with a bunch of people (who may not even be following these pages here), email (or, as applicable, the even more interactive IRC) will still be the medium of choice. (And then, the executive summary should be posted here, or incorporated into your proposal.) Also, if you disagree with this suggested procedure right away, or at some later point begin to feel that this thing doesn't work out, or simply takes too much time (I don't think so: writing emails takes time, too), just say so, and we can reconsider. Of course, as this wiki is a passive medium rather than an active one as IRC and email are, it is fine to send notices like: *I have updated the wiki page, please have a look*. One idea is that your proposal evolves alongside with the ongoing work, and represents (in more or less detail) what has been done and what will be done. Also, we can hopefully use parts of it for documentation purposes, or as recipes for similar work (enabling other programming languages on the Hurd, for example). For this, I suggest the following procedure: as applicable, you can either address any comments in here (for example, if they're wrong :-), or if they require further discussion; think: *email discussion*), or you can address them directly in your propoal and remove the comments from here at the same time (think: *bug fix*). Generally, you can assume that for things I didn't comment on (within some reasonable timeframe/upon asking me again) that I'm fine with them. Otherwise, I might say: *I don't like this as is, but I'll need more time to think about it.* There is also a possibility that parts of your proposal will be split off; in cases where we think they're valuable to follow, but not at this time. (As you know, your proposal is not really a trivial one, so it may just be too much for one person's summer.) Such bits could be moved to [[open_issues]] pages, either new ones or existing ones, as applicable. # POSIX Threads Signal Semantics * Great! [[tschwinge]] had a brief look, and should have a deeper one. * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this (that is, only the refactoring patches for starters?) on the buildds. * Then: should ask Roland to review. * Documentations bits should probably be moved to [[glibc/signal]]. ## libthreads (cthreads) Integration * [[tschwinge]] suggests to leave them as-is? ## [[libpthread]] integration * To be done. # Java * [[tschwinge]] has to read about RMI and CORBA. # Joe-E * For later. # GCJ * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly dead? (True?) * Thus perhaps not too much effort should be spent with it. If the POSIX threads signal semantics makes it going, then great, otherwise we should get a feeling what else is missing. # OpenJDK * All in all, [[tschwinge]] has the feeling that a working OpenJDK will be more useful/powerful than GCJ. * We need to get a feeling how difficult such an OS port will be. * [[jkoenig]] suggests OpenJDK 6 -- should we directly go for version 7 instead? * What are the differences (regarding the OS port) between the two versions? Or this there something even more recent to be worked upon, for new OS ports? * Perhaps the different versions' OS port specific stuff is not at all very different, so that both v6 and v7 could be done? * They seem to have a rather heavy-weight process for such projects: confer , for example. Do we need this, too? # Eclipse OK for testing -- but I'd very much hope that it *just works* as soon as we provide the required Java platform. # Java Bindings ## Design Principles * Generally ack. ### MIG * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult. * (Unless you want to make MIG's own code (that is, not the generated code, but MIG itself) look a bit more nice, too.) ;-) * There are also alternatives to MIG. If there is interest, the following could be considered: * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if there would be any benefits over MIG, like better modularity (for the backends)? If we feel like it, we could spend a little bit of time on this. * For [[microkernel/Viengoos]], Neal has written a RPC stub generator entirely in C Preprocessor macros. While this is obviously not directly applicable, perhaps we can get some ideas from it. * Anything else that would be worth having a look at? (What are other microkernels using?) ### `mach_msg` * Seems like the right approach to [[tschwinge]], but hasn't digested all the pecularities yet. Will definitely need more time. # GSoC Site Discussion * Discussion items from should be copied here: * technical bits (obviously); * also the *why do we want Java bindings* reasoning; * CLISP findings should also be documented somewhere permanently. * We should probaby open up a *languages for Hurd* section on the web pages ([[!taglink open_issue_documentation]]).