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: Sander v. R. <san...@gm...> - 2007-08-29 08:02:50
|
Well this time i -did- receive my own email this time.. don't know why i didn't get it the last time.. The 2nd attempt also shows up in the archives properly this time.. sourceforge glitch? On 8/29/07, Pieter Mees <pie...@in...> wrote: > It's normal that you don't receive your own mails from the mailing list. > I believe you can configure this in your subscription on SF. I received > that mail on Tuesday. > > Insite Mees-Delbeke VOF > Zomerstraat 29A > 9270 Laarne > Telefoon: 09 367 96 34 > GSM: 0478 44 96 04 > E-mail: pie...@in... > Site: http://www.insitehosting.be > > > -----Original Message----- > From: sha...@li... > [mailto:sha...@li...] On Behalf Of > Sander van Rossen > Sent: woensdag 29 augustus 2007 9:55 > To: sha...@li... > Subject: [SharpOS Developers] about sharpws / keymap (2nd attempt) > > Odd... i send this email to the mailing list a couple of days ago.. > but it never returned to me (is that normal behaviour?) > On the other hand i can see the title of the mail on the sourceforge > mailing list page, but the mail itself doesn't show up when i click it > and browse trough all the emails... weird huh? > > ---------- Forwarded message ---------- > From: Sander van Rossen <san...@gm...> > Date: Aug 28, 2007 4:09 PM > Subject: sharpws / keymap etc. > To: Sha...@li... > > > I've been working at a client the last month and things have been way > too busy for me to contribute to sharpos.. (or give enough attention > to my family) > but from next week on (i hope) i'll have more time to spend on sharpos > once again. > (and my family ;)) > > > > I noticed the complete overhaul in the repository.. wow, lots of changes > looks good :) > too bad it doesn't run too well tough :-/ > but i guess that will be fixed soon.. > > > > I spend a little time on sharpws, cleaned things a bit up so that it > actually compiles ;) > still doesn't run tough. > I was thinking tough.. right now sharpws has a library called sharpws > and an executable called sharpws-server.. > now it's not entirely clear, but it looks like the library has some > client and common code.. > maybe it's better to have 3 parts instead of 2; > the client, the server and the host. > > The host is basically the actuall machine, the hardware if you will.. > here are all the things that the client / server have in common and > where they get all their resources from. > The client and server parts only handle the protocol part of it all > basically. > > This way it should also be simpler to have multiple servers and > multiple clients, which could be usefull at some point. > > I'm also really concerned about font rendering, i did a bit of > research into it a while ago and to say it's complicated is an > understatement.. it's a whole research field on it's own! > I think it's best to use bitmapped fonts for a while, and maybe > eventually try to port (eek!) something like freetype to get proper > font rendering working.. > > > > Also, i looked at the keymapping part and i realized that besides > numlock mode is basically more or less the same (from a keymapping > pov) as capslock mode. > Also, the meanings of some keys are also different when you press > ctrl, like pause/break etc. > > Which just makes me feel that key maps might need to be more flexible > and handle as much 'modes' as they need. > I haven't put much tought in it tough, just made the observation. > > > > I'm sure you all the papers on singularity, they have some interesting > ideas on having driver manifests that define which ports/irq/dma's > etc. the drivers use.. > Which helps automatically check at install time if drivers would have > conflicts, and helps port/irq/dma resource management.. > Shouldn't be too hard to implement something simular using stubs and > attributes.. > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > |
From: Pieter M. <pie...@in...> - 2007-08-29 07:58:34
|
It's normal that you don't receive your own mails from the mailing list. I believe you can configure this in your subscription on SF. I received that mail on Tuesday. Insite Mees-Delbeke VOF Zomerstraat 29A 9270 Laarne Telefoon: 09 367 96 34 GSM: 0478 44 96 04 E-mail: pie...@in... Site: http://www.insitehosting.be -----Original Message----- From: sha...@li... [mailto:sha...@li...] On Behalf Of Sander van Rossen Sent: woensdag 29 augustus 2007 9:55 To: sha...@li... Subject: [SharpOS Developers] about sharpws / keymap (2nd attempt) Odd... i send this email to the mailing list a couple of days ago.. but it never returned to me (is that normal behaviour?) On the other hand i can see the title of the mail on the sourceforge mailing list page, but the mail itself doesn't show up when i click it and browse trough all the emails... weird huh? ---------- Forwarded message ---------- From: Sander van Rossen <san...@gm...> Date: Aug 28, 2007 4:09 PM Subject: sharpws / keymap etc. To: Sha...@li... I've been working at a client the last month and things have been way too busy for me to contribute to sharpos.. (or give enough attention to my family) but from next week on (i hope) i'll have more time to spend on sharpos once again. (and my family ;)) I noticed the complete overhaul in the repository.. wow, lots of changes looks good :) too bad it doesn't run too well tough :-/ but i guess that will be fixed soon.. I spend a little time on sharpws, cleaned things a bit up so that it actually compiles ;) still doesn't run tough. I was thinking tough.. right now sharpws has a library called sharpws and an executable called sharpws-server.. now it's not entirely clear, but it looks like the library has some client and common code.. maybe it's better to have 3 parts instead of 2; the client, the server and the host. The host is basically the actuall machine, the hardware if you will.. here are all the things that the client / server have in common and where they get all their resources from. The client and server parts only handle the protocol part of it all basically. This way it should also be simpler to have multiple servers and multiple clients, which could be usefull at some point. I'm also really concerned about font rendering, i did a bit of research into it a while ago and to say it's complicated is an understatement.. it's a whole research field on it's own! I think it's best to use bitmapped fonts for a while, and maybe eventually try to port (eek!) something like freetype to get proper font rendering working.. Also, i looked at the keymapping part and i realized that besides numlock mode is basically more or less the same (from a keymapping pov) as capslock mode. Also, the meanings of some keys are also different when you press ctrl, like pause/break etc. Which just makes me feel that key maps might need to be more flexible and handle as much 'modes' as they need. I haven't put much tought in it tough, just made the observation. I'm sure you all the papers on singularity, they have some interesting ideas on having driver manifests that define which ports/irq/dma's etc. the drivers use.. Which helps automatically check at install time if drivers would have conflicts, and helps port/irq/dma resource management.. Shouldn't be too hard to implement something simular using stubs and attributes.. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list Sha...@li... https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
From: Sander v. R. <san...@gm...> - 2007-08-29 07:54:53
|
Odd... i send this email to the mailing list a couple of days ago.. but it never returned to me (is that normal behaviour?) On the other hand i can see the title of the mail on the sourceforge mailing list page, but the mail itself doesn't show up when i click it and browse trough all the emails... weird huh? ---------- Forwarded message ---------- From: Sander van Rossen <san...@gm...> Date: Aug 28, 2007 4:09 PM Subject: sharpws / keymap etc. To: Sha...@li... I've been working at a client the last month and things have been way too busy for me to contribute to sharpos.. (or give enough attention to my family) but from next week on (i hope) i'll have more time to spend on sharpos once again. (and my family ;)) I noticed the complete overhaul in the repository.. wow, lots of changes looks good :) too bad it doesn't run too well tough :-/ but i guess that will be fixed soon.. I spend a little time on sharpws, cleaned things a bit up so that it actually compiles ;) still doesn't run tough. I was thinking tough.. right now sharpws has a library called sharpws and an executable called sharpws-server.. now it's not entirely clear, but it looks like the library has some client and common code.. maybe it's better to have 3 parts instead of 2; the client, the server and the host. The host is basically the actuall machine, the hardware if you will.. here are all the things that the client / server have in common and where they get all their resources from. The client and server parts only handle the protocol part of it all basically. This way it should also be simpler to have multiple servers and multiple clients, which could be usefull at some point. I'm also really concerned about font rendering, i did a bit of research into it a while ago and to say it's complicated is an understatement.. it's a whole research field on it's own! I think it's best to use bitmapped fonts for a while, and maybe eventually try to port (eek!) something like freetype to get proper font rendering working.. Also, i looked at the keymapping part and i realized that besides numlock mode is basically more or less the same (from a keymapping pov) as capslock mode. Also, the meanings of some keys are also different when you press ctrl, like pause/break etc. Which just makes me feel that key maps might need to be more flexible and handle as much 'modes' as they need. I haven't put much tought in it tough, just made the observation. I'm sure you all the papers on singularity, they have some interesting ideas on having driver manifests that define which ports/irq/dma's etc. the drivers use.. Which helps automatically check at install time if drivers would have conflicts, and helps port/irq/dma resource management.. Shouldn't be too hard to implement something simular using stubs and attributes.. |
From: Pieter M. <pie...@in...> - 2007-08-29 07:46:25
|
Chriss, I don't think anyone here is questioning your contributions. I for one think you've done a great job with developing something like the AOT. Due to the very fact that we don't understand how it really works (yet), makes it impossible for us to check how good it really is. So we can't comment on the quality of your work. By making at least a general architecture design, or even just document its current design a lot more people will have the chance to help you out. Most people can only assist in small areas (due to knowledge or time constraints), so they won't go as far as to read all the code to be able to add some lines. If on the other hand we had some design documents (e.g. a general map of the bytecode->asm flow, some class diagrams, ...) those people will be "in the loop" with much less effort. What we would do here is instead of all of us doing the same work (trying to understand the structure), some of us document it for the rest so they can understand in a fraction of that time. This does not only hold true for AOT, but also for the kernel. I believe we can all agree that good documentation is a MUST to keep everything clear and organizable. So I think the question that has to be answered first is: Do we continue development and start documenting by following its trail? Or do we ask Chriss and the others to halt for a moment so we can all catch up? I think the last option is the best one because otherwise we wouldn't notice architectural problems until it's too late. Just my 2 cents... Insite Mees-Delbeke VOF Zomerstraat 29A 9270 Laarne Telefoon: 09 367 96 34 GSM: 0478 44 96 04 E-mail: pie...@in... Site: http://www.insitehosting.be -----Original Message----- From: sha...@li... [mailto:sha...@li...] On Behalf Of Darx Kies Sent: woensdag 29 augustus 2007 4:23 To: sha...@li... Subject: Re: [SharpOS Developers] Proposal Scott Balmos wrote: > Darx Kies wrote: > =20 >> Scott Balmos wrote: >> =20 >> =20 >>> Chad Z. Hower aka Kudzu wrote: >>> =20 >>> =20 >>> =20 >>>> I'd like to make a few proposals. >>>> >>>> 1) We establish a loose but workable team structure which includes conflict >>>> resolution. >>>> >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>> Someone will probably say this already exists. I don't know. My major=20 >>> recommendation right now is establishment of a build master, who owns=20 >>> the trunk. All changes should be done in local repos. When something >>> should be promoted to the trunk, it is debated here, goes through a code=20 >>> check, and the build master normalizes the code to a coding standard >>> before committing it to the trunk. Trying to get rid of William breaking=20 >>> the kernel again (heh), or our infamous problems of things compiling >>> under Mono but not VStudio or vice versa. >>> >>> Between that, and API / architecture docs before you start coding a=20 >>> major piece. Everyone else can tell you how much I've grumbled lately=20 >>> about not being able to get my VM code going because the trunk repo got=20 >>> reworked, the base kernel's in flux, and the AOT is still buggy. :) >>> =20 >>> =20 >>> =20 >> And now guess why I was begging for test cases and test cases and I=20 >> still do. >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>> 2) We establish a highly documented, well debated kernel design doc. Then >>>> proceed to make the kernel rock solid before putting too much effort into >>>> anything beyond the command line. >>>> >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>> I've been kicking for this for awhile. Currently it's more a code-first,=20 >>> write-architecture-later. The largest part of the system, the compiler,=20 >>> is AOT-only, and only one person knows its architecture. I've been very=20 >>> vocal about that. Don't know if Chriss has gotten anywhere with=20 >>> documenting the architecture. >>> =20 >>> =20 >>> =20 >> Like I already said. The AOT itself is still subject to change, and=20 >> right now I am rewriting parts of it. >> The code is partly documented and it does even have some inline examples=20 >> to make it more understandable >> and I everyone that wants to understand it better just write me on IRC. >> >> =20 >> =20 >>> Personally, I would halt all current kernel-related development, go back=20 >>> and tear back apart the compiler and get that completely rearchitected,=20 >>> redocumented, and retested.=20 >>> =20 >>> =20 >> That is what actually is happening right now, even though I had to=20 >> suspend the work on it for a while.... again. >> >> =20 >> =20 >>> Start with reading in the source bytecode at=20 >>> a method level from multiple sources, whether it's a byte stream, file,=20 >>> whatever. This ensures an easy separation of code into an embeddable JIT=20 >>> engine, with the AOT system simply being a file-feeder shell. Convert to=20 >>> unoptimized IR code, then register transfer code. Spit out direct,=20 >>> unoptimized machine code from there. Possibly hand-verify if necessary=20 >>> the generated machine code. That way we know the basic compiler works=20 >>> and implements all CIL opcodes. Optimizations such as SSA, dead code >>> elimination, loop unwinding, etc can all be implemented as transforms on=20 >>> top of the base IR code stream. From the testing I've seen, I can't tell=20 >>> whether bugs are in simple bytecode conversion or various IR=20 >>> optimization algorithms. They all seem to be intertwined currently. >>> >>> But I'm liable to get my head chopped off by Chriss for the above. :) >>> =20 >>> =20 >>> =20 >> I am not that cruel. ;) >> >> The idea was actually to get something working ASAP so that the ppl that=20 >> wanted to work on the kernel >> can do something too. That is why there are lots of generated test cases=20 >> for the x86 encoding but pertty few test >> cases for the rest of the AOT. I would just suggest to look in the=20 >> source code for the TODO lines and there are >> lots of them. Most of it was just implemented when an exception raised=20 >> because some part was not implemented >> yet. And most of the time the trunk kernel was the main source of code=20 >> to test and develop the AOT. Johann and >> William felt pitiful enough to write test cases.;) Thank you guys! >> >> What I am trying to say is that I am the only one that is working on it=20 >> and any help is more than welcome. >> >> Chriss. >> =20 >> =20 > > Not to be chicken-and-egg, but almost all good test cases cannot be=20 > covered unless there was a set of overall architecture designs. And=20 > getting that written in writing, rather than saying "just talk to me on=20 > IRC", will ultimately benefit us more. Likewise with "just read the=20 > code". That's just not good enough with a multi-member team. Plus, how > will we ever know whether we've written enough unit tests? > =20 We need at least more than 150 that there are now (not counting the x86=20 ones). And besides what I meant were NOT test cases for the AOT internals but for .NET.=20 Just take a look at the current test cases and the test cases for example of mono, pnet and=20 rotor. And once again, yes, I will document the AOT once it is stable and more or less feature=20 complete and when I said "talk to me on IRC" I was saying that I want to help everyone that wants to get involved with the AOT and start document it where needed which was done partly by others as well. > You acknowledge that you're the only one working on it currently, and=20 > would welcome the help. Personally, I'd love to help, as compiler theory=20 > as well as OS design was my emphasis threads in college. But, as Bruce > just noted in his email, everything's black box. You yourself once noted=20 > to me that most of the compiler design was taken from another project of=20 > yours that converted CIL to JavaScript, parts of which you can't=20 > release, and the architecture of which you don't clearly remember. :)=20 > =20 It's not about not being able but not wanting to release it. And I don't get what you mean about not remembering the architecture. > Plus, seeing huge code files that are over 400k in size scares the crap=20 > out of anyone. Heck, you remember my first few weeks of talking. I=20 > couldn't follow much of anything, and it took longer for me to realize > and remember various compiler optimization tricks such as SSA. > > Even now, you're rewriting the compiler.=20 Yes I am rewriting parts of it, which is mostly refactoring, removing=20 some hacks and at the same time I continue to implement the missing parts. And I am=20 also working on making it possible to turn on and off the whole constant propagation, copy=20 propagation, constant folding and so on. > Okay, but again, what=20 > architecture? How is it designed, the flow of code from a bytecode=20 > stream into native platform code? etc. We won't truly know how to test > it unless we know intimately how it is designed to work.=20 Read above about the test cases. > That's the=20 > whole point behind writing a true written architecture document, posted=20 > up on our site. That way everyone knows how it works, everyone knows how=20 > to test it, and everyone knows (generally) where a fix would have to be=20 > made in what code transformation layer in order to fix a bug. Hence also=20 > my advocation of starting out with "raw, unoptimized" code. Layer on the=20 > optimizers one by one as they're tested, in order to minimize the number=20 > of variables when tracking down a bug. > =20 Read the above again. That is what I am working on as well. I am=20 rewriting parts of it to make it more easily for anyone to start working on the AOT. > Again, yeah, we've got a working compiler now and it was produced "just=20 > to get things going". But now we're taking a step back, looking to see > how well everything's designed in the first place (if at all), in order=20 > to make for a better long-term system. > =20 Sorry but that sounds harsh! The AOT is by far not complete and not perfect. And I tried to do my=20 best to contribute to the project instead of whining and doing nothing. Not all of the AOT is a=20 "black box", tough I see no attempt to at least document that for the others, (except the ones by xfury and illuminus). Illuminus for example documented how to write the AOT test cases. And=20 once again, if anyone volunteers to write the documentation of the AOT, yes....., write me on IRC. Everyone does what he cans, as good as he cans, when he cans. Chriss. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list Sha...@li... https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
From: Sander v. R. <san...@gm...> - 2007-08-29 07:34:23
|
I live in the netherlands, capelle aan den ijssel to be exact (=practically rotterdam, rotterdam metro even has several stops here) On 8/28/07, Chad Z. Hower aka Kudzu <Ch...@ho...> wrote: > Also again. :) > > Could everyone enumerate where they are located? :) > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > |
From: Matthijs t. W. <mat...@gm...> - 2007-08-29 06:57:37
|
I'm really interested in this project too, but don't know any assembly, so can only help in the c#/non assembly parts and infrastructural stuff regarding the project.... ----- Original Message ----- From: "Chad Z. Hower aka Kudzu" <Chad@Hower.org> To: <sha...@li...> Sent: Tuesday, August 28, 2007 10:52 PM Subject: Re: [SharpOS Developers] SharpOS name >> http://members.simunex.com/sbalmos/CosmOS.pdf (heh, notice I fell into > > Thanks. Saved for a future plane ride (I have 15 or so long hauls to Asia, > back and forth in Sept) > >> By my count, I think 6 including you? There is no current team > > Which to me is all the more reason we need to establish some sort of > structure now before it grows to big. > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
From: Olexandr M. <om...@gm...> - 2007-08-29 02:47:07
|
THZpdiwgVWtyYWluZQoKb25lIG1vcmUgRXVyb3BlYW4gOikKCk9uIDgvMjkvMDcsIFJvaCBKYWUg SHl1biA8d29uYmVhckBnbWFpbC5jb20+IHdyb3RlOgo+Cj4gSSdtIGluIFNvdXRoIEtvcmVhLiBu b3Qgbm9ydGggOikKPiBJIHRoaW5rIEknbSB0aGUgb25seSBvbmUgd2hvIGxpdmUgaW4gdGhlIGFz aWFuIGNvdW50cnkuCj4KPiBEZW5uaXMgSGF5ZXMg7JO0IOq4gDoKPiA+IFVTLCBHZW9yZ2lhLCBB dGxhbnRhLgo+ID4gRGVubmlzCj4gPgo+ID4KPiA+ICovRGFyeCBLaWVzIDxkYXJ4X2tpZXNAZ214 Lm5ldD4vKiB3cm90ZToKPiA+Cj4gPiAgICAgSGkuCj4gPgo+ID4gICAgIENoYWQgWi4gSG93ZXIg YWthIEt1ZHp1IHdyb3RlOgo+ID4gICAgID4gQWxzbyBhZ2Fpbi4gOikKPiA+ICAgICA+Cj4gPiAg ICAgPiBDb3VsZCBldmVyeW9uZSBlbnVtZXJhdGUgd2hlcmUgdGhleSBhcmUgbG9jYXRlZD8gOikK PiA+ICAgICA+Cj4gPiAgICAgPgo+ID4gICAgIEF1c3RyaWEuIDopCj4gPgo+ID4gICAgIENocmlz cy4KPiA+Cj4gPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICAgICBUaGlzIFNGLm5ldCBlbWFpbCBp cyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuCj4gPiAgICAgU3RpbGwgZ3JlcHBpbmcgdGhyb3Vn aCBsb2cgZmlsZXMgdG8gZmluZCBwcm9ibGVtcz8gU3RvcC4KPiA+ICAgICBOb3cgU2VhcmNoIGxv ZyBldmVudHMgYW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMgdXNpbmcgQUpBWCBhbmQgYQo+ID4gICAg IGJyb3dzZXIuCj4gPiAgICAgRG93bmxvYWQgeW91ciBGUkVFIGNvcHkgb2YgU3BsdW5rIG5vdyA+ PiBodHRwOi8vZ2V0LnNwbHVuay5jb20vCj4gPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+ICAgICBTaGFycE9TLURldmVsb3BlcnMgbWFpbGlu ZyBsaXN0Cj4gPiAgICAgU2hhcnBPUy1EZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+ ID4gICAgIGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NoYXJw b3MtZGV2ZWxvcGVycwo+ID4KPiA+Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+IE1vb2R5IGZyaWVu ZHMuIERyYW1hIHF1ZWVucy4gWW91ciBsaWZlPyBOb3BlISAtIHRoZWlyIGxpZmUsIHlvdXIgc3Rv cnkuCj4gPiBQbGF5IFNpbXMgU3RvcmllcyBhdCBZYWhvbyEgR2FtZXMuCj4gPiA8aHR0cDovL3Vz LnJkLnlhaG9vLmNvbS9ldnQ9NDgyMjQvKmh0dHA6Ly9zaW1zLnlhaG9vLmNvbS8+Cj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KPiA+Cj4gPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+IFRoaXMgU0YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5rIEluYy4KPiA+IFN0aWxsIGdyZXBwaW5nIHRocm91 Z2ggbG9nIGZpbGVzIHRvIGZpbmQgcHJvYmxlbXM/ICBTdG9wLgo+ID4gTm93IFNlYXJjaCBsb2cg ZXZlbnRzIGFuZCBjb25maWd1cmF0aW9uIGZpbGVzIHVzaW5nIEFKQVggYW5kIGEgYnJvd3Nlci4K PiA+IERvd25sb2FkIHlvdXIgRlJFRSBjb3B5IG9mIFNwbHVuayBub3cgPj4gIGh0dHA6Ly9nZXQu c3BsdW5rLmNvbS8KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBTaGFycE9TLURldmVsb3BlcnMgbWFp bGluZyBsaXN0Cj4gPiBTaGFycE9TLURldmVsb3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4g PiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zaGFycG9zLWRl dmVsb3BlcnMKPiA+Cj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUaGlzIFNGLm5ldCBlbWFpbCBp cyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuCj4gU3RpbGwgZ3JlcHBpbmcgdGhyb3VnaCBsb2cg ZmlsZXMgdG8gZmluZCBwcm9ibGVtcz8gIFN0b3AuCj4gTm93IFNlYXJjaCBsb2cgZXZlbnRzIGFu ZCBjb25maWd1cmF0aW9uIGZpbGVzIHVzaW5nIEFKQVggYW5kIGEgYnJvd3Nlci4KPiBEb3dubG9h ZCB5b3VyIEZSRUUgY29weSBvZiBTcGx1bmsgbm93ID4+ICBodHRwOi8vZ2V0LnNwbHVuay5jb20v Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBTaGFy cE9TLURldmVsb3BlcnMgbWFpbGluZyBsaXN0Cj4gU2hhcnBPUy1EZXZlbG9wZXJzQGxpc3RzLnNv dXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp bmZvL3NoYXJwb3MtZGV2ZWxvcGVycwo+CgoKCi0tIApTaW5jZXJlbHkgeW91cnMsCk9sZXhhbmRy IE1lbG55awpodHRwOi8vb21lbG55ay5uZXQvCg== |
From: Roh J. H. <wo...@gm...> - 2007-08-29 02:28:57
|
I'm in South Korea. not north :) I think I'm the only one who live in the asian country. Dennis Hayes 쓴 글: > US, Georgia, Atlanta. > Dennis > > > */Darx Kies <dar...@gm...>/* wrote: > > Hi. > > Chad Z. Hower aka Kudzu wrote: > > Also again. :) > > > > Could everyone enumerate where they are located? :) > > > > > Austria. :) > > Chriss. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > > ------------------------------------------------------------------------ > Moody friends. Drama queens. Your life? Nope! - their life, your story. > Play Sims Stories at Yahoo! Games. > <http://us.rd.yahoo.com/evt=48224/*http://sims.yahoo.com/> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-29 02:28:28
|
> Like I already said. The AOT itself is still subject to change, and > right now I am rewriting parts of it. > The code is partly documented and it does even have some inline > examples > to make it more understandable > and I everyone that wants to understand it better just write me on IRC. It will likely be Nov before I could so any serious work. But I spent several hours tonight digging through mostly AOT with Scott helping me navigate. We can greatly simplify AOT in many areas. AOT is critical to get right and I think we must address it very soon. In addition, the method of using the attributes to match up unsafe code into safe code. There are more expedient ways to do this which also include static checking of interfaces which is not present now. |
From: Darx K. <dar...@gm...> - 2007-08-29 02:22:48
|
Scott Balmos wrote: > Darx Kies wrote: > >> Scott Balmos wrote: >> >> >>> Chad Z. Hower aka Kudzu wrote: >>> >>> >>> >>>> I'd like to make a few proposals. >>>> >>>> 1) We establish a loose but workable team structure which includes conflict >>>> resolution. >>>> >>>> >>>> >>>> >>>> >>> Someone will probably say this already exists. I don't know. My major >>> recommendation right now is establishment of a build master, who owns >>> the trunk. All changes should be done in local repos. When something >>> should be promoted to the trunk, it is debated here, goes through a code >>> check, and the build master normalizes the code to a coding standard >>> before committing it to the trunk. Trying to get rid of William breaking >>> the kernel again (heh), or our infamous problems of things compiling >>> under Mono but not VStudio or vice versa. >>> >>> Between that, and API / architecture docs before you start coding a >>> major piece. Everyone else can tell you how much I've grumbled lately >>> about not being able to get my VM code going because the trunk repo got >>> reworked, the base kernel's in flux, and the AOT is still buggy. :) >>> >>> >>> >> And now guess why I was begging for test cases and test cases and I >> still do. >> >> >>> >>> >>> >>>> 2) We establish a highly documented, well debated kernel design doc. Then >>>> proceed to make the kernel rock solid before putting too much effort into >>>> anything beyond the command line. >>>> >>>> >>>> >>>> >>>> >>> I've been kicking for this for awhile. Currently it's more a code-first, >>> write-architecture-later. The largest part of the system, the compiler, >>> is AOT-only, and only one person knows its architecture. I've been very >>> vocal about that. Don't know if Chriss has gotten anywhere with >>> documenting the architecture. >>> >>> >>> >> Like I already said. The AOT itself is still subject to change, and >> right now I am rewriting parts of it. >> The code is partly documented and it does even have some inline examples >> to make it more understandable >> and I everyone that wants to understand it better just write me on IRC. >> >> >> >>> Personally, I would halt all current kernel-related development, go back >>> and tear back apart the compiler and get that completely rearchitected, >>> redocumented, and retested. >>> >>> >> That is what actually is happening right now, even though I had to >> suspend the work on it for a while.... again. >> >> >> >>> Start with reading in the source bytecode at >>> a method level from multiple sources, whether it's a byte stream, file, >>> whatever. This ensures an easy separation of code into an embeddable JIT >>> engine, with the AOT system simply being a file-feeder shell. Convert to >>> unoptimized IR code, then register transfer code. Spit out direct, >>> unoptimized machine code from there. Possibly hand-verify if necessary >>> the generated machine code. That way we know the basic compiler works >>> and implements all CIL opcodes. Optimizations such as SSA, dead code >>> elimination, loop unwinding, etc can all be implemented as transforms on >>> top of the base IR code stream. From the testing I've seen, I can't tell >>> whether bugs are in simple bytecode conversion or various IR >>> optimization algorithms. They all seem to be intertwined currently. >>> >>> But I'm liable to get my head chopped off by Chriss for the above. :) >>> >>> >>> >> I am not that cruel. ;) >> >> The idea was actually to get something working ASAP so that the ppl that >> wanted to work on the kernel >> can do something too. That is why there are lots of generated test cases >> for the x86 encoding but pertty few test >> cases for the rest of the AOT. I would just suggest to look in the >> source code for the TODO lines and there are >> lots of them. Most of it was just implemented when an exception raised >> because some part was not implemented >> yet. And most of the time the trunk kernel was the main source of code >> to test and develop the AOT. Johann and >> William felt pitiful enough to write test cases.;) Thank you guys! >> >> What I am trying to say is that I am the only one that is working on it >> and any help is more than welcome. >> >> Chriss. >> >> > > Not to be chicken-and-egg, but almost all good test cases cannot be > covered unless there was a set of overall architecture designs. And > getting that written in writing, rather than saying "just talk to me on > IRC", will ultimately benefit us more. Likewise with "just read the > code". That's just not good enough with a multi-member team. Plus, how > will we ever know whether we've written enough unit tests? > We need at least more than 150 that there are now (not counting the x86 ones). And besides what I meant were NOT test cases for the AOT internals but for .NET. Just take a look at the current test cases and the test cases for example of mono, pnet and rotor. And once again, yes, I will document the AOT once it is stable and more or less feature complete and when I said "talk to me on IRC" I was saying that I want to help everyone that wants to get involved with the AOT and start document it where needed which was done partly by others as well. > You acknowledge that you're the only one working on it currently, and > would welcome the help. Personally, I'd love to help, as compiler theory > as well as OS design was my emphasis threads in college. But, as Bruce > just noted in his email, everything's black box. You yourself once noted > to me that most of the compiler design was taken from another project of > yours that converted CIL to JavaScript, parts of which you can't > release, and the architecture of which you don't clearly remember. :) > It's not about not being able but not wanting to release it. And I don't get what you mean about not remembering the architecture. > Plus, seeing huge code files that are over 400k in size scares the crap > out of anyone. Heck, you remember my first few weeks of talking. I > couldn't follow much of anything, and it took longer for me to realize > and remember various compiler optimization tricks such as SSA. > > Even now, you're rewriting the compiler. Yes I am rewriting parts of it, which is mostly refactoring, removing some hacks and at the same time I continue to implement the missing parts. And I am also working on making it possible to turn on and off the whole constant propagation, copy propagation, constant folding and so on. > Okay, but again, what > architecture? How is it designed, the flow of code from a bytecode > stream into native platform code? etc. We won't truly know how to test > it unless we know intimately how it is designed to work. Read above about the test cases. > That's the > whole point behind writing a true written architecture document, posted > up on our site. That way everyone knows how it works, everyone knows how > to test it, and everyone knows (generally) where a fix would have to be > made in what code transformation layer in order to fix a bug. Hence also > my advocation of starting out with "raw, unoptimized" code. Layer on the > optimizers one by one as they're tested, in order to minimize the number > of variables when tracking down a bug. > Read the above again. That is what I am working on as well. I am rewriting parts of it to make it more easily for anyone to start working on the AOT. > Again, yeah, we've got a working compiler now and it was produced "just > to get things going". But now we're taking a step back, looking to see > how well everything's designed in the first place (if at all), in order > to make for a better long-term system. > Sorry but that sounds harsh! The AOT is by far not complete and not perfect. And I tried to do my best to contribute to the project instead of whining and doing nothing. Not all of the AOT is a "black box", tough I see no attempt to at least document that for the others, (except the ones by xfury and illuminus). Illuminus for example documented how to write the AOT test cases. And once again, if anyone volunteers to write the documentation of the AOT, yes....., write me on IRC. Everyone does what he cans, as good as he cans, when he cans. Chriss. |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 23:45:53
|
> I just signed up. Might as well try it out... scott.balmos Have you on the list now. Skype is really good. I dropped ICQ etc as skype is better and auto connects better. > Though just to get something out of the way, we really should maintain > "official decision making" on this list. One-on-one chats on IRC and IM Yes I agree. But what Im still pitching is that we "formalize" the process of that decision making. ;) For example, in Indy we have a voting process on things that are in dispute, etc. |
From: Scott B. <sb...@me...> - 2007-08-28 23:39:30
|
Chad Z. Hower aka Kudzu wrote: > Not for voice, but in addition to IRC I find skype great for IM. It can do > multichat as well... > > I'm kudzu22 on my dev machine, ziloni on travel. > I just signed up. Might as well try it out... scott.balmos Likewise, I'm ScottBalmos on AIM and 1325000 on ICQ. [TechGuy] on IRC. Though just to get something out of the way, we really should maintain "official decision making" on this list. One-on-one chats on IRC and IM is fine. But there's obviously more of us here on the mailing list who can't meet because of time constraints (heck, I can't even make our usual weekend meetings because I'm taking care of my normal weekend running around. :D). |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 23:05:26
|
> The operable question being what goal is the selected license covering? > Or are we selecting LGPL / GPL simply because it's the most popular OSS > license? I cannot agree with using GPL, again not without a linking > clause. LGPL, for all intents, covers this. The "kernel", runtime, > scheduler, driver framework, etc all would be LGPL, allowing for binary > closed-source drivers and other apps. Again, personally I would rather > go for BSD. But I can understand where people want to force things to > remain open source and attributable. Thus the necessity of commercial > dual-licensing. > > So what is GPL covering that LGPL doesn't, in terms of a microkernel > architecture? +1 on all this - esp the part about GPL. |
From: Scott B. <sb...@me...> - 2007-08-28 23:03:16
|
Darx Kies wrote: > Scott Balmos wrote: > >> Chad Z. Hower aka Kudzu wrote: >> >> >>> I'd like to make a few proposals. >>> >>> 1) We establish a loose but workable team structure which includes conflict >>> resolution. >>> >>> >>> >>> >> Someone will probably say this already exists. I don't know. My major >> recommendation right now is establishment of a build master, who owns >> the trunk. All changes should be done in local repos. When something >> should be promoted to the trunk, it is debated here, goes through a code >> check, and the build master normalizes the code to a coding standard >> before committing it to the trunk. Trying to get rid of William breaking >> the kernel again (heh), or our infamous problems of things compiling >> under Mono but not VStudio or vice versa. >> >> Between that, and API / architecture docs before you start coding a >> major piece. Everyone else can tell you how much I've grumbled lately >> about not being able to get my VM code going because the trunk repo got >> reworked, the base kernel's in flux, and the AOT is still buggy. :) >> >> > And now guess why I was begging for test cases and test cases and I > still do. > >> >> >>> 2) We establish a highly documented, well debated kernel design doc. Then >>> proceed to make the kernel rock solid before putting too much effort into >>> anything beyond the command line. >>> >>> >>> >>> >> I've been kicking for this for awhile. Currently it's more a code-first, >> write-architecture-later. The largest part of the system, the compiler, >> is AOT-only, and only one person knows its architecture. I've been very >> vocal about that. Don't know if Chriss has gotten anywhere with >> documenting the architecture. >> >> > Like I already said. The AOT itself is still subject to change, and > right now I am rewriting parts of it. > The code is partly documented and it does even have some inline examples > to make it more understandable > and I everyone that wants to understand it better just write me on IRC. > > >> Personally, I would halt all current kernel-related development, go back >> and tear back apart the compiler and get that completely rearchitected, >> redocumented, and retested. >> > That is what actually is happening right now, even though I had to > suspend the work on it for a while.... again. > > >> Start with reading in the source bytecode at >> a method level from multiple sources, whether it's a byte stream, file, >> whatever. This ensures an easy separation of code into an embeddable JIT >> engine, with the AOT system simply being a file-feeder shell. Convert to >> unoptimized IR code, then register transfer code. Spit out direct, >> unoptimized machine code from there. Possibly hand-verify if necessary >> the generated machine code. That way we know the basic compiler works >> and implements all CIL opcodes. Optimizations such as SSA, dead code >> elimination, loop unwinding, etc can all be implemented as transforms on >> top of the base IR code stream. From the testing I've seen, I can't tell >> whether bugs are in simple bytecode conversion or various IR >> optimization algorithms. They all seem to be intertwined currently. >> >> But I'm liable to get my head chopped off by Chriss for the above. :) >> >> > I am not that cruel. ;) > > The idea was actually to get something working ASAP so that the ppl that > wanted to work on the kernel > can do something too. That is why there are lots of generated test cases > for the x86 encoding but pertty few test > cases for the rest of the AOT. I would just suggest to look in the > source code for the TODO lines and there are > lots of them. Most of it was just implemented when an exception raised > because some part was not implemented > yet. And most of the time the trunk kernel was the main source of code > to test and develop the AOT. Johann and > William felt pitiful enough to write test cases.;) Thank you guys! > > What I am trying to say is that I am the only one that is working on it > and any help is more than welcome. > > Chriss. > Not to be chicken-and-egg, but almost all good test cases cannot be covered unless there was a set of overall architecture designs. And getting that written in writing, rather than saying "just talk to me on IRC", will ultimately benefit us more. Likewise with "just read the code". That's just not good enough with a multi-member team. Plus, how will we ever know whether we've written enough unit tests? You acknowledge that you're the only one working on it currently, and would welcome the help. Personally, I'd love to help, as compiler theory as well as OS design was my emphasis threads in college. But, as Bruce just noted in his email, everything's black box. You yourself once noted to me that most of the compiler design was taken from another project of yours that converted CIL to JavaScript, parts of which you can't release, and the architecture of which you don't clearly remember. :) Plus, seeing huge code files that are over 400k in size scares the crap out of anyone. Heck, you remember my first few weeks of talking. I couldn't follow much of anything, and it took longer for me to realize and remember various compiler optimization tricks such as SSA. Even now, you're rewriting the compiler. Okay, but again, what architecture? How is it designed, the flow of code from a bytecode stream into native platform code? etc. We won't truly know how to test it unless we know intimately how it is designed to work. That's the whole point behind writing a true written architecture document, posted up on our site. That way everyone knows how it works, everyone knows how to test it, and everyone knows (generally) where a fix would have to be made in what code transformation layer in order to fix a bug. Hence also my advocation of starting out with "raw, unoptimized" code. Layer on the optimizers one by one as they're tested, in order to minimize the number of variables when tracking down a bug. Again, yeah, we've got a working compiler now and it was produced "just to get things going". But now we're taking a step back, looking to see how well everything's designed in the first place (if at all), in order to make for a better long-term system. |
From: Bruce <ill...@gm...> - 2007-08-28 22:53:58
|
On 8/28/07, Darx Kies <dar...@gm...> wrote: > > Scott Balmos wrote: > > Chad Z. Hower aka Kudzu wrote: > > > >> I'd like to make a few proposals. > >> > >> 1) We establish a loose but workable team structure which includes > conflict > >> resolution. > >> > >> > >> > > Someone will probably say this already exists. I don't know. My major > > recommendation right now is establishment of a build master, who owns > > the trunk. All changes should be done in local repos. When something > > should be promoted to the trunk, it is debated here, goes through a code > > check, and the build master normalizes the code to a coding standard > > before committing it to the trunk. Trying to get rid of William breaking > > the kernel again (heh), or our infamous problems of things compiling > > under Mono but not VStudio or vice versa. Though I am not personally proficient with branching and then re-merging for the purpose of trunk preservation, I'm a big fan of moving in that direction. I tried setting up a continuous integration system, (CruiseControl.NET), for the project - and CruiseControl.NET from what I understand is the better of the open-source options - but it was a pain in the arse to keep it configured properly, especially with the build scripts changing all the time. If we think we are worth it, we should check into getting a free license, available to open source projects, of a commercial continuous integration suite, such as Jira. > Between that, and API / architecture docs before you start coding a > > major piece. Everyone else can tell you how much I've grumbled lately > > about not being able to get my VM code going because the trunk repo got > > reworked, the base kernel's in flux, and the AOT is still buggy. :) > > > And now guess why I was begging for test cases and test cases and I > still do. These are the things that we ideally need to test: -1- test kernel API functionality -2- test AOT output validity -3- test AOT API functionality (And ideally, the testing process needs to be fully automated, and fully attempted and reported after changes to the trunk.) #1 can be tested, as we've discussed, by conditionally compiling test cases into the kernel. We have not done any work in this area yet. As far as #2, we've done this thus far by compiling a tests kernel that runs the set of test methods, and then printing if one fails. This can be automated by writing to a serial port on the virtual machine which is routed to a named pipe or log file on the host machine, and then processed. The problem with what we have been doing is, some bugs only arise when compiling multiple tests. AOTing test A actually makes test B either fail to AOT or fail to succeed. So we may need a more intelligent testing process that attempts to resolve failed-to-AOT-tests attempts by removing test cases. *shrug*. It has also been suggested that we need to "hand verify" our machine code output, so perhaps a way to compare x86 code output from our AOT with output from .NET or Mono could be possible. As far as #3 (testing the AOT's API functionality) - this is more of a sanity issue, might not need to be done off-the-bat, and it is certainly agreeable that alot of it would be redundant with testing AOT output. Furthermore, regarding all this testing, is that the amount of testing done will compound with every architecture we eventually support. All the more reason to establish as much automation as possible. > > >> 2) We establish a highly documented, well debated kernel design doc. > Then > >> proceed to make the kernel rock solid before putting too much effort > into > >> anything beyond the command line. > >> I firmly agree with this. The problem is, most of us aren't organized enough or well-practiced enough to draw up diagrams of an entire kernel. But I agree that it does need to be done, it does need to be debated. But once settled, it should not be changed for a long time. Projects that keep re-hashing their core design, before they get "off the ground", never get anywhere. They fall apart. We will have to accept that not everyone will be happy with the final design. Thats why forks were invented. >> > > I've been kicking for this for awhile. Currently it's more a code-first, > > write-architecture-later. The largest part of the system, the compiler, > > is AOT-only, and only one person knows its architecture. I've been very > > vocal about that. Don't know if Chriss has gotten anywhere with > > documenting the architecture. > > > Like I already said. The AOT itself is still subject to change, and > right now I am rewriting parts of it. > The code is partly documented and it does even have some inline examples > to make it more understandable > and I everyone that wants to understand it better just write me on IRC. > > > Personally, I would halt all current kernel-related development, go back > > and tear back apart the compiler and get that completely rearchitected, > > redocumented, and retested. > That is what actually is happening right now, even though I had to > suspend the work on it for a while.... again. But in essence, I have to agree. No more kernel work, yet. The AOT is the heart of the project. We have to keep it beating. And we have to get that blood pressure up. I think if we setup a comprehensive test automation process, we can polish the AOT with ease, and then proceed with the kernel, and he monstrous task of at least *trying* to get everyone to agree on its design. > Start with reading in the source bytecode at > > a method level from multiple sources, whether it's a byte stream, file, > > whatever. This ensures an easy separation of code into an embeddable JIT > > engine, with the AOT system simply being a file-feeder shell. Convert to > > unoptimized IR code, then register transfer code. Spit out direct, > > unoptimized machine code from there. Possibly hand-verify if necessary > > the generated machine code. That way we know the basic compiler works > > and implements all CIL opcodes. Optimizations such as SSA, dead code > > elimination, loop unwinding, etc can all be implemented as transforms on > > top of the base IR code stream. From the testing I've seen, I can't tell > > whether bugs are in simple bytecode conversion or various IR > > optimization algorithms. They all seem to be intertwined currently. > > > > But I'm liable to get my head chopped off by Chriss for the above. :) > > > I am not that cruel. ;) > > The idea was actually to get something working ASAP so that the ppl that > wanted to work on the kernel > can do something too. That is why there are lots of generated test cases > for the x86 encoding but pertty few test > cases for the rest of the AOT. I would just suggest to look in the > source code for the TODO lines and there are > lots of them. Most of it was just implemented when an exception raised > because some part was not implemented > yet. And most of the time the trunk kernel was the main source of code > to test and develop the AOT. Johann and > William felt pitiful enough to write test cases.;) Thank you guys! > > What I am trying to say is that I am the only one that is working on it > and any help is more than welcome. I have to say, Chriss, you are very helpful. But the AOT is a beast. A black-box beast. Try not to blame a few of us for being intimidated. ;-) The function-pointer-stub fiasco has scared me quite thoroughly into a position of lurking... So we have to keep our task list, (regardless as to whether or not we keep it on Trac), needs to be fleshed out as thoroughly as possible. If someone decides to work on something (preferably something that has been discussed) before a task has been made for it, then they should, at the very least, make a task for it first. Alot of the craziness around here is simply because we don't keep things organized. No one really knows what someone else is doing until the trunk gets broken... |
From: Scott B. <sb...@me...> - 2007-08-28 22:52:13
|
Darx Kies wrote: > Hi > > I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. > > Chriss. > > Chad Z. Hower aka Kudzu wrote: > >> Which also brings up... >> >> Go to the home page. Search for "license". I Cant find anything... rule #1 >> of any open source project (Darn, cant use OS abbreviation, would be >> ambiguous) is to prominently display the license. >> >> The operable question being what goal is the selected license covering? Or are we selecting LGPL / GPL simply because it's the most popular OSS license? I cannot agree with using GPL, again not without a linking clause. LGPL, for all intents, covers this. The "kernel", runtime, scheduler, driver framework, etc all would be LGPL, allowing for binary closed-source drivers and other apps. Again, personally I would rather go for BSD. But I can understand where people want to force things to remain open source and attributable. Thus the necessity of commercial dual-licensing. So what is GPL covering that LGPL doesn't, in terms of a microkernel architecture? |
From: Dennis H. <den...@ya...> - 2007-08-28 22:45:01
|
US, Georgia, Atlanta. Dennis Darx Kies <dar...@gm...> wrote: Hi. Chad Z. Hower aka Kudzu wrote: > Also again. :) > > Could everyone enumerate where they are located? :) > > Austria. :) Chriss. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list Sha...@li... https://lists.sourceforge.net/lists/listinfo/sharpos-developers --------------------------------- Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. |
From: Bruce <ill...@gm...> - 2007-08-28 22:18:47
|
> > > > So far Europe is tipping the scales. :) I'm in Virginia, USA. But yes, Europe seems to be tipping the scales - in a lot of .NET-related open-source projects, it seems. ;-) -Bruce |
From: Bruce <ill...@gm...> - 2007-08-28 22:15:43
|
On 8/28/07, Darx Kies <dar...@gm...> wrote: > > Hi > > I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. > > Chriss. I concur with Chriss. -Bruce |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 22:15:38
|
> I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. I think this would be an appropriate time to discuss conflict resolution and how its handled on the team again. :) |
From: Darx K. <dar...@gm...> - 2007-08-28 22:13:27
|
Hi In case you are using Windows I would suggest XChat 2.8.X. Chriss. Chad Z. Hower aka Kudzu wrote: >> We usually meet around #sharpos at freenode. If you want to hash some >> ideas with us, either here or there is fine. >> > > Been a few years sine I've been on IRC and I haven't found any recent > clients I like. Any recommendations? > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 22:12:34
|
Not for voice, but in addition to IRC I find skype great for IM. It can do multichat as well... I'm kudzu22 on my dev machine, ziloni on travel. -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
From: Darx K. <dar...@gm...> - 2007-08-28 22:12:07
|
Hi I would opt for LGPL for the kernel, GPL for the drivers and the rest. A commercial dual-licensing should be ok too. Chriss. Chad Z. Hower aka Kudzu wrote: > Which also brings up... > > Go to the home page. Search for "license". I Cant find anything... rule #1 > of any open source project (Darn, cant use OS abbreviation, would be > ambiguous) is to prominently display the license. > > -- > Chad Z. Hower aka Kudzu > "Programming is an art form that fights back" > http://www.KudzuWorld.com/ > http://www.Woo-Hoo.net/ > http://www.DelphiToDotNet.com/ > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > |
From: Darx K. <dar...@gm...> - 2007-08-28 22:08:43
|
Scott Balmos wrote: > Chad Z. Hower aka Kudzu wrote: > >> I'd like to make a few proposals. >> >> 1) We establish a loose but workable team structure which includes conflict >> resolution. >> >> >> > Someone will probably say this already exists. I don't know. My major > recommendation right now is establishment of a build master, who owns > the trunk. All changes should be done in local repos. When something > should be promoted to the trunk, it is debated here, goes through a code > check, and the build master normalizes the code to a coding standard > before committing it to the trunk. Trying to get rid of William breaking > the kernel again (heh), or our infamous problems of things compiling > under Mono but not VStudio or vice versa. > > Between that, and API / architecture docs before you start coding a > major piece. Everyone else can tell you how much I've grumbled lately > about not being able to get my VM code going because the trunk repo got > reworked, the base kernel's in flux, and the AOT is still buggy. :) > And now guess why I was begging for test cases and test cases and I still do. > >> 2) We establish a highly documented, well debated kernel design doc. Then >> proceed to make the kernel rock solid before putting too much effort into >> anything beyond the command line. >> >> >> > I've been kicking for this for awhile. Currently it's more a code-first, > write-architecture-later. The largest part of the system, the compiler, > is AOT-only, and only one person knows its architecture. I've been very > vocal about that. Don't know if Chriss has gotten anywhere with > documenting the architecture. > Like I already said. The AOT itself is still subject to change, and right now I am rewriting parts of it. The code is partly documented and it does even have some inline examples to make it more understandable and I everyone that wants to understand it better just write me on IRC. > Personally, I would halt all current kernel-related development, go back > and tear back apart the compiler and get that completely rearchitected, > redocumented, and retested. That is what actually is happening right now, even though I had to suspend the work on it for a while.... again. > Start with reading in the source bytecode at > a method level from multiple sources, whether it's a byte stream, file, > whatever. This ensures an easy separation of code into an embeddable JIT > engine, with the AOT system simply being a file-feeder shell. Convert to > unoptimized IR code, then register transfer code. Spit out direct, > unoptimized machine code from there. Possibly hand-verify if necessary > the generated machine code. That way we know the basic compiler works > and implements all CIL opcodes. Optimizations such as SSA, dead code > elimination, loop unwinding, etc can all be implemented as transforms on > top of the base IR code stream. From the testing I've seen, I can't tell > whether bugs are in simple bytecode conversion or various IR > optimization algorithms. They all seem to be intertwined currently. > > But I'm liable to get my head chopped off by Chriss for the above. :) > I am not that cruel. ;) The idea was actually to get something working ASAP so that the ppl that wanted to work on the kernel can do something too. That is why there are lots of generated test cases for the x86 encoding but pertty few test cases for the rest of the AOT. I would just suggest to look in the source code for the TODO lines and there are lots of them. Most of it was just implemented when an exception raised because some part was not implemented yet. And most of the time the trunk kernel was the main source of code to test and develop the AOT. Johann and William felt pitiful enough to write test cases.;) Thank you guys! What I am trying to say is that I am the only one that is working on it and any help is more than welcome. Chriss. |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:44:41
|
> We usually meet around #sharpos at freenode. If you want to hash some > ideas with us, either here or there is fine. Been a few years sine I've been on IRC and I haven't found any recent clients I like. Any recommendations? |