sharpos-developers

Re: [SharpOS Developers] MOSA / AOT

[grover <sh...@mi...>]

Hi Bruce,

The MOSA Forum is at mosa.ensemble-os.org, its SVN is at  
svn.mosa.ensemble-os.org (thanks Scott!).

There are currently members from JNode, Cosmos, Ensemble and SharpOS  
registered with the board. The discussions have flattened a bit there,  
but I still think the effort is "live". Ensemble is pretty much  
committed to using/working with MOSA as they're basically waiting for  
the compiler. However Scott is reserved due to SharpOS/Ensemble  
architecture differences, which I think can be resolved though. If we  
define proper interfaces and make all operating system "algorithms"  
pluggable, we'll get this done and we'll get another point: We're  
getting interesting from a research perspective. (Hi Adam!) A lot of  
progress JikesRVM has made the past years is due to research  
contributions - we have to get there to stay alive.

I know compiler writing is viewed as black art, however a proper  
design deals with a lot of things without black art. If you take a  
look at my work you'll certainly find that it has a lot of pieces to  
it, but they're cleanly seperated and easy to replace (research!) and  
it will move us forward IMO.

Mike

Am 04.08.2008 um 02:46 schrieb Bruce Markham:

> The SharpOS AOT is a fantastic machine. And if Chriss is still out  
> there listening - you have our deepest thanks for jump-starting the  
> project with it.
>
> However, I am in also in agreement with Phil and Mike, in that,  
> right now, there is no maintenance on it - I believe that unsaid  
> sentiment is that it simply isn't maintainable. Everyone here wants  
> to write kernel code. Or user level code. The AOT is the means to an  
> end - and several people now (through grover's MOSA efforts,  
> Ensemble, and Cosmos), have proven the basic ability to compile IL  
> to x86 is not particularly difficult. (Time consuming to implement,  
> sure. But there is more than enough documentation out there, and  
> previous works, to make a basic functionality work.)
>
> The problem is, no one can take it that step forward. We need  
> reflection, we need dynamic runtime bindings, and we need it to be  
> self-hosting. Whether or not an AOT is re-written, or the current  
> one is re-purposed - we still face the issue of *how* to bind the  
> kernel code to the AOT.
>
> All of our efforts as a whole, need to address this issue first and  
> foremost. The good news is, if we can agree - it doesn't matter  
> whose AOT to work we decide to extend in that direction. Any single  
> one could be the solution to getting us to the next step. Just like  
> there are standards for how C compilers and C# compilers and such  
> work - if we can define a standard on how we want the AOT to handle  
> a kernel - and then all agree to step forward with that - we can  
> benefit as a group.
>
> And *then*, we can start talking about driver architectures and code  
> sharing. *shudder*. (I think a "common kernel" is out of the  
> question, because of licensing decisions as well as varying schools  
> of thought around here. But at least a common API means we don't  
> have to share core implementation code.)
>
> Furthermore, I would like to assert that we not overlook JNode. MOSA  
> right now may just have a couple C# OS projects in it - but JNode  
> has us beat on the proof-of-concept managed operating system goal.  
> With the proper allocation of design efforts, we can create a set of  
> standards that does not preclude using IKVM, in combination with  
> whatever AOT a C# OS project is using, in order to run JNode driver  
> binaries. It bypasses alot of design and implementation work in  
> order to get us all into common ground. Without common ground, we  
> cannot refer to ourselves as seperate projects divergent from some  
> mystical original ideal. C# is not an ideal. Its a tool. And the  
> managed bit, well, its already been done. If we are looking to  
> innovate, we need a jump-start. And then we can talk about re-writes  
> and branches and optimizations down the road.
>
> I don't think there has been any official talks between SharpOS and  
> JNode. SharpOS + Ensemble + Cosmos relations are slippery at best.  
> The C# crowd - all of us - need to get our acts and heads together,  
> under MOSA, (not sure if Cosmos is still viable, much less,  
> interested in MOSA, but still). With that done, collectively, we  
> need to rise up to meet JNode, and extend a hand of friendship.
>
> So, if someone could re-post the information on MOSA (wasn't there a  
> discussion group or something somewhere?), I would be grateful. We  
> need start some topics of conversation at a centralized, non-biased  
> location. See if we can crack our skulls together to get an idea of  
> where to proceed.
>
> But I agree. We will either work together or die together. There are  
> too few interested and available developers right now for it to be  
> any other way. And if we allow ourselves to fizzle, we will pollute  
> the water for future generations that get curious regarding this  
> idea...
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers

Re: [SharpOS Developers] Trunk Status Inquiry

[Phil G. <ph...@th...>]

Hi! Thanks for bring this up.

I have been tinkering a lot with a device drivers architecture. See my
e-mail July 24's email entitled Device Drivers & Attributes for some recent
discussion. I have been working on both SharpOS and Ensemble projects. Sharp
is a bottom up design, while Ensemble is a top down design. I will not go
into the pros and cons of each design and implement approached - both have
merits. However, my work at Ensemble is better - but I have been unable to
port it back to SharpOS since the AOT is missing some language
implementations and still has some serious bugs. To be frank, I'm given up
the port due to AOT's limitations until Mike's MOSA compiler is ready.
My personal goal is to include a basic device driver framework and some
drivers included in the MOSA project.
In regards to Redmine, I have a Unix and Linux background - but no
experience with Redmine itself. I had hoped someone with more experience
would volunteer and tackle Redmine's stability issues. (Although, I'm
thinking about trying Redmine on Windows for fun).

