Here are the revised meeting notes that I took during our meeting on Saturday. It was a very long meeting (about six hours) but we discussed many important issues. The full log for the meeting is available in the Sharpbot logs at:
http://sharpos.org/logs/?channel=sharpos&date=2008.4.12 I've got both a basic outline and a narrative summary. * New meeting scheme - Two meeting sessions both on Saturday is best to avoid conflicts - 1800 GMT and 2200 GMT * Logging/Sharpbot - Create Redmine project for issue tracking - Bot improvements * Michael Ruck (grover) volunteers * distributed features - Use freenode nick system as a locking mechanism - We will have nodes which fill the gaps when the bot is not available * Me, Bruce (illuminus), Michael (grover), and Stanislow (viraptor) volunteer to host such nodes * profiling * improve sync security so more nodes are possible - Other cool features * Code search (possible from ROS bot) * AI-based personality code * Coding style - Tab size? * Up to now we've used size 8 tabs (as Mono's guidelines suggest). * Size 4 tabs is more desirable for our code base * using space alignment while breaking long lines is accepable - Max character limit * 120 is reasonable for average font sizes on 1024x768. - Member naming * public CamelCase, protected CamelCase, private [_]camelCase * Possibly vote for _ vs lowerCamelCase for private members * Use 'this.' if you do not prefix with '_' * Moderately descriptive variable names, don't overdo it * Short 'i' and 'a' names for loop-related variables only, and better names when the loop is very large - Space before parentheses / brackets? * Vote is necessary - Opening bracket on next line for long class interface definitions - Vote on next line bracket for all class definitions * Lint/gendarme integration - Need to clean up current code base first (xfury will handle) - Codebase already has fxcop rules and files. - Integration of gendarme into nant build files via 'nant gendarme' or similar - fxcop via CI (continuous integration) (CC.net) * Volunteers/discussion? (for some much needed projects) - Documentation and Design: in-code documentation, code review, howtos, technical documents, redesigns, etc * Adam (bigfootag) volunteers to lead documentation efforts * z98 is currently documenting exception handling * Documentation efforts should be coordinated in the wiki * We want to create an overview document of the architecture which explains as much of the inherent SharpOS knowledge as possible to make it easier for new developers to understand the rationale - Testcases: more IL, AOT and kernel testcases, unification of the testcase system, * Darxkies volunteers to unify the testcases * Still missing support for shutdown after testcases? - AOT refactoring for JIT (grover) * True compilation pipe * Optimizations * Dump Cecil for a custom reader? - Jon from Ensemble wants to share his IL reader - Grover says he's got a custom IL reader which will work as well * Sharing infrastructure with Ensemble/Cosmos - Licensing * Still controversial - Shared code / interfaces * Common SF project to organize such initiatives? - Community * A common website for news, discussions, and the like * Common mailing list * Name ideas: - MOSIS: Managed Operating System Interface Standard - MOSA: Managed operating system alliance - Knexus: Community for * Brief on current projects from developers (as time and developer availability permits) - Memory management / virtual memory (Z98) * The way is clear if we use one memory space - <1G reserved for kernel + cached/block allocations - >1G for GC pages * More than one memory space is unclear - Use shared spaces to facilitate IPC and IO - Use separate spaces with traditional IPC models using remoting * And it is not clear which of the models is most beneficial - Driver System - VFS/Filesystem - AOT/Generics/JIT - GC * Mini meetings - Larger discussions offloaded to smaller meetings - Planned for the week at the weekly meeting - A set of "slots" (maybe three) per week that each discussion fits into - END - Not reached: * Discussion: Driver Interfaces, ideas, models, methods to ensure code safety efficiently, etc. ---- MEETING SCHEDULE We decided to pick a two-session meeting model for next Saturday to allow better flexibility for our world of developers. We decided that having both sessions on Saturday was the best way to avoid schedule conflicts. The meeting sessions are close enough so that it is might be possible to attend both. They are four hours apart which sets a natural time limit on the meeting time (the last meeting was about 6 hours long, although there were many topics built up). The first session will be at 1800 GMT like the last one, and we will have the second session at 2200 GMT. As it looks so far, I will chair the first one and Michael Ruck has volunteered to handle the second one. The agenda will be chosen over the course of the week. I will start a thread to poll for topics. LOGGING / SHARPBOT We decided to set up a Redmine project for the bot to track bugs and set goals (more or less integrate it as a part of the project to promote awareness and contribution to it). Michael Ruck has volunteered to coordinate improvement of the bot, including adding some distributed features which will help us build a network of sharpbot hosts to improve log coverage for the channel. Such features will probably use the IRC/freenode nick system as a locking mechanism to ensure that only one bot is in control of the logs. We will also need to harden the security of the log synchronization code / server code. It may be possible to reduce the amount of trust necessary to run a sharpbot node. Me (xfury), Bruce (illuminus), Michael (grover), and Stanislow (viraptor) offered to host nodes in the sharpbot network. CODING STYLE GUIDELINES We voted on a number of changes to our coding style guidelines and found a few more issues which will need to be discussed and voted on in the mailing list to make any kind of informed decision. We agreed that size 8 tab characters were rather large for the amount of nesting that can become necessary for this work. Many popular C# IDEs use size 4 tabs by default as well. We also agreed that it is acceptable to use space alignment for breaking long if() statements, function calls, function definitions, etc. We also examined the case for establishing a new max character limit, replacing the Mono guidelines value of 80 characters per line. We established 120 as a sensible value based on average font sizes on a 1024x768 screen. As for member naming, we established a common naming model of CLS for public/protected fields and all properties, and lowerCamelCase for private fields with an optional underscore ("_") as a prefix. Local variables should be lowerCamelCase and should not include underscores. If the private field is NOT prefixed with an underscore, always use "this." before it to denote that the identifier is a field. Aim for moderately descriptive variable names, but not TOO descriptive, and do not use single-letter names like 'a' or 'i' except for as loop variables, and only in loops which do not span more than a span on your page (as a rule of thumb). It is also acceptable to move the opening bracket for a class to the next line if the base class/interface list must be broken into two or more lines. Topics of discussion which remain in the realm of coding style guidelines: whether to keep the spaces before parantheses and brackets and whether to require the opening curly bracket of a class be put on the next line. FXCOP/GENDARME INTEGRATION This topic was added as an offshoot of the coding style guidelines discussion. To improve our code quality we endeavoured to discuss integration of lint tools like gendarme into the repository. It was noted that we already have fxcop build files and an 'fxcop' build rule for nant. Before we can improve lint tool integration in our code base, we will need to clean up the warnings which are emitted by csc/mcs during the SharpOS build cycle. I (xfury) volunteered to work towards cleaning up these warnings and improving the gendarme integration once that is finished. There was also a strong interest in integrating fxcop runs in with the CruiseControl.net service which Phil has been providing for SharpOS. MUCH-NEEDED PROJECTS Documentation & Design Adam Stevenson (bigfootag) volunteered to head our documentation efforts. He is currently working on a design for a new garbage collector. Zach Gorden (z98) has been working on documentation of exception handling. We decided to coordinate the effort via the wiki as the most logical choice (as opposed to revision control with SVN). As one of the primary goals of the effort, we'd like to create an technical overview document describing SharpOS. With this effort we hope to decrease the learning curve that exists for new developers interested in contributing to SharpOS. Redmine Upgrade It is rumored that a new Redmine release is on the way. Mircea Cristian Racasan (darxkies) plans to upgrade us to the new version when it becomes available. Testcase Unification Chriss (darxkies) volunteered to work on the testcase unification which has eluded us for quite some time now. We still need to finish shutdown support so the 'nant test' run can shutdown after running the tests without user interaction. Delegates We discussed some of the technical obstacles toward finishing delegate support (which are few) but no one volunteered to complete delegate support (at least immediately: Sander van Rossen (logicalerror) said he would work on it when he gets time if it isn't already done by then). JIT Refactoring Michael Ruck introduced some thoughts on the JIT refactoring process which is now becoming the focus of the AOT development. He wants to generalize the compilation pipe so that individual stages can be included or removed for different scenarios. We touched upon the topic of dumping Mono.Cecil for a quicker reader in the JIT use case. I (xfury) mentioned that Jonathon Dickinson (from the Ensemble project) has offered to share his custom IL reader implementation. Michael also offered one which he has implemented. SHARED INFRASTRUCTURE / COMMUNITY with OTHER MANAGED OS PROJECTS We wanted to work on finding suitable ways to contribute to the Managed OS community which is forming around the SharpOS, Ensemble, and Cosmos projects. There is no neutral forum where we can exchange ideas and news, or discuss interface standards/shared code initiatives. We worked this out to a two-entity idea: a community website, and a shared code project with a mailing list. We also discussed more possible licensing deviations, albeit with little headway into finding a compromise for sharing code with the other projects. Michael Ruck and I volunteered to head development of this endeavor, and we are now working on starting talks with the other projects towards forging a neutral community ground where we can discuss the website and code project ideas. Some of the name ideas we ran across: "MOSIS: Managed Operating System Interface Standard", "MOSA: Managed Operating System Alliance", "Knexus". Just ideas. BRIEF ON CURRENT PROJECTS Memory Management Design Zach discussed some current thoughts about the memory management design. The issue quickly became which memory model we would seek: a single memory space for all code, shared spaces where there is more than one process in a memory space, or individual spaces using overhead-less kernel calls and kernel-channel/remoting based IPC. A common perception of the single memory space scenario is that the kernel core would reserve the first gigabyte of virtual memory for itself and it's memory allocations. The kernel core GC and process-specific data would be found above the 1G mark. It is not yet clear which model we should follow. VFS/Filesystem Michael (grover) and Phil Garcia (tgiphil) discussed the VFS/Filesystem/Block developments. Individually, the filesystem and VFS code is coming along well. Now they are being connected, but progress in this area is currently somewhat limited due to lack of completed string support in the AOT, and the lack of System.Stream support in the current kernel. AOT/Generics/JIT Chriss (darxkies) talked about the completion of generics and expressed that the AOT development is now headed toward the JIT refactoring part of development. Only one generics testcase is failing due to a virtual methods issue. GC Adam (bigfootag) briefed us on the progress of his GC work. We discussed stack tracing, whether to use registers as roots, possible resources for designing thread-safe non-halting collection. AOT backend plugin for GPUs Michael (grover) briefed us on a backend for the AOT that he is interested in building. It would target graphics processing units (GPUs). The AOT would need to be modified to take into account the notion of "profiles", each of which would have an allowed subset of CIL. In this way, code streams can be verified to be of a profile which can run on a GPU, etc. This design could be expanded for other subprocessors in the future. MINI-MEETINGS It was suggested to allow the more detailed, long discussions to be offloaded from the main meetings to separate public discussions, where the time could be unmonitored and an agenda would not be necessary. We decided to pick the discussions which would occur during a given week at the weekly meeting. We would decide on a number of slots on different days of the week (Tuesday, Wednesday, Thursday?). The details of the 'discussion' slots will be discussed at the next meeting. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
