On 9/18/07, Bruce <[EMAIL PROTECTED]> wrote: > Everything here that is directly related to coding, will get made into tasks > based on the input that is provided, so that the group can function once > more, now that the long outage of the trunk kernel being near useless, is > over. Hurray for Chriss fixing it! (Did everyone poke xfury enough? > Remember, we still need him, so don't poke him too hard. ;-P ) (For the > record, I attempted to fix the kernel, and completely skipped over what > ended up being the culprit. Thats what *I* get for being sloppy...)
What!? The kernel is no longer broken? This is news to me. I guess Chriss has a new AOT commit? > Kernel Bugs > It appears that somewhere between Foundation.Convert.ToString(...) and > TextMode.Write(int), that integers are being printed in reverse. Hahaha! Chriss used a very mystical (to me) algorithm for doing that, I tried to transition it into the Convert class but perhaps I got it wrong. > for the timer display they are. (I have no way of telling, when it comes to > the memory addresses, but since the code paths meet at TextMode.Write(int), > I believe they are affected as well.) All the loops appear to be going in > the right direction, but it prints the digits backwards, and it adds a > couple zeroes to the front (of the end result). Obviously, I can reverse the > printing loop, and it prints mostly correctly, with the exception of the > mysterious trailing 0's (always two, no matter how big the number seems to > get.) > > KeyMap functionality is still not in a functioning state. Hopefully xfury > will take a peek, *wink wink*, and if not, I'll look into it eventually, > though I can't promise anything because I'll basically have to read through > every piece of code that he has written that centers around that > functionality. If we can't get it working soon, we will have to hard-code > US-101 into the kernel, as actual C# code, so that we can temporarily bypass > the issue, and proceed forward with other things, like console support. I will, but I've been distracted with a commercial project I'm doing. Hopefully soon I'll have that code ready so I can sit down and get back to some SharpOS goodness. Bypassing it would be an excellent idea for now. > xfury has informed us that paging doesn't work, and that it is disabled for > now. We can avoid it for now. I think its a safely avoided issue for now. > Anyone that wants to take a look is most welcome to. Please do. I don't like paging. Luckily we can work on memory management without a real paging implementation, just leaving paging off and forgoing memory mapping. > One of the issues involved with this has to do with garbage collection. I > believe some preliminary work has been done on this, but nothing has been > suitable for integration into the trunk, as of yet. I think, that we might > be able to set up a low-level kernel system that uses a timer to make the > sweeps, but most of the GC algorithm stuff is currently beyond me, so I'd > prefer not to touch it myself... I wrote a garbage collector that should work fine. It might already be in the trunk. If not, its in my sandbox. It's as functional as I could get it without a kernel to run it in :). > Chriss has done some amazing work at simplifying the AOT, but there is only > so much that can be done. If you want to help out with this, then you need > to get the code from SVN, and start spamming Chriss with e-mails with AOT > questions. Be heard! Get involved! Can't wait to see the new code. > Food For Thought > With runtime bindings, console support, and preliminary korlib - we should > be able to look at integrating xfury's command-line shell, "nash". (I hope > he didn't use anything that the AOT can't AOT, or it might be a year or more > before we can seriously consider this...) Nash is such a gem. It's raw still, but the allure of BASHy goodness integrated with .NET reflection is strong. Oh, and it uses only 2.0 corlib stuff and Mono.GetOptions. However, it could potentially use any DLLs as Nash is meant to run in user space (ie: not AOTed).... > Other potential side-projects, more or less useful to SharpOS at present > time: > * there has been experimentation with a Window system, SharpWS. I haven't > personally looked at it, it hasn't been discussed group-wide, so I don't > think we can call it an "official" SharpOS pursuit, but I'm definitely > excited that the preliminary work has been done. If it picks up momentum, it > may manage to get done before the rest of SharpOS is ready for it, and we > will be good to go when we are. Hit xfury up for more information. Discuss away. Most of what has been done is boilerplate, going at it from a client/server perspective (a la X11). > * Before we start talking about full-grown graphics, we will definitely need > some text-based UI action. There have been a few attempts to wrap up > ncurses. I don't think there is a fully managed version. Anyone that can > hack something together for SharpOS will help us along a good ways. Indeed. > * Drivers - anyone that wants to draft up some documentation on a potential > driver abstraction layer and architecture, start talking about it now. The > sooner we can define a model for drivers, the sooner we can start working on > them. (If you expect pretty SharpOS GUI action, this is where you need to > start...) > * nash will be great, but we won't be a good open-source OS unless we have > 50 million different shells. Discussion and experimentation with other > options is most welcome. (IronPython shell? PowerShell port?) You could > easily go off on a completely non-SharpOS tangent (and be busy for a *long* > time) with some of these ideas, and still help us out. This isn't all about > x86 and hardware interrupts... In fact, there was another person working on a Monad-clone. Could we get that code into the sandbox as well, so we can have shell choices by the time the kernel is ready? not everyone loves BASH with the passion I do, you know. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
