There's no benefits to using mono as opposed to using any of the free hosting ones out there. Mono doesn't come with a bug tracker, it doesn't come with space to host downloads, it doesn't come with a wiki of any kind. You really should consider using a free hosting that gives you all that. For example google code, github, whatever.
Alan. On Wed, Jan 14, 2009 at 12:09 AM, crashfourit <crashfou...@gmail.com> wrote: > > > > Rodrigo Kumpera wrote: > > > > On Tue, Jan 13, 2009 at 9:26 PM, crashfourit <crashfou...@gmail.com> > > wrote: > > > >> > >> > >> > >> Hurliman, John wrote: > >> > > >> >> -----Original Message----- > >> >> From: mono-devel-list-boun...@lists.ximian.com > >> >> [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of > >> >> Rodrigo Kumpera > >> >> Sent: Tuesday, January 13, 2009 12:00 PM > >> >> To: crashfourit > >> >> Cc: mono-devel-list@lists.ximian.com > >> >> Subject: Re: [Mono-dev] simd: more accelerated classes > >> >> > >> >> On Tue, Jan 13, 2009 at 5:50 PM, crashfourit <crashfou...@gmail.com> > >> >> wrote: > >> >> > >> >> crashfourit wrote: > > I was wondering what it would > >> >> take to use simd > >> >> to acclerate this > > Vector4f { > public float X; > >> > > >> >> public float Y; > >> >> > public float Z; > public float W; > //....... > >> > > >> } > >> >> > > instead of > >> >> this > Vector4f { > internal float x; > internal float y; > >> > > >> >> internal > >> >> float z; > internal float w; > > public float X {get > >> >> {return x;} set > >> >> {x = value;}} > public float Y {get {return y;} set {y = > >> value;}} > >> >> > > >> >> public float Z {get {return z;} set {z = value;}} > public float > W > >> >> {get > >> >> {return w;} set {w = value;}} > //....... > } > Any > >> >> sugestions? > > >> >> > >> >> > >> >> > >> >> Also, I was wondering is there any interest in accelerated > >> versions > >> >> of high > >> >> level math constructs? > >> >> > >> >> Like, QuaternionF, QuaternionD, Matrix4f, Matrix4d, etc? > >> >> -- > >> >> > >> >> > >> >> I would love to see a library with such high level constructs that > >> >> exploit Mono.Simd. I would help with it for sure, but it shouldn't be > >> >> bundled with mono. > >> >> > >> > > >> > I would be willing to help with this as well. I currently maintain a > >> > library called OpenMetaverseTypes (code is at > >> > > >> > http://www.openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/Types/ > >> ) > >> > which implements Vector2/3/4, Quaternion, Matrix4, Color4, Ray, and a > >> few > >> > collections. In the future I'd like to accelerate as many of these as > >> > possible. Sharing code with another library on top of Mono.Simd would > >> be > >> a > >> > good start. > >> > > >> > John > >> > > >> Is that code under the X11/MIT license? If so, we can start there. I > will > >> set up a sourceforge project for that purpose if the mono team does not > >> want > >> the code on there svn server. > >> -- > > > > > > Let me explain the implications of shipping such library. > > > > First, it would require to be API stable, which will be a pain in the > neck > > during the initial ramp up while the design is flushed out. > > Second, we really really want to stop adding non essential libraries to > > the > > shipping mono. This only increases the load on our QA team at near to no > > benefit for the end user. > > Third, as Novell offers commercial support over the entire mono stack, > > adding stuff increase the load on all of us mono developers that are > > Novell > > employees. This is, for me, the major reason not to add it to our core > > stack. It will increase the support load on my shoulders at little gain. > > > > This is only strict related to the inclusion of such library into the lib > > shipped with mono. It's not the first time this issues has come before us > > with other libraries, such as Mono.Rocks for example, and the consensus > > was > > the same: it would be in the best interest of all parties involved to not > > have it included. > > > > But this doesn't mean the library can't be endorsed as the preferred one > > for > > high level usage of Mono.Simd. From the very begging we already have > > realized that almost everyone would not be willing to use it directly, as > > the lib itself is just some building blocks. > > > > As for hosting the project in the mono svn server, there isn't much of an > > advantage for it, really. I, for one, would rather use github for > example. > > But if you really fancy it, please talk to Miguel, as he is the one that > > can > > make such arrangement. > > > > What would be really nice is to make a single effort for such library and > > make sure that the Mono.Simd side of the things are well fit for such > > library. Keep me posted on your efforts and I'll try to help as much as I > > can. > > > > Cheers, > > Rodrigo > > > I, for one, would prefer the library on the mono svn if it is going to have > the unofficial nod, but I'm going to see what the others here that wanted a > similar library have to say. > -- > View this message in context: > http://www.nabble.com/simd%3A-more-accelerated-classes-tp21442105p21447449.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list