On Nov 29, 2007 4:56 AM, Bruce Markham <[EMAIL PROTECTED]> wrote:
> Hey folks:
>
> Aside from the runtime stuff, I've also been entertaining myself by working
> on the demo shell. (Though nash looks great, it requires EDC which is post
> of our 0.0.1 milestone guidelines.) I'm basically just writing a system that
> uses simple string comparison against a sorted linked-list of structures
> containing function pointers to functions that do each command's execution.
Yeah Nash was never intended to work as the shell inside of the
kernel. However, it is one hell of a shell so far, thanks to the work
I did over Thanksgiving.
> Its a mouthful, but its the only way we can really do it at this point. I'm
> keeping it structured and hierarchical, so it shouldn't be hard for someone
> to dig in and add commands, after I've finished the basics and moved it into
> the trunk. The only awkward change I have to do is I'm going to have to
> modify our console code to start buffering entered lines of text, and to
> call out to the shell code when a line is completed. (If anyone has any
> suggestions, let me know.)
Buffering is a requirement under almost any circumstances.
>
> I've run into a few repo/code issues/questions though, that I'd like to
> bring up...
>
> Asgeir:
> In /trunk/Kernel/Core/, MemoryManager.cs appears to be some sort of
> duplication of /ADC/MemoryManager.cs . It appears that the former uses
> PageAllocator, whereas the latter does not. And the former is incomplete.
> What's the status here? I've been writing my code against the MemoryManager
> in /ADC, but the type name ambiguity is causing some issues. Are these going
> to be merged at some point?
>
> xfury:
> 1) Can we take the mono corlib out of /trunk/Kernel/ for now? After all,
> we'll still have it in /upstream/. There have been a couple complaints about
> running an 'svn update' and having fifty million corlibs to download. ;-(
> We also might want to consider a request of anyone with inactive sandboxes
> with copies of the corlib in them, to let us remove such.
> 2) In my work on the demo shell, I'm going to have to gut your
> /Foundation/StringBuilder.cs a bit, because I think I can make it more
> dynamic using ADC.MemoryManager.Alloc(). And I'm having the strange urge to
> rename the methods from "Add" to "Append", to help make it more identical to
> .NET's version.... If you have any thoughts or objections, let me know.
Sure you can take it out if you want, but the idea is to _not_ modify
the /upstream copy, and instead to modify the Kernel branch, so that
we can merge in the upstream changes into our copy. But I haven't been
following further developments in our mscorlib plan as closely as I
should.
> Sander:
> You've indicated in /trunk/Kernel/Core/Console.cs that the switch() { }
> statement isn't working as expected. (From reading the repo logs, I believe
> it was you that commented the switch syntax out and put in a bunch of ifs.)
> Has this been a documented AOT issue that we need to fix or write a test
> for? Has this been resolved already by DarxKies or someone else?
I have also had trouble with switch in the past.
--
fury
long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
