Anything removed from your response means I generally agree.
On 05/03/2008, William Lahti <[EMAIL PROTECTED]> wrote:
> Oh right, let's just dump all the progress we've already got and start
> completely from scratch. Forgive me if I'm not a big fan of this idea.
> And now on to your specific points-- you asked for bluntness and you
> *got it*. But before you read my agitated responses (after all I
> thought this was a discussion about SIngularity source-- not about
> remerging the projects), I'm gonna outline a bit about how *I* think
> we should work this out.
Thank you for gracing me. This needs to be done. We don't nessecarily need
to start from scratch, but copy'n'paste is a wonderful tool :). I am going
to speak to Scott and I will bring my new code over to SharpOS and let AOT
and it run in parrelel until we can decide which is better.
> Jon, wake up the coffee's brewing. ATA and Ext2 have absolutely
> nothing to do with a runtime!! Besides, we've got Ext2 code too, but
> there have been two things stopping it: our broken floppy controller
> and a filesystem interface (both now being worked on by tgiphil)
You missed the point, ATA and Ext2 were easy (albeit unnessecary) *because*
we had a solid runtime.
>
> > Cecil is a wonderful thing. But this is not it's place: it does a lot of
> > automatic inference that really slows things down (Cosmos saw a roughly
> 2x
> > speed increase after switching to a custom IL Reader).
>
> You might be right but I'm EXTREMELY curious to hear some numbers from
> the il2cpu camp on how fast their compiler is, because right now the
> SharpOS kernel compiles in less than 7 seconds on my box, using a tiny
> fraction of RAM--- I'm on a 1.7ghz celeron box with 512MB ram and a
> slow hard drive. So there. Please. Grace me with the numbers. Is
> getting rid of Cecil really the only way you guys could speed it up
> because it must be BLAZING fast. It only took one guy on our team
> something like 2 days of profiling work to make our AOT orders of
> magnitude faster, to the point now where it's already done before I
> realize it's running.
Hmm... Last I checked, I _think_ it was a move from a 18 second build to a
6-8 second build (not bad, considering that some of the Microsoft CORLIB was
being built as well).
> > SharpOS has a lot of code that was made before a solid runtime was
> > supported: which needs to be re-written for the new features.
>
> Hardly rewritten but refactored. For instance I wrote the system clock
> code originally using the low level facilities. When the object
> support was far enough along I ported it to use objects. It took me
> all of 2 hours to get it ported. Ha. Why isn't more of SharpOS like
> that now? We have a kernel rehash coming up once the new features are
> more stable but for now we've got LOTS of stuff to implement. If
> you've been tracking our progress (oh come on you know you want to)...
> we've got everything short of GC and a full corlib, the latest
> addition being generics.
Wow!!! Generics, you guys keep impressing me <no sarcasm>.
> > Serious thought needs to be given about just linking in the Mono
> BCL/FCL.
>
> Your right on this but only partially. I think that large portions of
> the Mono CORLIB (please, stop calling it a BCL or FCL and just call it
> what it is) can be merged in alongside our Korlib code, but I think
> that it will need to be in a much less foggy way (right now we are
> looking at importing a set of types and it's dependencies, whereas we
> should really be going only for the set of explicit types, and
> reimplement what is not included). But using Mono's corlib still has a
> *lot* of merit and has proven to be an excellent way to rigorously
> expose the bugs in our high level facilities.
The thing that worries me, personally, the most is that we can hardly write
anything revolutionary if we use a counter-revolutionary corlib. Can
*anyone* see my point?
> > New Entity
> > Let's collaborate on:
> >
> > 1. A name
> Names don't matter. Never did. Look at Linux. At first glance you
> might say "Hey, that's very original why would you say that?" Well no.
> It's not. Linux is Linus's UNIX which makes the name about as creative
> as SharpOS if you think about it.
Isn't Linux: Linux IsNt UniX?
> > 3. A SCM solution (SVN seems to work very well, but other better ones
> are
> > popping up - e.g. Mercurial)
>
> Hrmmm. The last project that I was involved in that used a more
> [snip]
SVN it is then.
> In closing, yeah peace would be a good thing for all of us and yeah we
> are duplicating effort, and yeah starting from scratch is by far the
> worst way to do it. From my perspective, SharpOS has not been hurt by
> the existence of the other two projects... we've only continued to
> grow. But from what I can see, it is most definitely affecting the
> livelihood of the other two projects, neither of which seem to be
> exactly "thriving". I hate to bring it down to this fact but it's
> there. We're doing *just fine*, so why should we have to compromise on
> our beliefs for so little benefit?
Why? I am worried about the AOT's ability to JIT. Really I am.
Take it however you want, see it as intimidation (which it is NOT). I want
to come back to SharpOS and bring what I have started for Ensemble.
> --
> fury
>
> long name: William Lahti
> handle :: fury
> freenode :: xfury
> blog :: http://xfurious.blogspot.com/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> SharpOS-Developers mailing list
> SharpOS-Developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
--
Jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
