Menu
▾
▴
sharpos-developers
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(29) |
Aug
(214) |
Sep
(148) |
Oct
(7) |
Nov
(117) |
Dec
(220) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(202) |
Feb
(96) |
Mar
(106) |
Apr
(90) |
May
(10) |
Jun
(13) |
Jul
(99) |
Aug
(76) |
Sep
(17) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2009 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert W. <rj...@gm...> - 2008-08-07 15:07:59
|
Hello, I have just checked out revision 1233 to try and get into SharpOS. However, it won't build. I attach the NAnt output. I know I should probably raise this on IRC, but my proxy server won't let it through at the moment. Thank you, Robert Wills |
|
From: grover <sh...@mi...> - 2008-08-07 08:10:44
|
Me too! I've been using it for several tasks and university projects, it is a really lovely tool. Mike > -----Ursprüngliche Nachricht----- > Von: sha...@li... > [mailto:sha...@li...] Im > Auftrag von Adam Stevenson > Gesendet: Donnerstag, 7. August 2008 07:15 > An: sha...@li... > Cc: ens...@li...; Cos...@ya... > Betreff: Re: [SharpOS Developers] [Cosmos-Dev] FYI: OMG leans > toward LINQ asan OODBMS access standard > > Yeah I have been in love with Db4o for years, since its > inception, and use it every time I need to do serialization. > :) For me, it is a win hands down because of the fact it can > serialize an object that it has never seen before. > > On Wed, Aug 6, 2008 at 7:22 PM, Chad Z. Hower aka Kudzu > <Ch...@ho...> wrote: > > Very interesting indeed! > > > > > > > > From: Cos...@ya... > [mailto:Cos...@ya...] > > On Behalf Of grover > > Sent: Thursday, August 07, 2008 1:45 AM > > To: sha...@li...; > > ens...@li...; Cos...@ya... > > Subject: [Cosmos-Dev] FYI: OMG leans toward LINQ as an > OODBMS access > > standard > > > > > > > > I've just found the following snippet in todays db4o (www.db4o.com) > > newsletter: > > > > OMG Leaning towards the LINQ Way to a OODBMS Standard > > > > * Not having a standard query language for object databases > has been a > > stumbling block for OODBMS adoption. > > * The OMG is working on creating such a standard (see the OMG > > activities > <http://developer.db4o.com/r.ashx?3&pnr=00Q3000000C1zcYEAR> ). > > * In the last meeting in Ottawa in June, the committee has > viewed LINQ > > (on .NET) as the way to go for the standard. > > * LINQ is a Native Queries > > > <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecy > > cle/Qu erying/Native_Queries?pnr=00Q3000000C1zcYEAR> approach > > combining Relational and Object Database Queries into a > unified native > > interface, which has been accepted very enthusiastically by the > > community. > > * db4o is full heartedly supporting this direction, and has > been first > > to release an optimized provider for LINQ > > > <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecy > > cle/Qu > > erying/LINQ?pnr=00Q3000000C1zcYEAR> . > > * We would like to hear your opinion on the LINQ for Java group > > <http://developer.db4o.com/r.ashx?2&pnr=00Q3000000C1zcYEAR> . > > > > I think this is a very important milestone. > > > > Mike aka grover > > > > __._,_.___ > > > > Messages in this topic (1) Reply (via web post) | Start a new topic > > > > Messages | Files | Photos | Links | Database | Polls | Members | > > Calendar > > > > Change settings via the Web (Yahoo! ID required) Change > settings via > > email: Switch delivery to Daily Digest | Switch format to > Traditional > > Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe > > > > Recent Activity > > > > · 1 > > > > New Members > > > > Visit Your Group > > > > Yahoo! Finance > > > > It's Now Personal > > > > Guides, news, > > > > advice & more. > > > > Popular Y! Groups > > > > Is your group one? > > > > Check it out and > > > > see. > > > > Check out the > > > > Y! Groups blog > > > > Stay up to speed > > > > on all things Groups! > > > > . > > > > __,_._,___ > > > > > ---------------------------------------------------------------------- > > --- 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 > |
|
From: Adam S. <a.l...@gm...> - 2008-08-07 05:15:02
|
Yeah I have been in love with Db4o for years, since its inception, and use it every time I need to do serialization. :) For me, it is a win hands down because of the fact it can serialize an object that it has never seen before. On Wed, Aug 6, 2008 at 7:22 PM, Chad Z. Hower aka Kudzu <Ch...@ho...> wrote: > Very interesting indeed! > > > > From: Cos...@ya... [mailto:Cos...@ya...] On > Behalf Of grover > Sent: Thursday, August 07, 2008 1:45 AM > To: sha...@li...; > ens...@li...; Cos...@ya... > Subject: [Cosmos-Dev] FYI: OMG leans toward LINQ as an OODBMS access > standard > > > > I've just found the following snippet in todays db4o (www.db4o.com) > newsletter: > > OMG Leaning towards the LINQ Way to a OODBMS Standard > > * Not having a standard query language for object databases has been a > stumbling block for OODBMS adoption. > * The OMG is working on creating such a standard (see the OMG > activities <http://developer.db4o.com/r.ashx?3&pnr=00Q3000000C1zcYEAR> ). > * In the last meeting in Ottawa in June, the committee has viewed LINQ > (on .NET) as the way to go for the standard. > * LINQ is a Native Queries > <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu > erying/Native_Queries?pnr=00Q3000000C1zcYEAR> approach combining Relational > and Object Database Queries into a unified native interface, which has been > accepted very enthusiastically by the community. > * db4o is full heartedly supporting this direction, and has been first > to release an optimized provider for LINQ > <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu > erying/LINQ?pnr=00Q3000000C1zcYEAR> . > * We would like to hear your opinion on the LINQ for Java group > <http://developer.db4o.com/r.ashx?2&pnr=00Q3000000C1zcYEAR> . > > I think this is a very important milestone. > > Mike aka grover > > __._,_.___ > > Messages in this topic (1) Reply (via web post) | Start a new topic > > Messages | Files | Photos | Links | Database | Polls | Members | Calendar > > Change settings via the Web (Yahoo! ID required) > Change settings via email: Switch delivery to Daily Digest | Switch format > to Traditional > Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe > > Recent Activity > > · 1 > > New Members > > Visit Your Group > > Yahoo! Finance > > It's Now Personal > > Guides, news, > > advice & more. > > Popular Y! Groups > > Is your group one? > > Check it out and > > see. > > Check out the > > Y! Groups blog > > Stay up to speed > > on all things Groups! > > . > > __,_._,___ > > ------------------------------------------------------------------------- > 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 > > |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2008-08-07 00:23:51
|
Very interesting indeed! From: Cos...@ya... [mailto:Cos...@ya...] On Behalf Of grover Sent: Thursday, August 07, 2008 1:45 AM To: sha...@li...; ens...@li...; Cos...@ya... Subject: [Cosmos-Dev] FYI: OMG leans toward LINQ as an OODBMS access standard I've just found the following snippet in todays db4o (www.db4o.com) newsletter: OMG Leaning towards the LINQ Way to a OODBMS Standard * Not having a standard query language for object databases has been a stumbling block for OODBMS adoption. * The OMG is working on creating such a standard (see the OMG activities <http://developer.db4o.com/r.ashx?3 <http://developer.db4o.com/r.ashx?3&pnr=00Q3000000C1zcYEAR> &pnr=00Q3000000C1zcYEAR> ). * In the last meeting in Ottawa in June, the committee has viewed LINQ (on .NET) as the way to go for the standard. * LINQ is a Native Queries <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu erying/Native_Queries?pnr=00Q3000000C1zcYEAR> approach combining Relational and Object Database Queries into a unified native interface, which has been accepted very enthusiastically by the community. * db4o is full heartedly supporting this direction, and has been first to release an optimized provider for LINQ <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu erying/LINQ?pnr=00Q3000000C1zcYEAR> . * We would like to hear your opinion on the LINQ for Java group <http://developer.db4o.com/r.ashx?2 <http://developer.db4o.com/r.ashx?2&pnr=00Q3000000C1zcYEAR> &pnr=00Q3000000C1zcYEAR> . I think this is a very important milestone. Mike aka grover __._,_.___ Messages <http://groups.yahoo.com/group/Cosmos-Dev/message/1186;_ylc=X3oDMTM1b2dudm1q BF9TAzk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRtc2dJZAMxMTg2 BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTIxODA0NDg2OQR0cGNJZAMxMTg2> in this topic (1) <http://groups.yahoo.com/group/Cosmos-Dev/post;_ylc=X3oDMTJxNW5xa2FzBF9TAzk3 MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRtc2dJZAMxMTg2BHNlYwNm dHIEc2xrA3JwbHkEc3RpbWUDMTIxODA0NDg2OQ--?act=reply&messageNum=1186> Reply (via web post) | Start <http://groups.yahoo.com/group/Cosmos-Dev/post;_ylc=X3oDMTJmOTRva3MxBF9TAzk3 MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNudHBj BHN0aW1lAzEyMTgwNDQ4Njk-> a new topic Messages <http://groups.yahoo.com/group/Cosmos-Dev/messages;_ylc=X3oDMTJmNmw3dGMxBF9T Azk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNt c2dzBHN0aW1lAzEyMTgwNDQ4Njk-> | Files <http://groups.yahoo.com/group/Cosmos-Dev/files;_ylc=X3oDMTJnMjdtMXJ1BF9TAzk 3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNmaWx lcwRzdGltZQMxMjE4MDQ0ODY5> | Photos <http://groups.yahoo.com/group/Cosmos-Dev/photos;_ylc=X3oDMTJmazBnMHJiBF9TAz k3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNwaG 90BHN0aW1lAzEyMTgwNDQ4Njk-> | Links <http://groups.yahoo.com/group/Cosmos-Dev/links;_ylc=X3oDMTJnbXIyZjBxBF9TAzk 3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNsaW5 rcwRzdGltZQMxMjE4MDQ0ODY5> | Database <http://groups.yahoo.com/group/Cosmos-Dev/database;_ylc=X3oDMTJkY25yOTNuBF9T Azk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNk YgRzdGltZQMxMjE4MDQ0ODY5> | Polls <http://groups.yahoo.com/group/Cosmos-Dev/polls;_ylc=X3oDMTJnbnZiajVyBF9TAzk 3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNwb2x scwRzdGltZQMxMjE4MDQ0ODY5> | Members <http://groups.yahoo.com/group/Cosmos-Dev/members;_ylc=X3oDMTJmY24xM2ppBF9TA zk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNtY nJzBHN0aW1lAzEyMTgwNDQ4Njk-> | Calendar <http://groups.yahoo.com/group/Cosmos-Dev/calendar;_ylc=X3oDMTJlZTI0Mzh0BF9T Azk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNj YWwEc3RpbWUDMTIxODA0NDg2OQ--> <http://groups.yahoo.com/;_ylc=X3oDMTJlb2k5dGQ0BF9TAzk3MzU5NzE0BGdycElkAzIxM zk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIxODA0NDg2O Q--> Yahoo! Groups Change <http://groups.yahoo.com/group/Cosmos-Dev/join;_ylc=X3oDMTJnMDA3dThtBF9TAzk3 MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNzdG5n cwRzdGltZQMxMjE4MDQ0ODY5> settings via the Web (Yahoo! ID required) Change settings via email: Switch <mailto:Cos...@ya...?subject=Email%20Delivery:%20Digest > delivery to Daily Digest | Switch <mailto:Cos...@ya...?subject=Change%20Delivery%20F ormat:%20Traditional> format to Traditional Visit <http://groups.yahoo.com/group/Cosmos-Dev;_ylc=X3oDMTJlYWZjaWJkBF9TAzk3MzU5N zE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDZnRyBHNsawNocGYEc3Rpb WUDMTIxODA0NDg2OQ--> Your Group | Yahoo! Groups <http://docs.yahoo.com/info/terms/> Terms of Use | Unsubscribe <mailto:Cos...@ya...?subject=> Recent Activity . 1 New <http://groups.yahoo.com/group/Cosmos-Dev/members;_ylc=X3oDMTJnb2dnNTFnBF9TA zk3MzU5NzE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDdnRsBHNsawN2b WJycwRzdGltZQMxMjE4MDQ0ODY5> Members Visit <http://groups.yahoo.com/group/Cosmos-Dev;_ylc=X3oDMTJma3ZhMWVhBF9TAzk3MzU5N zE0BGdycElkAzIxMzk5Nzk2BGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDdnRsBHNsawN2Z2hwBHN0a W1lAzEyMTgwNDQ4Njk-> Your Group Yahoo! Finance It's <http://us.ard.yahoo.com/SIG=13ondjkq2/M=493064.12016257.12445664.8674578/D= groups/S=1705006559:NC/Y=YAHOO/EXP=1218052070/L=/B=QCl2B0LaX90-/J=1218044870 237083/A=4507179/R=0/SIG=12de4rskk/*http:/us.rd.yahoo.com/evt=50284/*http:/f inance.yahoo.com/personal-finance> Now Personal Guides, news, advice & more. Popular Y! Groups Is <http://us.ard.yahoo.com/SIG=13or1po1d/M=493064.12016306.12445698.8674578/D= groups/S=1705006559:NC/Y=YAHOO/EXP=1218052070/L=/B=QSl2B0LaX90-/J=1218044870 237083/A=4763761/R=0/SIG=11ou7otip/*http:/advision.webevents.yahoo.com/besto fyahoogroups/> your group one? Check it out and see. Check out the Y! <http://us.ard.yahoo.com/SIG=13ot6pnj9/M=493064.12016258.12582637.8674578/D= groups/S=1705006559:NC/Y=YAHOO/EXP=1218052070/L=/B=Qil2B0LaX90-/J=1218044870 237083/A=5191952/R=0/SIG=112mhte3e/*http:/www.ygroupsblog.com/blog/> Groups blog Stay up to speed on all things Groups! . <http://geo.yahoo.com/serv?s=97359714/grpId=21399796/grpspId=1705006559/msgI d=1186/stime=1218044869/nc1=4507179/nc2=4763761/nc3=5191952> __,_._,___ |
|
From: grover <sh...@mi...> - 2008-08-06 20:46:45
|
Hello MOSA community members, As most likely no one checks the MOSA Forum anymore, I'm explicitly sending the mail to potentially interested projects. You can find a proposal on the topic of physical memory page management at http://svn.mosa.ensemble-os.org/rfc/proposals/mosa-rfc-0003.xml. Anyone interested in discussing this RFC should join the MOSA forums and contribute to the thread http://mosa.ensemble-os.org/viewtopic.php?f=4&t=16. Thank you. Mike aka grover |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 19:15:30
|
gcc-cil seems to be rather defunct now. A guy worked on it for SOC '05, never finished, and has moved on to other pursuits. Eventually, hopefully, someone from one of our OS projects, or someone from GCC, or someone from Mono, will come along and pick up the slack... |
|
From: Maciej J. <him...@o2...> - 2008-08-06 18:30:34
|
I would rather consider solutions such as GCC-CIL (http://www.mono-project.com/Summer2005#GCC_CIL), but it would be somehow ugly anyway... Btw, the GNU Classpath has a TrueType renderer, but we must consider license issues (GPLv2+CP) if the implementation's going to be shared among projects. |
|
From: grover <sh...@mi...> - 2008-08-06 17:47:58
|
I've just found the following snippet in todays db4o (www.db4o.com) newsletter: OMG Leaning towards the LINQ Way to a OODBMS Standard * Not having a standard query language for object databases has been a stumbling block for OODBMS adoption. * The OMG is working on creating such a standard (see the OMG activities <http://developer.db4o.com/r.ashx?3&pnr=00Q3000000C1zcYEAR> ). * In the last meeting in Ottawa in June, the committee has viewed LINQ (on .NET) as the way to go for the standard. * LINQ is a Native Queries <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu erying/Native_Queries?pnr=00Q3000000C1zcYEAR> approach combining Relational and Object Database Queries into a unified native interface, which has been accepted very enthusiastically by the community. * db4o is full heartedly supporting this direction, and has been first to release an optimized provider for LINQ <http://developer.db4o.com/Resources/view.aspx/Reference/Object_Lifecycle/Qu erying/LINQ?pnr=00Q3000000C1zcYEAR> . * We would like to hear your opinion on the LINQ for Java group <http://developer.db4o.com/r.ashx?2&pnr=00Q3000000C1zcYEAR> . I think this is a very important milestone. Mike aka grover |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 13:05:15
|
Well, TrueType font support would be nice. But I think the whole point is to do it all in a managed language. For the sanity of any developers on any of the C# OS projects, I would suggest not diverging into running native code right now. For something like TrueType fonts - I think we will all need an implementation native to us, that is, managed. For more complex applications down the road, (Firefox, anyone?), maybe then - we can talk about VMing to run native code or something. (But frankly, I think we need a C# web browser, too.) For now, I personally think running native code will cause more headaches than it can solve. |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 12:44:39
|
Welcome, Simon! I think grover will need all the help he can get, but we are, regardless, glad to have you on board with the community. Just don't be afraid to bring the more extended discussions up on the mailing list, (instead of IRC), so everyone can contribute. Again, good to have you! |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 12:42:33
|
> The MOSA forums are not used much right now. I agree with you > there. You see I'm in a weird position - I'm contributing things > and trying to drive the effort my way. I've been primarily doing > things by communicating with those really interested directly in > person and have used the resources SharpOS and Ensemble have provided > me with. The infrastructure (like Phil said) is being worked on and > will appear sooner or later. > And don't think we weren't keeping that in mind when we put you on the SharpOS board. We are here for community, and we don't want to alienate anyone. (i.e., I wasn't trying to alienate anyone.) Just keep the communcation channels open. That is the key to us all uniting under a MOSA banner. > > > Calling it a MOSA compiler may not be accurate if it has to > > be branched four ways from Sunday in order to work with each > > project. > > No branches. The design and architecture of the jit compiler is > flexible enough to survive differing OS designs, calling conventions > etc. I don't want to call it a piece of art because its not there > yet everywhere, but it will eventually. I hope you haven't bitten off more than you can chew. This is certainly something to look forward to! > > MOSA needs a domain. MOSA needs a mailing list. MOSA needs > > *people*. Then, I think, MOSA can sit down to create > > standards. There is so much to talk about, that I think we > > need some clear, defined space to do it in, so we can track > > what is going on. > > I fully agree with you here. Like Phil said, we're working on it. By we I'm > talking about Adam, Phil, Scott, rootnode and myself. (Sorry if I forgot > someone, > as always I'm on the run.) These are five people with differing interests > and > focus coming from various backgrounds that are actively contributing in > various > ways there. The space is being worked on, however what hasn't been > discussed > yet > is where we'll start. More on this below. I might have displayed more interest in MOSA from the start (I think I did sign up for a membership on those forums right when they were first created) if it had been a bit more organized, and I know Will was interested - but this isn't the first time we've talked about "getting along" with the other C# OS projects, and we still really haven't proven that it can be done on a meaningful level. > > > When you guys first started talking about MOSA, I didn't > > think about code at all. But code is an understandable > > extension of agreed-upon specifications. Specifications that > > we need to take time, space, and conversation to figure out. > > The MOSA AOT is fascinating and exciting, but conversations > > about it are moot for now. > > This is the point where my opinion differs by far from yours. I consider a > compiler and runtime environment *the* two *key* pieces of any effort. I'll stop you right there. At that point of my ramblings, I was more referring to my first impressions of what the idea meant. You've already shown me the light on this regard. > If > your > compiler isn't capable of certain things, then you can't use them. Which > means > that you either start adapting your designs to a lacking compiler (like > SharpOS > is right now) or you freeze those efforts and define a specific set of > features you > need from the compiler in order to do a *good* design. The latter approach > is > IMO the right one and the one I'm pursuing. But as your compiler matures, people will start tinkering with it. And if it has limitations, chances are people will code around it. With no documented standards, we can't even write unit tests to help you out. I want to see this compiler soar - but its going to take some bearucratic processes to pave the way. Otherwise, it isn't any different than the path the SharpOS' AOT took. (A lone developer dropping a black box on hungry kernel-coders-to-be.) > And please stop talking about the > compiler as an AOT - in fact it is not. Oh goodness. I didn't mean it as an insult - its just from habit. We all spent alot of time here with our AOT - and we've seen other projects try the "Its a magical box that compiles your code to anything" thing, and that project ended up re-prioritizing (for that time being.) Its no small feat - and I don't envy the tasks you have in front of you. > And one of my next contributions > will add > jit trampolines I like trampolines. They make me happy! I know you won't agree with me on some of these thoughts and this is really > ok. I think we agree more than I let on. But since I don't have the time to help you code, (which I really wish I could do), I'm at least taking the time to suggest how this needs to be handled administratively. |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 12:22:54
|
Very nice. Could have used that at my last job (no firewall problems now)... |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 12:20:23
|
>From first impressions, I'm not opposed to the idea. But then we'd all have to agree on some really fine details... |
|
From: Bruce M. <ill...@gm...> - 2008-08-06 12:16:00
|
And to follow up on Zachery - I agree. I always thought of MOSA being more about standards and less about code. A MOSA compiler is a great idea - and it will probably involve some standard libs that a MOSA kernel might need to tap into (to use, for example, the "Intrinsic" attribute that grover exampled earlier) to use the compiler. And maybe, down the road, we can agree in enough commonalities for a HAL and a JIT (well, of course the JIT, if we all end up using a common compiler), that we will have more interfaces that we will either need to implement or code against. (But no standard implementations.) I think though, for now, the MOSA compiler having some sort of simple kernel with it, is making the compiler easier to develop. I believe it was grover that pointed out that because of the way SharpOS expects to be AOTed, the MOSA compiler can't really handle us yet. |
|
From: Jonathan D. <jon...@gm...> - 2008-08-06 09:10:58
|
Hi All, Something to put up on your Wiki. Go to http://www.mibbit.com/widget.html and set up a widget and provide a link in your wiki. Look at http://www.ensemble-os.org/wiki/core/IRC_Channel for more info. It helps with people (like me) who are behind a firewall. -- Jonathan |
|
From: Jonathan D. <jon...@gm...> - 2008-08-06 07:53:22
|
Hi All,
I initially started writing a response to my previous post, but this
makes more sense in a new one. Sorry for so many posts :P.
How about writing a CIL bootSTRAPPER? I.e. not a drop-in replacement
for GRUB, but something that would allow us to at least get the boring
stuff out of the way (GDT and whatnot). This the boot process would
be:
GRUB [Loads]
o MOSA CIL Bootstrapper (Native) [Loads via cfg]
x Bootstrap Drivers (Native)
x JIT (Native)
x Scheduler (Managed)
x GC (Managed)
x Kernel (Managed) [Loads]
:: HAL (Managed) [Loads]
o Drivers (Managed)
:: ...
:: Userland (Managed)
I am sure you get the idea.
Each team could then make their own JITters, GCers, and Kernels while
keeping the mundane at bay: instead of writing a unified kernel. Is
that a win-win situation for everyone?
--
Jonathan
|
|
From: Zachary G. <dra...@gm...> - 2008-08-06 07:26:46
|
First off, let's remember that not all of us want some single kernel acting as the foundation. I'd much prefer both projects to have the freedom to do radically different things in the kernel. I believe it is possible to create a set of interfaces that could be the same in both so we can exchange kernel components however we like between the two projects, but that's about as far as we should go in that area. |
|
From: Jonathan D. <jon...@gm...> - 2008-08-06 07:19:25
|
Great to have someone working on the new compiler!!! Not all of us can manage it :). Good luck with your last semester (I assume BSc CS is also 6 semesters in Germany). On Tue, Aug 5, 2008 at 1:39 PM, Simon Wollwage <sim...@ya...> wrote: > Hi everyone, > > since I'm new I'll introduce myself a bit. My name is rootnode (Simon > Wollwage) > and I'm helping grover with the MOSA compiler. > I'm a B.Sc. student of computer science and mathematics in my 5th > semester at RWTH Aachen University, Germany. So far about my background. > > Thath's all for now to keep my introduction short . > > I hope I can be of help within this project. > -------------------------------------- > For All Sports Lovers! SPORTS OHEN PROJECT 2008 > http://pr.mail.yahoo.co.jp/yells/ > > ------------------------------------------------------------------------- > 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 |
|
From: Jonathan D. <jon...@gm...> - 2008-08-06 07:16:35
|
Hi All, Mike has a really good idea with the whole common kernel idea, but there is a small identity crisis. If we consider that Ensemble and SharpOS will become distros of the new MOSA kernel: it doesn't really make sense. Firstly, MOSA does not mean CIL, it means Managed: so JNode/whatnot would be mutually excluded if we called the kernel MOSA kernel. Which brings me to my second point: Managed Operating System Alliance Kernel doesn't really make sense. The kernel should be [Insert Name Here] Kernel (MOSA Affiliated) or something like that. So in my opinion we should give the whole project it's own name, exactly like the Linux == Gentoo/Mandrake/Debian/Suse/etc idea. SharpOS and Ensemble should become distros (but I think they go beyond being just another distribution: but the concept is there). The problem is that we don't have a BDFL (like Linus), and with issues like these you may just get flame wars and stuff starting out. While a democracy works nicely, time and time again we have seen that it doesn't work too often with software projects: you always need a guy at the top who can aye, vito and bring down a hammer of justice of no remorse (Linus might have a questionable personality, but he does do this job extremely well). As far as the kernel goes I think we need a BDFL: so that we can grapple with issues such as naming (and hopefully side-step flaming). It looks like people such as Mike and Phil have the interests of all the projects in mind: my (humbled) opinion is that it should be one of them. However, there are people who have been around for much, much longer but have since slowed down in terms of interacting with the original project: would these people be insulted by the fact that they are not considered? For example, the instigator of the whole effort (I forget his name) has been MIA for ages now. Maybe he should be contacted as asked to designate a new BDFL? It's a hairy topic, but it will probably pay off to do this in the long run. Hopefully we don't get the same rivalry as the Linux distros do (I know I have been a major contributor to this rivalry, but hopefully my recent actions are showing that I am seeking to make ammends) and can all get along reasonably well. Sorry for rambling. -- Jonathan |
|
From: Matthijs t. W. <mat...@gm...> - 2008-08-06 07:01:35
|
It's technically not too hard to do: you need to have the binary format support, and implement the libraries it needs (c-lib, etc). Something like this is also done for the CrossKylix project, which makes it possible to run the Kylix compiler (Delphi compiler for Linux) on windows. -----Original Message----- From: sha...@li... [mailto:sha...@li...] On Behalf Of Jonathan Dickinson Sent: woensdag 6 augustus 2008 8:50 To: sha...@li... Subject: Re: [SharpOS Developers] Linking with native libraries (was TrueType Fonts) Just to make sure we are all on the same page, the point of having native libs is so that we can have a better start up time (i.e. True Type fonts, MySQL client, etc.). In the end (2 years on, or whatever) we should pull the support out of the compiler: or leave it in as a enduring experimental feature (i.e. don't cry when it breaks). There are obviously issues with security AND interaction between the .Net runtime, but it will definitely help out in the beginning. If it will take too long to implement there is probably little point, in my view it should be one of those things that we either get done really quickly or never done at all. On Tue, Aug 5, 2008 at 6:51 PM, grover <sh...@mi...> wrote: > Hi Jonathan, > > Inlining native libraries is difficult to say the least. I have not > thought about it as I consider this really dangerous to say the least. > > You'd have to process all emitted code and either link with the external > library or copy the code from it. Finally these libraries aren't standalone > but do require either the C runtime library, another runtime library or > operating system services - essentially some sort of Posix compliance. > > I don't think that will happen soon. How do others think about this? > > Mike > >> -----Ursprüngliche Nachricht----- >> Von: sha...@li... >> [mailto:sha...@li...] Im >> Auftrag von Jonathan Dickinson >> Gesendet: Dienstag, 5. August 2008 15:59 >> An: sha...@li... >> Betreff: Re: [SharpOS Developers] True Type Fonts >> >> I said this on the Cosmos ML, I suppose I should have said it >> everywhere. The point of this TTF stuff is that I will >> co-incide with completion of System.Drawing namespaces (and >> the start of userland as a whole). It will rely heavily on >> Regions and Paths and what not, we will need those types of >> things first. So it is a looong way off. >> >> Honestly, it is really on the back-burner at the moment as I >> have a quite a bit of work at work, and working with TTF can >> drive a person crazy. If anyone has a Hazmat suit for me >> maybe I could dedicate more time to it :). >> >> If someone wants to hack System.Drawing support on the >> current stuff feel free, I will try and get this thing >> working faster if that's the case. >> >> Has anyone thought about inlining native libs (via P/Invoke) >> so that we can use FreeType (which I am now considering just >> porting) and Cairo? The Google Javascript OS does that and it >> looks like it works pretty well... I know there is a certain >> philosophy with the whole C# only idea, but this would give >> us a boost so that we don't have to worry about >> mundane/arcane things (like TTF): we could port the libs >> later on. Mike, any chance of this stuff? >> >> On Fri, Aug 1, 2008 at 9:04 PM, Sander van Rossen >> <s.v...@sy...> wrote: >> > 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 >> > >> > >> ---------------------------------------------------------------------- >> > --- 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 >> >> -------------------------------------------------------------- >> ----------- >> 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 ------------------------------------------------------------------------- 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 |
|
From: Jonathan D. <jon...@gm...> - 2008-08-06 06:49:53
|
Just to make sure we are all on the same page, the point of having native libs is so that we can have a better start up time (i.e. True Type fonts, MySQL client, etc.). In the end (2 years on, or whatever) we should pull the support out of the compiler: or leave it in as a enduring experimental feature (i.e. don't cry when it breaks). There are obviously issues with security AND interaction between the .Net runtime, but it will definitely help out in the beginning. If it will take too long to implement there is probably little point, in my view it should be one of those things that we either get done really quickly or never done at all. On Tue, Aug 5, 2008 at 6:51 PM, grover <sh...@mi...> wrote: > Hi Jonathan, > > Inlining native libraries is difficult to say the least. I have not > thought about it as I consider this really dangerous to say the least. > > You'd have to process all emitted code and either link with the external > library or copy the code from it. Finally these libraries aren't standalone > but do require either the C runtime library, another runtime library or > operating system services - essentially some sort of Posix compliance. > > I don't think that will happen soon. How do others think about this? > > Mike > >> -----Ursprüngliche Nachricht----- >> Von: sha...@li... >> [mailto:sha...@li...] Im >> Auftrag von Jonathan Dickinson >> Gesendet: Dienstag, 5. August 2008 15:59 >> An: sha...@li... >> Betreff: Re: [SharpOS Developers] True Type Fonts >> >> I said this on the Cosmos ML, I suppose I should have said it >> everywhere. The point of this TTF stuff is that I will >> co-incide with completion of System.Drawing namespaces (and >> the start of userland as a whole). It will rely heavily on >> Regions and Paths and what not, we will need those types of >> things first. So it is a looong way off. >> >> Honestly, it is really on the back-burner at the moment as I >> have a quite a bit of work at work, and working with TTF can >> drive a person crazy. If anyone has a Hazmat suit for me >> maybe I could dedicate more time to it :). >> >> If someone wants to hack System.Drawing support on the >> current stuff feel free, I will try and get this thing >> working faster if that's the case. >> >> Has anyone thought about inlining native libs (via P/Invoke) >> so that we can use FreeType (which I am now considering just >> porting) and Cairo? The Google Javascript OS does that and it >> looks like it works pretty well... I know there is a certain >> philosophy with the whole C# only idea, but this would give >> us a boost so that we don't have to worry about >> mundane/arcane things (like TTF): we could port the libs >> later on. Mike, any chance of this stuff? >> >> On Fri, Aug 1, 2008 at 9:04 PM, Sander van Rossen >> <s.v...@sy...> wrote: >> > 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 >> > >> > >> ---------------------------------------------------------------------- >> > --- 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 >> >> -------------------------------------------------------------- >> ----------- >> 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 |
|
From: grover <sh...@mi...> - 2008-08-05 16:56:08
|
Hi Iraklis, Welcome to the mailing list. I can't suggest an activity for you and I'm sure others feel the same way. If you want to contribute, just read the mailing list and if an interesting topic crops up that you think is worthwile to pursue, go ahead and get involved there. There's a lot of work to do everywhere. Mike > -----Ursprüngliche Nachricht----- > Von: sha...@li... > [mailto:sha...@li...] Im > Auftrag von Iraklis Karagkiozoglou > Gesendet: Dienstag, 5. August 2008 13:17 > An: sha...@li... > Betreff: [SharpOS Developers] Hello guys > > I am new here, i am 16 years old. i know c, vb6, vb.net and > now i am learnig c#. > i dont know thinks about the kernel but i want to help. > > so what do u suggest me?? from where to start?? thanks :) > > PS > sorry for my english i speak them in the greek way :) > > Iraklis Karagkiozoglou > > |
|
From: grover <sh...@mi...> - 2008-08-05 16:51:20
|
Hi Jonathan, Inlining native libraries is difficult to say the least. I have not thought about it as I consider this really dangerous to say the least. You'd have to process all emitted code and either link with the external library or copy the code from it. Finally these libraries aren't standalone but do require either the C runtime library, another runtime library or operating system services - essentially some sort of Posix compliance. I don't think that will happen soon. How do others think about this? Mike > -----Ursprüngliche Nachricht----- > Von: sha...@li... > [mailto:sha...@li...] Im > Auftrag von Jonathan Dickinson > Gesendet: Dienstag, 5. August 2008 15:59 > An: sha...@li... > Betreff: Re: [SharpOS Developers] True Type Fonts > > I said this on the Cosmos ML, I suppose I should have said it > everywhere. The point of this TTF stuff is that I will > co-incide with completion of System.Drawing namespaces (and > the start of userland as a whole). It will rely heavily on > Regions and Paths and what not, we will need those types of > things first. So it is a looong way off. > > Honestly, it is really on the back-burner at the moment as I > have a quite a bit of work at work, and working with TTF can > drive a person crazy. If anyone has a Hazmat suit for me > maybe I could dedicate more time to it :). > > If someone wants to hack System.Drawing support on the > current stuff feel free, I will try and get this thing > working faster if that's the case. > > Has anyone thought about inlining native libs (via P/Invoke) > so that we can use FreeType (which I am now considering just > porting) and Cairo? The Google Javascript OS does that and it > looks like it works pretty well... I know there is a certain > philosophy with the whole C# only idea, but this would give > us a boost so that we don't have to worry about > mundane/arcane things (like TTF): we could port the libs > later on. Mike, any chance of this stuff? > > On Fri, Aug 1, 2008 at 9:04 PM, Sander van Rossen > <s.v...@sy...> wrote: > > 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 > > > > > ---------------------------------------------------------------------- > > --- 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 > > -------------------------------------------------------------- > ----------- > 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 > |
|
From: grover <sh...@mi...> - 2008-08-05 16:39:56
|
Hi Bruce, Answers inline. > -----Ursprüngliche Nachricht----- > Von: sha...@li... > [mailto:sha...@li...] Im > Auftrag von Bruce Markham > Gesendet: Dienstag, 5. August 2008 17:22 > An: sha...@li... > Betreff: Re: [SharpOS Developers] MOSA / AOT > > Okay, before anyone starts marking their scents on the ground > - (I'm stopping you so I can get mine in there first) - my > point isn't what looks pretty or doesn't. I understood you right. I'm glad you're contributing your scents ;) > My point is, MOSA needs to agree on how to handle (and how > much to handle) differing paradigms. Grover, I'm glad you > think you agree with me - but you didn't actually address the > blunt of my point. The point being, the MOSA forums are > almost as much of a ghost town as SharpOS is. It may be a > compiler you are writing to contribute to MOSA, but MOSA as a > whole (which in and of itself, is rather undefined), needs to > have an infrastructure on agreeing on standards by which > opinions or guidance can be generated in regards to *any* > compiler, including this new one being written. The MOSA forums are not used much right now. I agree with you there. You see I'm in a weird position - I'm contributing things and trying to drive the effort my way. I've been primarily doing things by communicating with those really interested directly in person and have used the resources SharpOS and Ensemble have provided me with. The infrastructure (like Phil said) is being worked on and will appear sooner or later. > Calling it a MOSA compiler may not be accurate if it has to > be branched four ways from Sunday in order to work with each > project. No branches. The design and architecture of the jit compiler is flexible enough to survive differing OS designs, calling conventions etc. I don't want to call it a piece of art because its not there yet everywhere, but it will eventually. > And maybe - maybe *thats* exactly how "MOSA" wants > to do it. But there just isn't a clear enough definition of > what MOSA is right now, for any of us to know how to feel > about each other's compilers. (After all, we are trying to > eliminate the "mine is bigger than yours" crap so that we can > get along.) Right. I've expressed my opinion about what MOSA is in the past. I can repeat that here: MOSA is an effort to provide at least a toolkit of ready made, tested and well designed components for all .NET CIL based operating system efforts. These components maybe specifications for interoperability, source code or other services. My personal belief is that MOSA can consist of standard ready-to-use implementations of several operating system services, which if used together result in a nice kernel. However the goal there is to make every part replacable (like they are in the current compiler!) so that every project can decide to pick this, that or roll its own if it doesn't see the ready-made things fit. > MOSA needs a domain. MOSA needs a mailing list. MOSA needs > *people*. Then, I think, MOSA can sit down to create > standards. There is so much to talk about, that I think we > need some clear, defined space to do it in, so we can track > what is going on. I fully agree with you here. Like Phil said, we're working on it. By we I'm talking about Adam, Phil, Scott, rootnode and myself. (Sorry if I forgot someone, as always I'm on the run.) These are five people with differing interests and focus coming from various backgrounds that are actively contributing in various ways there. The space is being worked on, however what hasn't been discussed yet is where we'll start. More on this below. > When you guys first started talking about MOSA, I didn't > think about code at all. But code is an understandable > extension of agreed-upon specifications. Specifications that > we need to take time, space, and conversation to figure out. > The MOSA AOT is fascinating and exciting, but conversations > about it are moot for now. This is the point where my opinion differs by far from yours. I consider a compiler and runtime environment *the* two *key* pieces of any effort. If your compiler isn't capable of certain things, then you can't use them. Which means that you either start adapting your designs to a lacking compiler (like SharpOS is right now) or you freeze those efforts and define a specific set of features you need from the compiler in order to do a *good* design. The latter approach is IMO the right one and the one I'm pursuing. I have a design of a lot of these things in my mind and the compiler is the core puzzle pieces - the first one of a larger puzzle. The MOSA driver model Phil works on builds on a set of features none of the existing CIL-to-native compilers have - but it's design is very much .NET. It is using attributes, interfaces, abstract base classes etc. Things that make .NET pretty in contrast to the unmanaged world. And please stop talking about the compiler as an AOT - in fact it is not. And one of my next contributions will add jit trampolines and dynamic compilation *on Windows*. It is a jit in the disguise of an AOT - and they will even differ a lot due to the use of different compilation pipelines. I know you won't agree with me on some of these thoughts and this is really ok. Mike |
|
From: Phil G. <ph...@th...> - 2008-08-05 15:38:51
|
On Tue, Aug 5, 2008 at 8:22 AM, Bruce Markham <ill...@gm...> wrote: > > MOSA needs a domain. MOSA needs a mailing list. MOSA needs *people*. Then, > I think, MOSA can sit down to create standards. > You are correct and we are working on it. We already got a domain already and we are working out the hosting resources now. - Phil |
44 messages has been excluded from this view by a project administrator.