Well... it wasn't in my reader when I sent the exact same thing ;)
On Thu, May 1, 2008 at 12:18 AM, Tomas Matousek
<Tomas.Matousek at microsoft.com> wrote:
> Interesting has this e-mail just arrived?
>> Tomas
>>>> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
> Sent: Wednesday, April 30, 2008 11:58 AM
> To: ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] Opening up our tree to external committers
>> That could be easily fixed by including 'zlib.rb', 'yaml.rb' next to IronRuby.exe. These files would do
> require 'IronRuby.ZLib, version=1.0.0.0, ..." to load the .NET assemblies. I need to think about our loader story more, but this idea seems to provide a nice way how to configure where the extensions are located, which version should be used etc.
>> Tomas
>> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
> Sent: Wednesday, April 30, 2008 11:47 AM
> To: ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] Opening up our tree to external committers
>> The only issue with this is we'll have to have some mechanism for them
> to be referenced with require 'zlib', requrie 'yaml', et. al. in order
> to maintain compatibility.
>> On Wed, Apr 30, 2008 at 12:27 PM, Tomas Matousek
> <Tomas.Matousek at microsoft.com> wrote:
> > I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names.
> >
> > Tomas
> >
> >
> >
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY)
> > Sent: Wednesday, April 30, 2008 7:01 AM
> > To: ironruby-core at rubyforge.org> > Cc: Qing Ye
> > Subject: [Ironruby-core] Opening up our tree to external committers
> >
> > Peter Bacon Darwin:
> >
> > > It is not too late to implement something like this. If a bit of work
> > > could be done on loading external IR libraries then projects could
> > > begin to be setup independently. This would have the multiple benefit
> > > of getting people to work on interesting and challenging projects,
> > > potentially creating alternative options to the IR community but also
> > > those people working on the projects are more likely to pickup bugs and
> > > add in the smaller patches to the core that are not getting people
> > > excited at the moment.
> >
> > I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port.
> >
> > Something like:
> >
> > src\
> > zlib
> > ironi
> > yaml
> > ...
> >
> > We would have external folks own those directories and they would be responsible for reviewing contributions into those directories.
> >
> > Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime:
> >
> > zlib ironi yaml
> > ironruby.libraries
> > ironruby
> >
> > The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll.
> >
> > That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today.
> >
> > Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today.
> >
> > I think that the natural owners of these libraries are:
> >
> > zlib: Michael Letterle
> > ironi: Peter Bacon Darwin
> > yaml: John Messerly
> >
> > There may be others - thoughts?
> >
> > Thanks,
> > -John
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org> > http://rubyforge.org/mailman/listinfo/ironruby-core> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org> > http://rubyforge.org/mailman/listinfo/ironruby-core> >
>>>> --
> Michael Letterle
> [Polymath Prokrammer]
>http://blog.prokrams.com> _______________________________________________
> Ironruby-core mailing list
>Ironruby-core at rubyforge.org>http://rubyforge.org/mailman/listinfo/ironruby-core> _______________________________________________
> Ironruby-core mailing list
>Ironruby-core at rubyforge.org>http://rubyforge.org/mailman/listinfo/ironruby-core> _______________________________________________
> Ironruby-core mailing list
>Ironruby-core at rubyforge.org>http://rubyforge.org/mailman/listinfo/ironruby-core>
--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com