-Phil


On Sun, Aug 3, 2008 at 6:13 PM, Bruce Markham <ill...@gm...> wrote:

> Due to the lack of regularly scheduled development on the project, combined
> with the fact that there has still been development, I was hoping that a few
> of the people involved with changes in the trunk could put together
> summaries of what they have been working on for the last several months.
>
> The majority of commits have been done by tgiphil - and some of those are
> larger than they appear because they are merges from sandboxes. LogicalError
> has also been doing lots of refactoring-type work (based on me just skimming
> through SVN logs since April). And mrfl has been posting some changes. (Is
> that grover?)
>
> I think the best way for us to move forward is for us to get an idea of
> what you guys have been tinkering with. I mean, I can compile and run the
> kernel - and other than some instabilities (which we've always had, but
> they've certainly changed over time it seems), running the kernel in and of
> itself does not reveal much about the changes ("listresources" command is
> fascinating, but sometimes it makes QEmu lock up...). And frankly, I can't
> make heads or tails of the architecture from looking at the code anymore.
> (Which is from enthusiastic efforts on each of you all's parts, but largely
> seemingly uncoordinated.)
>
> So what I'm really asking is - can each of you three, please take some time
> to tell us about your work on SharpOS recently? We have the development
> blog, which has sat untouched since obsethryl's interview. LogicalError
> already has posting priveleges - so if grover (mrfl?) and tgiphil could send
> me, privately, a Google Account alias of yours, (feel free to create one, or
> just send me a personal e-mail of yours that you want to sign in to blogger
> for SharpOS with), I'll get you guys posting privileges.
>
> After which, I would ask that each of you spend the time, say about an
> hour, and write up an article on what you've been working on, and more
> importantly, why. Where it is going. What you want to see happen. And then
> you can e-mail the mailing list to let us know when you are finished,
> (preferably linking to the post), so that we can restore an organic feeling
> of what is going on here.
>
> If you have time for graphics and diagrams, don't let me stop you. However,
> I'm really thinking all we need is baseline textual thoughts. Mention some
> classes you've written, some paradigms you are trying to apply, etc. I'm
> hoping it will make up for a lack of Redmine and
> regularly-attended-and-documented SharpOS meetings for the last 4 months.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
>

Re: [SharpOS Developers] Map of what kernel looks like in memory

[Zachary G. <dra...@gm...>]

Shit.  Alright, in that case I'm gonna have to do some more digging.  I need
to determine a point where there's a minimal need to remap all the addresses
and pointers but we have enough set up that we can switch over to page
tables.  And I need to talk to my tutors again.

On Mon, Aug 4, 2008 at 10:03 AM, Bruce Markham <ill...@gm...>wrote:

>
>
> On Sun, Aug 3, 2008 at 9:53 PM, Zachary Gorden <dra...@gm...>wrote:
>
>> I actually have a similar question, and this pertains to the current
>> mapping of the kernel in memory.  Because we don't have anything like ntldr
>> or freeldr, the kernel needs to manually set up its page tables first, kinda
>> like how Linux does it.  If we're following convention, I'll need to remap
>> all of the addresses to their appropriate location in the upper 2GB.
>>
>> So my question basically is, is there a current map of what the kernel
>> looks like in memory?
>>
>>
> This is material is definitely better suited for a separate thread, (which
> I've taken care of). I'll answer with as much as I expect is true...
>
> The kernel has no well-defined structure in memory. The AOT outputs things
> in a specific order (undocumented, but with research it wouldn't be hard to
> determine), into a brute-forced binary that GRUB loads into memory and then
> lets us have our way with ourselves.
>
> So without a custom loader, or some sort of hacked implementation in order
> to work with another loader, we currently do not have support for this.
> Frankly, I don't think you can setup page tables without having something
> tied to an interrupt when paging is needed to be done - which brings us to
> identifying and accessing disk space. Due to the nano-kernel-esque design we
> are shooting for, (as far as modularity), I don't think this is an option
> for us right now.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
>

Re: [SharpOS Developers] Trunk Status Inquiry

[Bruce M. <ill...@gm...>]

Do not let the temptations of the topic-changers dissuade you!

Please heed my plea and give us all a small bit of colorful commentary on
what you've been working on...

[SharpOS Developers] Map of what kernel looks like in memory

[Bruce M. <ill...@gm...>]

On Sun, Aug 3, 2008 at 9:53 PM, Zachary Gorden <dra...@gm...>wrote:

> I actually have a similar question, and this pertains to the current
> mapping of the kernel in memory.  Because we don't have anything like ntldr
> or freeldr, the kernel needs to manually set up its page tables first, kinda
> like how Linux does it.  If we're following convention, I'll need to remap
> all of the addresses to their appropriate location in the upper 2GB.
>
> So my question basically is, is there a current map of what the kernel
> looks like in memory?
>
>
This is material is definitely better suited for a separate thread, (which
I've taken care of). I'll answer with as much as I expect is true...

The kernel has no well-defined structure in memory. The AOT outputs things
in a specific order (undocumented, but with research it wouldn't be hard to
determine), into a brute-forced binary that GRUB loads into memory and then
lets us have our way with ourselves.

So without a custom loader, or some sort of hacked implementation in order
to work with another loader, we currently do not have support for this.
Frankly, I don't think you can setup page tables without having something
tied to an interrupt when paging is needed to be done - which brings us to
identifying and accessing disk space. Due to the nano-kernel-esque design we
are shooting for, (as far as modularity), I don't think this is an option
for us right now.

Re: [SharpOS Developers] Trunk Status Inquiry

[Zachary G. <dra...@gm...>]

I actually have a similar question, and this pertains to the current mapping
of the kernel in memory.  Because we don't have anything like ntldr or
freeldr, the kernel needs to manually set up its page tables first, kinda
like how Linux does it.  If we're following convention, I'll need to remap
all of the addresses to their appropriate location in the upper 2GB.

So my question basically is, is there a current map of what the kernel looks
like in memory?

[SharpOS Developers] Trunk Status Inquiry

[Bruce M. <ill...@gm...>]

Due to the lack of regularly scheduled development on the project, combined
with the fact that there has still been development, I was hoping that a few
of the people involved with changes in the trunk could put together
summaries of what they have been working on for the last several months.

The majority of commits have been done by tgiphil - and some of those are
larger than they appear because they are merges from sandboxes. LogicalError
has also been doing lots of refactoring-type work (based on me just skimming
through SVN logs since April). And mrfl has been posting some changes. (Is
that grover?)

I think the best way for us to move forward is for us to get an idea of what
you guys have been tinkering with. I mean, I can compile and run the kernel
- and other than some instabilities (which we've always had, but they've
certainly changed over time it seems), running the kernel in and of itself
does not reveal much about the changes ("listresources" command is
fascinating, but sometimes it makes QEmu lock up...). And frankly, I can't
make heads or tails of the architecture from looking at the code anymore.
(Which is from enthusiastic efforts on each of you all's parts, but largely
seemingly uncoordinated.)

So what I'm really asking is - can each of you three, please take some time
to tell us about your work on SharpOS recently? We have the development
blog, which has sat untouched since obsethryl's interview. LogicalError
already has posting priveleges - so if grover (mrfl?) and tgiphil could send
me, privately, a Google Account alias of yours, (feel free to create one, or
just send me a personal e-mail of yours that you want to sign in to blogger
for SharpOS with), I'll get you guys posting privileges.

After which, I would ask that each of you spend the time, say about an hour,
and write up an article on what you've been working on, and more
importantly, why. Where it is going. What you want to see happen. And then
you can e-mail the mailing list to let us know when you are finished,
(preferably linking to the post), so that we can restore an organic feeling
of what is going on here.

If you have time for graphics and diagrams, don't let me stop you. However,
I'm really thinking all we need is baseline textual thoughts. Mention some
classes you've written, some paradigms you are trying to apply, etc. I'm
hoping it will make up for a lack of Redmine and
regularly-attended-and-documented SharpOS meetings for the last 4 months.

Re: [SharpOS Developers] MOSA / AOT

[Bruce M. <ill...@gm...>]

The SharpOS AOT is a fantastic machine. And if Chriss is still out there
listening - you have our deepest thanks for jump-starting the project with
it.

However, I am in also in agreement with Phil and Mike, in that, right now,
there is no maintenance on it - I believe that unsaid sentiment is that it
simply isn't maintainable. Everyone here wants to write kernel code. Or user
level code. The AOT is the means to an end - and several people now (through
grover's MOSA efforts, Ensemble, and Cosmos), have proven the basic ability
to compile IL to x86 is not particularly difficult. (Time consuming to
implement, sure. But there is more than enough documentation out there, and
previous works, to make a basic functionality work.)

The problem is, no one can take it that step forward. We need reflection, we
need dynamic runtime bindings, and we need it to be self-hosting. Whether or
not an AOT is re-written, or the current one is re-purposed - we still face
the issue of *how* to bind the kernel code to the AOT.

All of our efforts as a whole, need to address this issue first and
foremost. The good news is, if we can agree - it doesn't matter whose AOT to
work we decide to extend in that direction. Any single one could be the
solution to getting us to the next step. Just like there are standards for
how C compilers and C# compilers and such work - if we can define a standard
on how we want the AOT to handle a kernel - and then all agree to step
forward with that - we can benefit as a group.

And *then*, we can start talking about driver architectures and code
sharing. *shudder*. (I think a "common kernel" is out of the question,
because of licensing decisions as well as varying schools of thought around
here. But at least a common API means we don't have to share core
implementation code.)

Furthermore, I would like to assert that we not overlook JNode. MOSA right
now may just have a couple C# OS projects in it - but JNode has us beat on
the proof-of-concept managed operating system goal. With the proper
allocation of design efforts, we can create a set of standards that does not
preclude using IKVM, in combination with whatever AOT a C# OS project is
using, in order to run JNode driver binaries. It bypasses alot of design and
implementation work in order to get us all into common ground. Without
common ground, we cannot refer to ourselves as seperate projects divergent
from some mystical original ideal. C# is not an ideal. Its a tool. And the
managed bit, well, its already been done. If we are looking to innovate, we
need a jump-start. And then we can talk about re-writes and branches and
optimizations down the road.

I don't think there has been any official talks between SharpOS and JNode.
SharpOS + Ensemble + Cosmos relations are slippery at best. The C# crowd -
all of us - need to get our acts and heads together, under MOSA, (not sure
if Cosmos is still viable, much less, interested in MOSA, but still). With
that done, collectively, we need to rise up to meet JNode, and extend a hand
of friendship.

So, if someone could re-post the information on MOSA (wasn't there a
discussion group or something somewhere?), I would be grateful. We need
start some topics of conversation at a centralized, non-biased location. See
if we can crack our skulls together to get an idea of where to proceed.

But I agree. We will either work together or die together. There are too few
interested and available developers right now for it to be any other way.
And if we allow ourselves to fizzle, we will pollute the water for future
generations that get curious regarding this idea...

Re: [SharpOS Developers] MOSA / AOT

[Phil G. <ph...@th...>]

I'm in general agreement with Mike on this.

On Sun, Aug 3, 2008 at 2:20 PM, grover <sh...@mi...> wrote:

> This is a longer discussion. The MOSA effort as it is right now is
> primarily
> the forum & svn hosted by Scott Balmos (now Ensemble). My personal
> intention
> is to make MOSA a shared effort by both SharpOS and Ensemble. The problem
> both projects face are those of contributors/contributions and as we have
> discussed more than a week ago about architecture. We have to more or less
> live with the split efforts, however I think we can share the code we
> develop.
>
> My contributions to MOSA include:
>
> - A compiler
> - Beginnings of a VES with support for reflection and other things packed
> on
> top
>
> I hope we can extend this through shared efforts to include:
>
> - A common kernel
> - A common driver model and driver code
> - A common port/adaptation of monos corlib
>
> One additional goal is to make MOSA attractive for research.
>
> I have a lot of ideas in this regard and especially my vacation week was
> very productive to accomplish these goals.
>
> My *personal* thinking of MOSA is that it acts as the core kernel and
> SharpOS/Ensemble/... become distributions based on this kernel code in
> different configurations including/excluding certain things. I know this
> isn't easy for some of us and it isn't easy for Scott. However looking at
> the active contributor lists and the overall progress this is the only way
> I
> see both projects or either one can move forward. Either we work together
> or
> we die together.
>
> The AOT is working for us right now. I would like to keep it along as long
> as possible. However there's no real maintenance there as I see it.
>
> Mike
>
> > -----Ursprüngliche Nachricht-----
> > Von: sha...@li...
> > [mailto:sha...@li...] Im
> > Auftrag von Sander van Rossen
> > Gesendet: Dienstag, 29. Juli 2008 13:36
> > An: sha...@li...
> > Betreff: [SharpOS Developers] MOSA / AOT
>  >
> > I'm looking trough the issues on the sharpos webpage:
> >
> > Is Mosa (going to be) a replacement for the AOT compiler?
> > I'm asking because we have several issues (also for the next
> > milestone) related to AOT.
> > If nobody's going to continue working on the AOT, and it's
> > going to be replaced, then those issues would never be met
> > and should be removed.
> > (for example: "AOT documentation issue" / "Support for
> > floating-point primitives and arithmetic issue" / "Add
> > support for constructors of arrays that are not 0 based.")
> >
> >
> >
> > Also, there still seems to be one open issue on exception handling..
> > Anyone got any idea what the status is on that?
> > (same goes for "Some interrupts need to throw exceptions just
> > like DivideByZero" issue)
> >
> > --------------------------------------------------------------
> > -----------
> > This SF.Net email is sponsored by the Moblin Your Move
> > Developer's challenge Build the coolest Linux based
> > applications with Moblin SDK & win great prizes Grand prize
> > is a trip for two to an Open Source event anywhere in the
> > world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > SharpOS-Developers mailing list
> > Sha...@li...
> > https://lists.sourceforge.net/lists/listinfo/sharpos-developers
> >
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>

Re: [SharpOS Developers] MOSA / AOT

[grover <sh...@mi...>]

This is a longer discussion. The MOSA effort as it is right now is primarily
the forum & svn hosted by Scott Balmos (now Ensemble). My personal intention
is to make MOSA a shared effort by both SharpOS and Ensemble. The problem
both projects face are those of contributors/contributions and as we have
discussed more than a week ago about architecture. We have to more or less
live with the split efforts, however I think we can share the code we
develop.

My contributions to MOSA include:

- A compiler
- Beginnings of a VES with support for reflection and other things packed on
top

I hope we can extend this through shared efforts to include:

- A common kernel
- A common driver model and driver code
- A common port/adaptation of monos corlib

One additional goal is to make MOSA attractive for research. 

I have a lot of ideas in this regard and especially my vacation week was
very productive to accomplish these goals. 

My *personal* thinking of MOSA is that it acts as the core kernel and
SharpOS/Ensemble/... become distributions based on this kernel code in
different configurations including/excluding certain things. I know this
isn't easy for some of us and it isn't easy for Scott. However looking at
the active contributor lists and the overall progress this is the only way I
see both projects or either one can move forward. Either we work together or
we die together.

The AOT is working for us right now. I would like to keep it along as long
as possible. However there's no real maintenance there as I see it.

Mike

> -----Ursprüngliche Nachricht-----
> Von: sha...@li... 
> [mailto:sha...@li...] Im 
> Auftrag von Sander van Rossen
> Gesendet: Dienstag, 29. Juli 2008 13:36
> An: sha...@li...
> Betreff: [SharpOS Developers] MOSA / AOT
> 
> I'm looking trough the issues on the sharpos webpage:
> 
> Is Mosa (going to be) a replacement for the AOT compiler?
> I'm asking because we have several issues (also for the next
> milestone) related to AOT.
> If nobody's going to continue working on the AOT, and it's 
> going to be replaced, then those issues would never be met 
> and should be removed.
> (for example: "AOT documentation issue" / "Support for 
> floating-point primitives and arithmetic issue" / "Add 
> support for constructors of arrays that are not 0 based.")
> 
> 
> 
> Also, there still seems to be one open issue on exception handling..
> Anyone got any idea what the status is on that?
> (same goes for "Some interrupts need to throw exceptions just 
> like DivideByZero" issue)
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
> 

Re: [SharpOS Developers] Virtual Meeting: Memory Manager Design, To Do List, and Overall Compartmentalization

[grover <sh...@mi...>]

I have not received a reply on the backup status. The other issue is that
someone with better Unix skills should do this job. So there's no updates
from me. 

> -----Ursprüngliche Nachricht-----
> Von: sha...@li... 
> [mailto:sha...@li...] Im 
> Auftrag von Sander van Rossen
> Gesendet: Dienstag, 29. Juli 2008 15:44
> An: sha...@li...
> Betreff: Re: [SharpOS Developers] Virtual Meeting: Memory 
> Manager Design,To Do List, and Overall Compartmentalization
> 
> Any update on this? Is there any plan currently to upgrade redmine?
> having to retry 5-10 times before an issue i'm modifying is 
> actually modified is getting rather tiresome...
> 
> On Mon, Jul 21, 2008 at 10:59 AM, grover 
> <sh...@mi...> wrote:
> > I've just looked into the issue. We need to update ruby to 
> 1.8.6 and 
> > we could go to redmine 0.7.3 from 0.6.1 - sounds like major 
> changes to 
> > me. Additionally we may need to update rails unless its part of the 
> > ruby package.
> >
> > I'm not the most profound user of these shared hosting 
> accounts - if 
> > we have a backup I could try my luck.
> >
> > Mike
> >
> > Am 21.07.2008 um 02:40 schrieb William Lahti:
> >
> >> Another option is to upgrade redmine, which hasn't been 
> done since we 
> >> installed it. Any takers there?
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
> 

[SharpOS Developers] I am new :)

[Iraklis K. <her...@gm...>]

Hi,

I am new, I a programming experience in c, vb6, vb.net and now in c#
(thanks to god c# exists:P). i am 16 years old and i want to help as
much as i can. i have not any kind of experinmce on developing kernels
but i find it interesting!

how can i start to understand the hole thing?? any book, reference or
any kind of docs?? in wich area i can help?? i hope i can help somewere!

Thanks,
Iraklis

[SharpOS Developers] AOT Help

[Phil G. <ph...@th...>]

/*
 * (c) 2008 The Ensemble OS Project
 * http://www.ensemble-os.org
 * All Rights Reserved
 *
 * This code is covered by the New BSD License, found in license.txt
 *
 * Authors:
 *  Phil Garcia (tgiphil) <ph...@th...>
 *
*/

using System;
using System.Collections.Generic;
using System.Collections;

namespace Mosa.ClassLibs
{

    public class LinkedList<T> : ICollection<T>, IEnumerable<T>
    {
        public class LinkedListNode<T>
        {
            public T value;
            public LinkedListNode<T> next;
            public LinkedListNode<T> previous;

            public LinkedListNode(T value, LinkedListNode<T> previous, LinkedListNode<T> next)
            {
                this.value = value;
                this.next = next;
                this.previous = previous;
            }

        }

        protected LinkedListNode<T> first;
        protected int count;

        public bool IsReadOnly { get { return false; } }
        public int Count { get { return count; } }

        public LinkedListNode<T> First
        {
            get
            {
                return first;
            }
        }

        protected LinkedListNode<T> last;

        public LinkedListNode<T> Last
        {
            get
            {
                return last;
            }
        }

        public LinkedList()
        {
            first = last = null;
        }

        public void Clear()
        {
            first = last = null;
        }

        public LinkedListNode<T> Find(T value)
        {
            LinkedListNode<T> cur = first;

            while (cur != null) {
                if (cur.value.Equals(value))
                    return cur;
                cur = cur.next;
            }
            return null;
        }

        public bool Contains(T value)
        {
            return (Find(value) != null);
        }

        public LinkedListNode<T> FindLast(T value)
        {
            LinkedListNode<T> found = null;
            LinkedListNode<T> cur = first;

            while (cur != null) {
                if (cur.value.Equals(value))
                    found = cur;
                cur = cur.next;
            }
            return found;
        }

        public void Add(T value)
        {
            AddLast(value);
        }

        public LinkedListNode<T> AddLast(T value)
        {
            LinkedListNode<T> node = new LinkedListNode<T>(value, last, null);
            return AddLast(node);
        }

        public LinkedListNode<T> AddLast(LinkedListNode<T> node)
        {
            if (first == null) {
                first = node;
                last = node;
            }
            else {
                node.previous.next = node;
                last = node;
            }

            count++;
            return node;
        }

        public LinkedListNode<T> AddFirst(T value)
        {
            LinkedListNode<T> node = new LinkedListNode<T>(value, null, first);
            return AddFirst(node);
        }

        public LinkedListNode<T> AddFirst(LinkedListNode<T> node)
        {
            if (first != null)
                first.previous = node;

            first = node;

            count++;
            return node;
        }

        public LinkedListNode<T> AddAfter(LinkedListNode<T> node, T value)
        {
            if (node == null)
                throw new ArgumentNullException();

            LinkedListNode<T> cur = new LinkedListNode<T>(value, node, node.next);

            if (node.next != null)
                node.next.previous = cur;
            node.next = cur;

            if (cur.next == null)
                last = cur;

            count++;
            return cur;
        }

        public LinkedListNode<T> AddBefore(LinkedListNode<T> node, T value)
        {
            if (node == null)
                throw new ArgumentNullException();

            LinkedListNode<T> cur = new LinkedListNode<T>(value, node.previous, node);

            if (node.previous != null)
                node.previous.next = cur;
            node.previous = cur;

            if (cur.previous == null)
                first = cur;

            count++;
            return cur;
        }

        public bool Remove(T value)
        {
            LinkedListNode<T> node = Find(value);

            if (node == null)
                return false;

            Remove(node);
            return true;
        }

        public void Remove(LinkedListNode<T> node)
        {
            if (node == null)
                throw new InvalidOperationException();

            if (node.previous != null)
                node.previous.next = node.next;

            if (node.next != null)
                node.next.previous = node.previous;

            if (node == first)
                first = node.next;

            if (node == last)
                last = node.previous;

            count--;
        }

        public void RemoveFirst()
        {
            if (first == null)
                throw new InvalidOperationException();

            first = first.next;
            first.previous = null;

            if (first.next == null)
                last = first;

            count--;
        }

        public void RemoveLast()
        {
            if (last == null)
                throw new InvalidOperationException();

            last.previous = null;
            count--;
        }

        public void CopyTo(T[] array, int arrayIndex)
        {
            if (array == null)
                throw new ArgumentNullException();
            if (arrayIndex < 0)
                throw new ArgumentOutOfRangeException();

            //if (array.Rank != 1)
            //    throw new ArgumentException();
            //if (array.Length - arrayIndex + array.GetLowerBound(0) < count)
            //    throw new ArgumentException();

            LinkedListNode<T> cur = First;
            int index = arrayIndex;

            while (cur != null) {
                array[index++] = cur.value;
                cur = cur.next;

            }
        }

        public IEnumerator<T> GetEnumerator()
        {
            for (LinkedListNode<T> cur = first; cur != null; cur = cur.next)
                yield return cur.value;
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            for (LinkedListNode<T> cur = first; cur != null; cur = cur.next)
                yield return cur.value;
        }

    }
}

Re: [SharpOS Developers] True Type Fonts

[Sander v. R. <s.v...@sy...>]

Yeah somebody did some basic graphics work, but it was a bit too early
for it to be used.. especially since we had nothing like a driver
architecture back then, which at least now we have a good part already
in place (of the architecture)

On Fri, Aug 1, 2008 at 4:55 PM, Phil Garcia <ph...@th...> wrote:
> Very cool. I think someone already did some work on a VGA driver, but they
> didn't been committed to the trunk. I'll look around for it and get it
> implemented. Let us know why type of graphic API methods you will need since
> obviously we won't have .NET graphic classes available for a while.
> -Phil

Re: [SharpOS Developers] True Type Fonts

[Phil G. <ph...@th...>]

Very cool. I think someone already did some work on a VGA driver, but they
didn't been committed to the trunk. I'll look around for it and get it
implemented. Let us know why type of graphic API methods you will need since
obviously we won't have .NET graphic classes available for a while.
-Phil
On Thu, Jul 31, 2008 at 2:46 AM, Jonathan Dickinson
<jon...@gm...>wrote:

> Hi All,
>
> I have taken the dive and I am busy implementing True Type font
> support: it's going to crop up sooner or later and I can't really help
> out with the stuff happening in Ensemble at the moment (I still need
> to do some more reading).
>
> In any case, the format is horrible! So far I am reading in the cmap
> (maps unicode characters to glyphs), cvt (constants) and name (name
> table, has the font name etc.).
>
> I am thinking I will do the glyf table next, so that I can start
> drawing these bad-boys out ;).
>
> Just a heads up so that no one else works on it at the same time. I
> will be uploading it to MOSA some time soon so if you want to help out
> just say. The code will, of course, be available for all the MOSA
> affiliates (MOSA affiliates ONLY).
>
> --
> Jonathan
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>

Re: [SharpOS Developers] True Type Fonts

[Maciej J. <him...@o2...>]

I'm willing to contribute, yet I'm not sure if I can do much in
time I have :(
I have some code for loading basic tables, yet I'd like to clean
it up a bit first...


Jonathan Dickinson wrote:
> Hi All,
>
> I have taken the dive and I am busy implementing True Type font
> support: it's going to crop up sooner or later and I can't really help
> out with the stuff happening in Ensemble at the moment (I still need
> to do some more reading).
>
> In any case, the format is horrible! So far I am reading in the cmap
> (maps unicode characters to glyphs), cvt (constants) and name (name
> table, has the font name etc.).
>
> I am thinking I will do the glyf table next, so that I can start
> drawing these bad-boys out ;).
>
> Just a heads up so that no one else works on it at the same time. I
> will be uploading it to MOSA some time soon so if you want to help out
> just say. The code will, of course, be available for all the MOSA
> affiliates (MOSA affiliates ONLY).
>
>   

Re: [SharpOS Developers] True Type Fonts

[Sander v. R. <s.v...@sy...>]

Awesome :)
Very useful (eventually), but i don't envy the world of hurt you're
getting yourself into ;)


On Thu, Jul 31, 2008 at 11:46 AM, Jonathan Dickinson
<jon...@gm...> wrote:
> Hi All,
>
> I have taken the dive and I am busy implementing True Type font
> support: it's going to crop up sooner or later and I can't really help
> out with the stuff happening in Ensemble at the moment (I still need
> to do some more reading).
>
> In any case, the format is horrible! So far I am reading in the cmap
> (maps unicode characters to glyphs), cvt (constants) and name (name
> table, has the font name etc.).
>
> I am thinking I will do the glyf table next, so that I can start
> drawing these bad-boys out ;).
>
> Just a heads up so that no one else works on it at the same time. I
> will be uploading it to MOSA some time soon so if you want to help out
> just say. The code will, of course, be available for all the MOSA
> affiliates (MOSA affiliates ONLY).
>
> --
> Jonathan
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>

[SharpOS Developers] True Type Fonts

[Jonathan D. <jon...@gm...>]

Hi All,

I have taken the dive and I am busy implementing True Type font
support: it's going to crop up sooner or later and I can't really help
out with the stuff happening in Ensemble at the moment (I still need
to do some more reading).

In any case, the format is horrible! So far I am reading in the cmap
(maps unicode characters to glyphs), cvt (constants) and name (name
table, has the font name etc.).

I am thinking I will do the glyf table next, so that I can start
drawing these bad-boys out ;).

Just a heads up so that no one else works on it at the same time. I
will be uploading it to MOSA some time soon so if you want to help out
just say. The code will, of course, be available for all the MOSA
affiliates (MOSA affiliates ONLY).

-- 
Jonathan

[SharpOS Developers] SharpBot

[Sander v. R. <s.v...@sy...>]

Yesterday i thought I'd debug sharpbot to see why it was crashing
before, but to my surprise it worked flawlessly!
I haven't tried it for a while, so maybe this had something to do with
the server problem we had some time ago?
Anyway, until we find a more permanent solution, it would be nice if
some volunteers would start starting up the sharpbot again now and
then.
Which reminds me... can one of the old board members send the sharpbot
settings (password etc.) to the new board members, so they can run it
as well?
(I don't have them here right now, I'll send them tonight if nobody
else has done so in the meantime)

[SharpOS Developers] Welcome new board members

[William L. <xfu...@gm...>]

I want to take a minute to welcome our two new board members, Michael
Ruck and Phil Garcia! Thanks for accepting and I look forward to
working with you to make SharpOS a brighter, healthier, and more
active project! To the board members: If you haven't already done so,
please take a few minutes to review our wiki page on our official
policies which we use to govern board activity at
http://www.sharpos.org/redmine/wiki/3/Organization_Policies. Both new
board members have been subscribed to the sharpos-board list. Great to
have you aboard!

-- 
fury

long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/

Re: [SharpOS Developers] Virtual Meeting: Memory Manager Design, To Do List, and Overall Compartmentalization

[Bruce M. <ill...@gm...>]

Chriss was the one that originally set up redmine (it was rather involved, I
believe.) But as far as I know, Will is the only one with access to the
server...

Re: [SharpOS Developers] Virtual Meeting: Memory Manager Design, To Do List, and Overall Compartmentalization

[Sander v. R. <s.v...@sy...>]

Any update on this? Is there any plan currently to upgrade redmine?
having to retry 5-10 times before an issue i'm modifying is actually
modified is getting rather tiresome...

On Mon, Jul 21, 2008 at 10:59 AM, grover <sh...@mi...> wrote:
> I've just looked into the issue. We need to update ruby to 1.8.6 and
> we could go to redmine 0.7.3 from 0.6.1 - sounds like major changes to
> me. Additionally we may need to update rails unless its part of the
> ruby package.
>
> I'm not the most profound user of these shared hosting accounts - if
> we have a backup I could try my luck.
>
> Mike
>
> Am 21.07.2008 um 02:40 schrieb William Lahti:
>
>> Another option is to upgrade redmine, which hasn't been done since we
>> installed it. Any takers there?

[SharpOS Developers] MOSA / AOT

[Sander v. R. <s.v...@sy...>]

I'm looking trough the issues on the sharpos webpage:

Is Mosa (going to be) a replacement for the AOT compiler?
I'm asking because we have several issues (also for the next
milestone) related to AOT.
If nobody's going to continue working on the AOT, and it's going to be
replaced,
then those issues would never be met and should be removed.
(for example: "AOT documentation issue" / "Support for floating-point
primitives and arithmetic issue" / "Add support for constructors of
arrays that are not 0 based.")



Also, there still seems to be one open issue on exception handling..
Anyone got any idea what the status is on that?
(same goes for "Some interrupts need to throw exceptions just like
DivideByZero" issue)

Re: [SharpOS Developers] DiagnosticTool

[Jonathan D. <jon...@gm...>]

Cedric I would be interested in helping you with the debugger. Since
we are going to be using one compiler portablility issues should
dissolve. As you probably know I did some work in Cosmos with the GDB
client protocol, how far are you with that?

On Tue, Jul 29, 2008 at 11:22 AM, Cédric Rousseau <ce...@gm...> wrote:
> I wrote the first version of DiagTool to help exploring memory in the
> kernel. The last commited version (02/2008) was able to gather unit test
> results and debug output strings. Due to platform specific code, the desktop
> client worked only on Windows: the name pipe code was not ported on Linux.
> I've started a wiki page to describe its job:
> http://www.sharpos.org/redmine/wiki/3/DiagnosticTool
>
> The first idea was to create a tool that helps developpers but I don't think
> it's now more than a proof of concept.
> I've never thougt to write a debugger. There are some very good debuggers
> around and I've started working in my sandbox on GDB (linux) and CDB
> (windows) debuggers stubs. I didn't have any time until now to complete
> this.
>
> I don't think the DiagTool has been used by many of us, so you can remove it
> from the trunk, or at least disable \ comment out the code. I keep a copy in
> my branch and I think I will have more time on september to work on this and
> on debugger stuff.
>
> Cédric
>
> On Tue, Jul 29, 2008 at 5:12 AM, Phil Garcia <ph...@th...> wrote:
>>
>> To be more specific, I refactored the existing serial driver into the new
>> driver framework. Unfortunately, it somehow broke the DiagnosticTool and I
>> have not been able to figure it out. Maybe a second pair of eyes can spot
>> the problem?
>>
>> In the mean time, I'd like to move forward and commit my changes back into
>> the trunk before they get too far out of sync.
>>
>> -Phil
>>
>>
>> On Mon, Jul 28, 2008 at 7:18 AM, Sander van Rossen
>> <s.v...@sy...> wrote:
>>>
>>> What exactly is the "DiagnosticTool", and is it still used/relevant?
>>> I'm asking because Phil had some problems to get the kernel side of it
>>> to work with the new driver model,
>>> and that's the main reason he hasn't committed his changes yet.
>>> If it's not used anymore, or relevant, it's support could be removed
>>> from the kernel and Phil can commit his changes.
>>> Otherwise, whomever uses it, can help him out getting it back to work?
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> SharpOS-Developers mailing list
>>> Sha...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> SharpOS-Developers mailing list
>> Sha...@li...
>> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
>



-- 
Jonathan

Re: [SharpOS Developers] DiagnosticTool

[Sander v. R. <s.v...@sy...>]

Allright.
So, Phil, i suggest that you commit your changes to the trunk and
comment out the diagnostic tool stuff so that cedric can eventually
fix/finish it whenever he has time again :)

On Tue, Jul 29, 2008 at 11:22 AM, Cédric Rousseau <ce...@gm...> wrote:
> I wrote the first version of DiagTool to help exploring memory in the
> kernel. The last commited version (02/2008) was able to gather unit test
> results and debug output strings. Due to platform specific code, the desktop
> client worked only on Windows: the name pipe code was not ported on Linux.
> I've started a wiki page to describe its job:
> http://www.sharpos.org/redmine/wiki/3/DiagnosticTool
>
> The first idea was to create a tool that helps developpers but I don't think
> it's now more than a proof of concept.
> I've never thougt to write a debugger. There are some very good debuggers
> around and I've started working in my sandbox on GDB (linux) and CDB
> (windows) debuggers stubs. I didn't have any time until now to complete
> this.
>
> I don't think the DiagTool has been used by many of us, so you can remove it
> from the trunk, or at least disable \ comment out the code. I keep a copy in
> my branch and I think I will have more time on september to work on this and
> on debugger stuff.
>
> Cédric