Ironruby core - Apr 2008 - Regarding IronRuby... How true it sounds from this blog

Hi,

I was just referring a blog from Charles Nutter about his thinking on
IronRuby and future implementations for Rails.

Here''s the link..
http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html

Just wondering, how true it sounds... I do not agree on many points.
Looking forward to read more comments on this.

Thanks
-- 
Posted via http://www.ruby-forum.com/.

2008/4/28 Rahil Kantharia <lists at
ruby-forum.com>:
> 
http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html
>
>  Just wondering, how true it sounds... I do not agree on many points.
>  Looking forward to read more comments on this.
It seems to be a rather good overview of the status to me. I mostly
agree, except for the accusation that "Microsoft would never back an
OSS web framework like Rails in preference to its own".

-- 
Seo Sanghyeon

Sanghyeon Seo:
> It seems to be a rather good overview of the status to me. I mostly
> agree, except for the accusation that "Microsoft would never back an
> OSS web framework like Rails in preference to its own".
He also gets a number of important technical details wrong about IronRuby,
I''ll respond later today.

Thanks,
-John

On Sun, 27 Apr 2008 23:31:21 -0600, Sanghyeon Seo <sanxiyn at gmail.com>  
wrote:
>>  Just wondering, how true it sounds... I do not agree on many points.
>>  Looking forward to read more comments on this.
> It seems to be a rather good overview of the status to me. I mostly
> agree, except for the accusation that "Microsoft would never back an
> OSS web framework like Rails in preference to its own".
Hmmm... I think that''s a pretty fair statement from Charlie.  If
I''m
understanding his point correctly, Microsoft will never turn away from  
ASP.NET in favor or Rails, and instead will continue to push ASP.NET in  
the various directions necessary to keep up with the trends (e.g. ASP.NET  
MVC Framework.)  They''ll certainly put the money into providing support
for Rails, whether that be through IronRuby, or directly through MRI via  
the IIS7 FastCGI layer.  But it will never become the King at DEV.MSFT.  Nor  
should it.  ASP.NET is a kick a$$ web application framework.  And  
regardless of the popularity of Rails in the OSS communities of the world,  
it will be a *VERY* long time -- if ever -- before the installed Rails  
developer base surpasses the installed ASP.NET developer base.

Plus, the installed ASP.NET developer base is actually willing to spend  
money on development tools and related products, something the installed  
Rails-base is only partially willing to do (e.g. TextMate).  And, in the  
end, it''s the products that find ways to generate revenue that continue
to
both survive and thrive.   That''s not to suggest Rails isn''t
going to
survive and/or thrive.  The free-as-in-speech Rails project is funded by  
the profit making 37 Signals and its various not-free-as-in-gasoline  
products in the same way the free-as-in-beer .NET/ASP.NET/etc. projects  
are funded by the profit making Microsoft and its various  
not-free-as-in-gasoline products.  And when you throw the  
free-as-in-speech IronPython/IronRuby/DLR/ASP.NET MVC/etc. projects into  
the mix, it''s tough to criticize MSFT''s intentions and
contributions to
the OSS ecosystem.

Of course the Mono Project -- which in and of itself provides not only the  
web framework support that Rails represents, but the entire language and  
platform that MRI represents (and then some!) -- represents a *MASSIVE*  
OSS community that the Rails community pales in comparison to. So it''s
tough to take on any type of stance that suggests that .NET/ASP.NET and  
related frameworks are the wrong overall direction for us developer types  
to be placing focus on, regardless of our preference towards OSS and  
proprietary platforms.

That said, I most definitely agree with Charlie''s thoughts regarding
the
overall community collaboration and contributions as it relates to the  
IronRuby project.  But I''m less inclined to put the blame entirely on  
MSFT''s shoulders.  The door has certainly been open for the community
to
contribute, and several folks have taken advantage of that.  And John and  
company have certainly proven a willingness to rapidly inject the various  
contributions into the source tree as soon as these same contributions  
seem viable enough to be injected into the source tree.

I don''t want to put the burden entirely on the communities shoulders,
but
there certainly needs to be at least some recognition to the fact that  
this is a completely different situation than was JRuby when it came into  
the good graces of Sun.  JRuby was a living, breathing, viable open source  
implementation of the Ruby language with a living, breathing, and active  
OSS community backing it up long before Sun came into the picture.  On the  
other hand, IronRuby was a resuscitated proof-of-concept project that
I''m
not even sure really ever saw the light of the OSS-day before being  
brought into the MSFT fold.  So while Charlie is correct: The IronRuby  
project needs to become more community oriented, that community  
orientation needs to come from not only MSFT''s direction, but the  
communities direction as well.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY)  
<jflam at microsoft.com> wrote:
> He also gets a number of important technical details wrong about  
> IronRuby, I''ll respond later today.
I can point out at least one: "IronRuby really has its roots in the  
Ruby.NET project from Queensland University of Technology" is incorrect.  
The IronRuby parser/scanner was bootstrapped by the Ruby.NET  
parser/scanner, but has since removed all signs of the Ruby.NET  
parser/scanner in favor of a from-the-ground-up implementation written  
entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points  
out somewhat correctly in his opening paragraph,
> IronRuby was still Wilco Bauer''s IronRuby, a doomed codebase and
project
> name eventually to be adopted by Microsoft''s later Ruby
implementation
> effort.
... which is at least partially correct, if not a bit misleading given  
that for all intents and purposes the IronRuby project of today is a  
from-the-ground-up implementation of the Ruby language and runtime based  
on top of the from-the-ground-up Dynamic Language Runtime code base and  
architecture.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

Well to be fair, IronRuby /does/ have it''s roots in Ruby.NET in that
it was the first Microsoft supported CLR implementation.  And I
believe Charles is referring to the /name/ of Bauer''s IronRuby being
adopted by Microsoft, not the codebase.

On Mon, Apr 28, 2008 at 10:52 AM, M. David Peterson
<m.david at xmlhacker.com> wrote:
> On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY)
> <jflam at microsoft.com> wrote:
>
>
> > He also gets a number of important technical details wrong about
IronRuby,
> I''ll respond later today.
> >
>
>  I can point out at least one: "IronRuby really has its roots in the
> Ruby.NET project from Queensland University of Technology" is
incorrect. The
> IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner,
but
> has since removed all signs of the Ruby.NET parser/scanner in favor of a
> from-the-ground-up implementation written entirely by -- I believe -- Tomas
> Matousek. Of course, as Charlie points out somewhat correctly in his
opening
> paragraph,
>
>
> > IronRuby was still Wilco Bauer''s IronRuby, a doomed codebase
and project
> name eventually to be adopted by Microsoft''s later Ruby
implementation
> effort.
> >
>
>  ... which is at least partially correct, if not a bit misleading given
that
> for all intents and purposes the IronRuby project of today is a
> from-the-ground-up implementation of the Ruby language and runtime based on
> top of the from-the-ground-up Dynamic Language Runtime code base and
> architecture.
>
>  --
>  /M:D
>
>  M. David Peterson
>  Co-Founder & Chief Architect, 3rd&Urban, LLC
>  Email: m.david at 3rdandUrban.com | m.david at amp.fm
>  Mobile: (206) 999-0588
>  http://3rdandUrban.com | http://amp.fm |
> http://www.oreillynet.com/pub/au/2354
>
>
>  _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

M. David Peterson wrote:
> That said, I most definitely agree with Charlie''s thoughts
regarding the
> overall community collaboration and contributions as it relates to the 
> IronRuby project.  But I''m less inclined to put the blame entirely
on
> MSFT''s shoulders.  The door has certainly been open for the
community to
> contribute, and several folks have taken advantage of that.  And John 
> and company have certainly proven a willingness to rapidly inject the 
> various contributions into the source tree as soon as these same 
> contributions seem viable enough to be injected into the source tree.
I disagree, and you need look no further than this mailing list to see 
the truth. Of the perhaps 40 threads I see started since Apr 3, I see 
only 8 that were started by folks from Microsoft...all John Lam...two of 
those SVN update emails. So perhaps 6 substantive threads where the 
initiator is someone from the IronRuby team.

In order for an OSS project to work, any core team needs to be having 
conversations in the open. Since this is clearly not happening, it would 
be the first thing to change. I don''t know if it''s Microsoft
policy or
just an oversight by the IronRuby team.

And obviously not tossing SVN bundles over the wall would help foster a 
bit more dynamic community. It''s far more difficult (maybe impossible) 
to run an OSS project well if the community members can''t update their 
working copies to exactly what the core team sees day-to-day. This one 
is most likely an MS issue.

- Charlie

M. David Peterson wrote:
> On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) 
> <jflam at microsoft.com> wrote:
> 
>> He also gets a number of important technical details wrong about 
>> IronRuby, I''ll respond later today.
> 
> I can point out at least one: "IronRuby really has its roots in the 
> Ruby.NET project from Queensland University of Technology" is
incorrect.
> The IronRuby parser/scanner was bootstrapped by the Ruby.NET 
> parser/scanner, but has since removed all signs of the Ruby.NET 
> parser/scanner in favor of a from-the-ground-up implementation written 
> entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points 
> out somewhat correctly in his opening paragraph,
The IronRuby parser/scanner being bootstrapped by the Ruby.NET 
parser/scanner is certainly enough to say that''s where
IronRuby''s roots
lie. And even without that, IronRuby probably wouldn''t have been 
attempted if Ruby.NET had shown it to be too difficult or impossible. 
IronRuby owes Ruby.NET for its birth, at least.
>> IronRuby was still Wilco Bauer''s IronRuby, a doomed codebase
and
>> project name eventually to be adopted by Microsoft''s later
Ruby
>> implementation effort.
> 
> ... which is at least partially correct, if not a bit misleading given 
> that for all intents and purposes the IronRuby project of today is a 
> from-the-ground-up implementation of the Ruby language and runtime based 
> on top of the from-the-ground-up Dynamic Language Runtime code base and 
> architecture.
No, it''s an entirely correct statement. At the time, IronRuby was 
Wilco''s project, and no IronRuby work had been started at MS. I did not
make any claim that the codebase was somehow reused or incorporated into 
the official "IronRuby", and made a point of calling it doomed because
as far as I know it''s never going to be touched again.

Perhaps I should have said:

"IronRuby" was still Wilco Bauer''s IronRuby, ...

- Charlie

On Mon, 28 Apr 2008 09:00:04 -0600, Michael Letterle  
<michael.letterle at gmail.com> wrote:
> Well to be fair, IronRuby /does/ have it''s roots in Ruby.NET in
that
> it was the first Microsoft supported CLR implementation.
Fair enough.
> And I
> believe Charles is referring to the /name/ of Bauer''s IronRuby
being
> adopted by Microsoft, not the codebase.
That would make sense.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, 28 Apr 2008 09:02:56 -0600, Charles Oliver Nutter  
<charles.nutter at sun.com> wrote:
> I disagree, and you need look no further than this mailing list to see  
> the truth. Of the perhaps 40 threads I see started since Apr 3, I see  
> only 8 that were started by folks from Microsoft...all John Lam...two of  
> those SVN update emails. So perhaps 6 substantive threads where the  
> initiator is someone from the IronRuby team.
Oh, I don''t disagree with this, just that I don''t see any
physical
obstacles keeping the community from becoming more involved.  Mental  
obstacles, for sure... And maybe that''s really where the focus needs to
be: Finding ways to remove the mental obstacles that keep people from  
contributing more aggressively.

I know how you guys have done it and are continuing to do it.  But putting  
yourself in IronRuby''s Red Slippers for a moment, how would you do it
if
you were starting from scratch (or as close to scratch as you can get w/o  
literally starting from scratch) and had to find ways to first, sell the  
overall idea to the community to then get that same community to actively  
participate in the process while at the same time making attempt to  
convince that the once proprietary-only giant really is committed to  
building OSS into their overall software ecosystem?

> In order for an OSS project to work, any core team needs to be having  
> conversations in the open. Since this is clearly not happening, it would  
> be the first thing to change. I don''t know if it''s
Microsoft policy or
> just an oversight by the IronRuby team.
I can''t say I really know the answer, but I do agree with your point.
 From my own perspective I would suggest it''s a combination of the
internal
culture at MSFT attempting to change how they go about the business of  
courting the developer coupled with the size of the internal IronRuby team  
that still have to meet deadlines and expectations that are unrelated to  
IronRuby (e.g. integration with the DLR team, MIX and other high profile  
events, typical corporate culture stuff such as performance reviews,  
etc.)  That''s not an attempt to provide an excuse as to why they
can''t be
more open.  Just an attempt at understanding there are more forces  
involved than are immediately obvious from the outside looking in.
> And obviously not tossing SVN bundles over the wall would help foster a  
> bit more dynamic community.
Absolutely 100% agree.  One of things I was curious to see when John first  
announced that IronRuby would be hosted on RubyForge was whether or not he  
could actually pull it off.  From what I assume is both of our  
perspectives, thus far it hasn''t worked out as well as it both could
and
should have.
> It''s far more difficult (maybe impossible) to run an OSS project
well if
> the community members can''t update their working copies to exactly
what
> the core team sees day-to-day. This one is most likely an MS issue.
It''s absolutely 100% an internal MSFT issue.  Can it be fixed?

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

M. David Peterson:
> > It''s far more difficult (maybe impossible) to run an OSS
project well
> > if the community members can''t update their working copies to
exactly
> > what the core team sees day-to-day. This one is most likely an MS
> issue.
>
> It''s absolutely 100% an internal MSFT issue.  Can it be fixed?
While meta-level discussions are interesting, they generally don''t
offer much in the way of concrete guidance. So let me ask this question to the
larger community:

Has working on the SVN sources (with the attendant delays in propagating to /
from our version of ''the truth'') blocked you from working on a
contribution?

Thanks,
-John

On Mon, 28 Apr 2008 09:27:53 -0600, M. David Peterson  
<m.david at xmlhacker.com> wrote:
> But putting yourself in IronRuby''s Red Slippers for a moment,
To put this another way, JRuby was a successful OSS project *FIRST* which  
-- because of this fact -- attracted Sun to bring the project and its two  
core contributors (at that time -- if not mistaken, didn''t Ola really  
begin his core involvement after the acquisition?) in house.  The  
community didn''t have to be convinced of the overall JRuby idea.  That
had
already happened long before Corporate America began it''s lust ->
love
fest with the project, gaining not only the already successful OSS JRuby  
project, but access to the best and the brightest minds/talent the Java  
development community had to offer as a result.

MSFT, on the other, went out and found the best and brightest minds/talent  
the .NET development community had to offer -- at least as far as  
experience with the Ruby language was concerned -- and then tasked them  
with building not only an OSS Ruby implementation for the .NET platform,  
but in building an OSS community as well > Both -- for all intents and  
purposes -- from scratch.

Two different situations.  Two different scenarios.  You''ve done it  
successfully from the outside in.  How would you do it -- again  
successfully -- from the inside out?

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, Apr 28, 2008 at 8:35 AM, John Lam (IRONRUBY)
<jflam at microsoft.com> wrote:
>  Has working on the SVN sources (with the attendant delays in propagating
to / from our version of ''the truth'') blocked you from working
on a contribution?
I have a large block of code that is based on the long-ago RubyCLR
bridge John implemented. I am very excited to get that onto native
.NET. My impression is that IronRuby is not far enough along to
support much of my codebase, but it''s a moot point. I cannot access
RubyForge''s SVN repository from behind my employer''s ISA
firewall (it
blocks certain HTTP headers SVN uses). I did manage to spider the
latest release at one point using WGET but it wasn''t an effort
I''d
repeat regularly. Another method for getting the codebase would make
it easier for me to see what IronRuby is capable of so far.

Justin

On Mon, 28 Apr 2008 09:35:24 -0600, John Lam (IRONRUBY)  
<jflam at microsoft.com> wrote:
> Has working on the SVN sources (with the attendant delays in propagating  
> to / from our version of ''the truth'') blocked you from
working on a
> contribution?
No.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Oliver Nutter wrote:
> I disagree, and you need look no further than this mailing list to see
> the truth. Of the perhaps 40 threads I see started since Apr 3, I see
> only 8 that were started by folks from Microsoft...all John Lam...two of
> those SVN update emails. So perhaps 6 substantive threads where the
> initiator is someone from the IronRuby team.
> 
> In order for an OSS project to work, any core team needs to be having
> conversations in the open. Since this is clearly not happening, it would
> be the first thing to change. I don''t know if it''s
Microsoft policy or
> just an oversight by the IronRuby team.
> 
> And obviously not tossing SVN bundles over the wall would help foster a
> bit more dynamic community. It''s far more difficult (maybe
impossible)
> to run an OSS project well if the community members can''t update
their
> working copies to exactly what the core team sees day-to-day. This one
> is most likely an MS issue.
I don''t usually like to criticize open source projects but I must say
that I wholeheartedly agree with you on this point. The development
process behind JRuby and Rubinius is very open, while IronRuby''s one is
not nearly enough so. The end result is that JRuby and Rubinius appear
to be improving really fast, while IronRuby seems to proceed at a
glacial pace. Behind the scenes, this may not be the case, but by
looking at the repository this is the impression that one gets.

According to ohloh, IronRuby has 2 contributors who made commits, JRuby
has 22 and Rubinius 152. JRuby and Rubinius get several commits on a
daily basis, while IronRuby''s commits are rare and 1 year after its
announcement there still hasn''t been a single release, the trunk is at
version 96 and x = 2 in interactive mode is still broken.

While granted IronRuby may appeal to less people than Rubinius or JRuby,
I still feel that the development process could benefit a lot from
incremental/daily commits, more transparency and a greater deal of
control handed to the community.

As Charlie mentioned somewhere else, JRuby is not Sun''s, it belongs to
the community. That statement is entirely backed up by facts, but I''m
afraid that, at this stage, it isn'' possible to claim the same for
IronRuby. This, coupled with the fact that ASP.NET and languages like C#
are clearly Microsoft''s main interest, lead me to believe that IronRuby
is not living up to its full potential.

Microsoft has the resources and brilliant minds (e.g. John Lam) to
seriously reconsider its approach to this project, in order to really
let it take off.

Just my 2 cents,
Antonio
- --
http://antoniocangiano.com - Zen and the Art of Programming
http://stacktrace.it - Aperiodico di resistenza informatica
http://math-blog.com - Math Blog: Mathematics is wonderful!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgV8PIACgkQqCqsu0qUj9SOrgCgww8tFRi03AQG0nnj6iE2MCuo
KboAn0hzVO97RQgJIALx07e1j4px1iOl
=Y1aM
-----END PGP SIGNATURE-----

John Lam (IRONRUBY) wrote:
> M. David Peterson:
> 
>>> It''s far more difficult (maybe impossible) to run an OSS
project well
>>> if the community members can''t update their working copies
to exactly
>>> what the core team sees day-to-day. This one is most likely an MS
>> issue.
>>
>> It''s absolutely 100% an internal MSFT issue.  Can it be fixed?
> 
> While meta-level discussions are interesting, they generally don''t
offer much in the way of concrete guidance. So let me ask this question to the
larger community:
> 
> Has working on the SVN sources (with the attendant delays in propagating to
/ from our version of ''the truth'') blocked you from working on
a contribution?
And answer carefully, friends, because you could help correct this 
policy. Don''t give an answer you think John wants to hear, because a 
little community pressure could go a long way toward improving the 
situation. I''m sure John would agree with me there...

- Charlie

On Mon, 28 Apr 2008 09:43:29 -0600, Justin Bailey <jgbailey at gmail.com>
wrote:
> Another method for getting the codebase would make
> it easier for me to see what IronRuby is capable of so far.
Like?  Is there another SCC/wire protocol that would work?  If yes, there  
are plenty of bridges out there that are 1-to-1 compatible (meaning they  
retain 100% of the meta-data and related versioning/check-in info) with  
SVN both forwards and backwards.  Tailor comes to mind.  I know there are  
others.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

I have not personally been affected by the long time periods between the
code drops.  I doubt it has had a serious impact on many other contributors.
Although there have certainly been a few issues highlighted in the mailing
list around the hosting API and some other internal chunks of code that have
delayed people trying to work on top of IR - the SaphireSteel guys come to
mind, I still believe this has not really been a problem, since even in a
totally open environment, people would need to wait on the core team to
deliver API''s anyway, no?

I think the main problem with the current wall-tossing arrangement is that
it creates a feeling of, "this is a their (Microsoft) project" rather
than
"this is our (community) project".  Contributors feel no ownership of
the
code they contribute, let alone the project as a whole.   What gets people
excited, and encouraged to contribute, to a project is the feeling that they
own some part of it or have some responsibility in the direction and
decision making.

Bug fixing patches and fleshing out code stubs is very important but not too
exciting for many developers.  It would have been an interesting exercise to
break off self-standing components of the Iron Ruby libraries and set them
up as independent OSS projects of their own that are primarily stored in SVN
and imported into MS Team repositories on occasion rather than the other way
around.  Obvious candidates are the YAML processor, the Regex engine, and
any other components that require substantial C# code to be written, and
design decisions to be made.

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.

My two pennies.

Pete

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam
(IRONRUBY)
Sent: Monday,28 April 28, 2008 16:35
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
this blog

M. David Peterson:
> > It''s far more difficult (maybe impossible) to run an OSS
project well
> > if the community members can''t update their working copies to
exactly
> > what the core team sees day-to-day. This one is most likely an MS
> issue.
>
> It''s absolutely 100% an internal MSFT issue.  Can it be fixed?
While meta-level discussions are interesting, they generally don''t
offer
much in the way of concrete guidance. So let me ask this question to the
larger community:

Has working on the SVN sources (with the attendant delays in propagating to
/ from our version of ''the truth'') blocked you from working on
a
contribution?

Thanks,
-John
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Hi,

All I can say is... The Progress is slow.

Refer to this thread in this forum only.

One of the community member shouts, since there is no beta around even 
after one year.

Here''s the link..
http://www.ruby-forum.com/topic/144090#new

All I can say clearly is...There is Lots of Delay in the progress.

Thanks
-- 
Posted via http://www.ruby-forum.com/.

On Mon, 28 Apr 2008 09:45:46 -0600, Charles Oliver Nutter  
<charles.nutter at sun.com> wrote:
> And answer carefully, friends, because you could help correct this  
> policy.
I answered honestly.  No, it''s not getting in the way.  But that
doesn''t
mean I believe that process isn''t broken.  It is without a doubt. 
I''m
just not 100% sure -- taking in all considerations to the challenge at  
hand -- how to "fix" it from a truly ideal OSS community perspective.
> Don''t give an answer you think John wants to hear, because a
little
> community pressure could go a long way toward improving the situation.  
> I''m sure John would agree with me there...
I dom''t know if he will agree or not, but whether he does or
doesn''t, the
fact of the matter is that there are two options,

  - Do nothing and wait for something to happen on its own.
  - Do something and see what happens as a result.

I''m 100% the notion of applying pressure.  Where''s the best
place to start?

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, 28 Apr 2008 09:44:50 -0600, Antonio Cangiano <acangiano at
gmail.com>
wrote:
> As Charlie mentioned somewhere else, JRuby is not Sun''s, it
belongs to
> the community. That statement is entirely backed up by facts, but
I''m
> afraid that, at this stage, it isn'' possible to claim the same for
> IronRuby. This, coupled with the fact that ASP.NET and languages like C#
> are clearly Microsoft''s main interest, lead me to believe that
IronRuby
> is not living up to its full potential.
Nicely stated!  Of course, as per my previous argument, I do believe  
consideration needs to be made as to the difference between the outside >  
in approach that JRuby represents and the inside > out approach  
represented by IronRuby.  None-the-less, there needs to be some faith  
building exercises coming from the direction of MSFT that help bring a  
better sense of community ownership to the project, that''s without a
doubt!
> Microsoft has the resources and brilliant minds (e.g. John Lam) to
> seriously reconsider its approach to this project, in order to really
> let it take off.
Absolutely!

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

2008/4/29 John Lam (IRONRUBY) <jflam at
microsoft.com>:
>  Has working on the SVN sources (with the attendant delays in propagating
to / from our version of ''the truth'') blocked you from working
on a contribution?
Blocked? No. Discouraged? Hell sure.

(The same applies to IronPython, but IronPython is much more stable
than IronRuby, so it changes less frequently, which makes keeping up
to date easier.)

-- 
Seo Sanghyeon

Peter Bacon Darwin wrote:
> I have not personally been affected by the long time periods between the
> code drops.  I doubt it has had a serious impact on many other
contributors.
> Although there have certainly been a few issues highlighted in the mailing
> list around the hosting API and some other internal chunks of code that
have
> delayed people trying to work on top of IR - the SaphireSteel guys come to
> mind, I still believe this has not really been a problem, since even in a
> totally open environment, people would need to wait on the core team to
> deliver API''s anyway, no?
In general the problem I see most often goes like this:

1. Contributor tries to run IronRuby from RubyForge trunk.
2. Contributor finds a bug.
3. Contributor emails the list, asking if this bug has been fixed, and 
often volunteering to fix it.
4. IronRuby Team Member replies, saying the bug is fixed and will be in 
the next drop.
5. Contributor waits, maybe moving on to other IronRuby work or maybe 
walking away from the project until the next drop.

And this seems to happen again and again. Not only does it slow the 
process of fixing bugs, it makes it impossible for people to want to 
help fix them. If you can never know you''re running against the latest 
sources, the process of finding a bug, emailing to see if it''s fixed 
already, and probably waiting for that fix to arrive is extremely 
discouraging.

- Charlie

On Mon, 28 Apr 2008 10:03:49 -0600, Sanghyeon Seo <sanxiyn at gmail.com>  
wrote:
> Blocked? No. Discouraged? Hell sure.
I can''t think of a better way to accurately portray the reality of the
situation.  Nicely stated, Seo!

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

In a technical fashion?  No.  From an emotional standpoint?  Yes.
Right now IronRuby is very unstable from the view of an outside
contributor, you don''t know if the code you''re working on now
is going
to need /major/ changes in the next drop, and you don''t know when
that''s going to be.  Why work on a bug that "in truth" may
already be
fixed?

The most important change that MSFT can do is let you push to
rubyforge DIRECTLY, none of this internal updates pushed to rubyforge
once in a while.  I assume it''s corporate preventing this, because it
really make no sense otherwise.  What we have here isn''t an OSS
community project in the traditional sense, what we have is a
Microsoft project that they''ve so kindly, in their infinite wisdom
allow us commoners to work on now and then.  Oh but you can''t see or
touch the real code until we''re ready to let you.  This is HIGHLY
discouraging.

Don''t get me wrong, I applaud Microsoft for going this far,
it''s a
major step, but only a step, there''s still a long way to go.

On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY)
<jflam at microsoft.com> wrote:
>  Has working on the SVN sources (with the attendant delays in propagating
to / from our version of ''the truth'') blocked you from working
on a contribution?
>
>  Thanks,
>  -John
>
>
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

On Mon, 28 Apr 2008 10:05:43 -0600, Charles Oliver Nutter  
<charles.nutter at sun.com> wrote:
> And this seems to happen again and again. Not only does it slow the  
> process of fixing bugs, it makes it impossible for people to want to  
> help fix them. If you can never know you''re running against the
latest
> sources, the process of finding a bug, emailing to see if it''s
fixed
> already, and probably waiting for that fix to arrive is extremely  
> discouraging.
I agree.  If I am remembering correctly, one of the primary reasons behind  
the dual-repository approach is the need to run a myriad of internal tests  
 from a test suite that reaches farther and deeper than just IronRuby, and  
therefore can not see the light of day outside the MSFT firewall.

John, is this an accurate assessment?  If yes, while I certainly recognize  
the need to run the code against internal test suites, couldn''t it be  
looked at from the opposite perspective?That of: We, the community, tell  
you, the big bad corporate firewall, when you get to gain access to *our*  
code to run your tests.  We will continue on our way checking it whatever  
we want whenever we want, and you can use repository revisions as a marker  
to determine what can be viewed as "blessed" and what can not as far
as
releases are concerned.

If it really is an issue with intellectual property et. al, you can keep  
those results locked up in a bit locker that guarantees they''ll never  
experience life outside their darkened dungeon. We, the community, are not  
interested in the results of internal tests, and we certainly would  
understand that, regardless of the results of our external tests, there  
are certain check boxes that need to be checked by powers unknown to us  
before an officially blessed release can be made.  All we care about is  
passing the spec, something which is, quite obviously, controlled outside  
the grasp of Redmond''s barbed [fire]wire-trimmed walls.  If it takes a
few
extra weeks to take a particular revision of the repository through the  
internal ringer before getting the official rubber stamp, then so be it.   
It wouldn''t be getting in the way of development progress, and if not  
mistaken, this is really the core of the argument as to why the process is  
currently broken.

Food for thought...

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

"but since removed all signs of the Ruby.NET
parser/scanner in favor of a from-the-ground-up implementation written
entirely by -- I believe -- Tomas Matousek"

More precisely, I''ve heavily refactored the tokenizer (and
it''s still not finished) and rewrote semantic actions in the grammar to
create IronRuby AST - which I wrote from scratch. The grammar rules themselves
are more or less as they was in Ruby.NET. With some renames and minor changes.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of M. David Peterson
Sent: Monday, April 28, 2008 7:52 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog

On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY)
<jflam at microsoft.com> wrote:
> He also gets a number of important technical details wrong about
> IronRuby, I''ll respond later today.
I can point out at least one: "IronRuby really has its roots in the
Ruby.NET project from Queensland University of Technology" is incorrect.
The IronRuby parser/scanner was bootstrapped by the Ruby.NET
parser/scanner, but has since removed all signs of the Ruby.NET
parser/scanner in favor of a from-the-ground-up implementation written
entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points
out somewhat correctly in his opening paragraph,
> IronRuby was still Wilco Bauer''s IronRuby, a doomed codebase and
project
> name eventually to be adopted by Microsoft''s later Ruby
implementation
> effort.
... which is at least partially correct, if not a bit misleading given
that for all intents and purposes the IronRuby project of today is a
from-the-ground-up implementation of the Ruby language and runtime based
on top of the from-the-ground-up Dynamic Language Runtime code base and
architecture.

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
http://www.oreillynet.com/pub/au/2354
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

On Mon, 28 Apr 2008 10:42:01 -0600, Tomas Matousek  
<Tomas.Matousek at microsoft.com> wrote:
> More precisely, I''ve heavily refactored the tokenizer (and
it''s still
> not finished) and rewrote semantic actions in the grammar to create  
> IronRuby AST - which I wrote from scratch. The grammar rules themselves  
> are more or less as they was in Ruby.NET. With some renames and minor  
> changes.
Thanks for the clarification, Tomas!

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

I can''t say that the delay has stopped me from working on a
contribution
since I''ve just recently started investigating where I may be able to
lend a
hand.  However, I can say that I''m much more reluctant to jump in and
start
working on something since I don''t want to work on a implementing or
fixing
something that has already been addressed.

I think it would be great to have a more open environment where the
community knows what the members of the IronRuby team are working on and
what they''re currently thinking about, as well as what things they
aren''t
able to get to yet but are higher priority.  This would help the community
understand what they should stay away from, as well as what would be a good
place to contribute.  In order to foster a community around IronRuby I
believe there needs to be something that can rally the community around a
cause.  Right now, most of the people I''ve spoken to are in a wait and
see
mode with IronRuby.  It would be great if we could do something to get
people in a "what can I do to contribute value to the project" mode.

This is coming from someone who has just recently "joined" the
IronRuby
community, so I may not be looking in the right places.

Cheers,
Steve

On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) <jflam at
microsoft.com>
wrote:
> M. David Peterson:
>
> > > It''s far more difficult (maybe impossible) to run an OSS
project well
> > > if the community members can''t update their working
copies to exactly
> > > what the core team sees day-to-day. This one is most likely an MS
> > issue.
> >
> > It''s absolutely 100% an internal MSFT issue.  Can it be
fixed?
>
> While meta-level discussions are interesting, they generally don''t
offer
> much in the way of concrete guidance. So let me ask this question to the
> larger community:
>
> Has working on the SVN sources (with the attendant delays in propagating
> to / from our version of ''the truth'') blocked you from
working on a
> contribution?
>
> Thanks,
> -John
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/1bde7b2a/attachment.html>

I believe one of the key problems is the DLR.  As I understand, it MS makes
a distinction between "important" stuff (i.e. the DLR) and
"peripheral"
stuff (i.e. IronXxxx).  MS wants to have complete control over the DLR and
is not interested in making it Open Source.  Rather the DLR code is just
community viewable, much like the rest of the .NET framework code.  I can
understand this since core .NET Framework code is central to the MS strategy
and they don''t want things sneaking in the sides.

 

IronRuby, IronPython and so on are not so important to MS strategy and they
are more happy to let the community muck about with the code.  I believe
that the long term goal is to open up the IronXxxx code much more to the
community but the problem is that the line between the DLR and the IronXxxx
languages is not yet nailed down.  Therefore until that happens MS is
unlikely to hand over the project to the community.

 

I would be interested to know how often an SVN dump is created compared to
successful check-ins going through the SNAP process.  Ideally, every
successful SNAP check-in should get automatically dumped out on the
RubyForge SVN repos, whether it added value or broke the tests or whatever.
You can always have SVN tags on the "good" builds and also create
downloadable "good" releases on the RubyForge site - this point would
probably help Justin Bailey''s access problems too.

 

Another scenario, which /M:D alludes to if I understand correctly, is to
allow the community to modify the code in the RubyForge project and then let
MS select "good" builds to check back into the Team system via the
SNAP
process.  That way, the community feels ownership of the project and MS get
that quality control on what finally goes into IronRuby.  There are
obviously many technical hurdles to overcome before this could become
reality.  In particular, there needs to be a separation of DLR from
IronXxxx, including, probably, some kind of stable release of the DLR for
the IronXxxx projects to work off.

 

Any other ideas?  John what are you thinking here?

 

Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/7b7435cc/attachment-0001.html>

So, as the new guy on the other (MSFT) side of the fence, I am interested in all
of these suggestions and ideas. In addition, I have some questions/suggestions
for you.

* Would mirroring our internal repo on a commit-by-commit basis help with the
repository issues? Would it help with the ownership feelings?
* How can we be more transparent about what we are working on, and where we are
heading? A blog? A weekly posting?
* Would mirroring the repo to other formats help? Would releasing alpha binaries
be worthwhile?

I''m new, but I want to help build a community, and show that this is a
real OSS project. So, I really appreciate the discource. I think that these meta
discussions are worthwhile in helping define the community.

Jim Deville

-----Original Message-----
From: "Steve Eichert" <steve.eichert at gmail.com>
To: "ironruby-core at rubyforge.org" <ironruby-core at
rubyforge.org>
Sent: 4/28/08 10:05 AM
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from     
this blog



I can''t say that the delay has stopped me from working on a
contribution since I''ve just recently started investigating where I may
be able to lend a hand.  However, I can say that I''m much more
reluctant to jump in and start working on something since I don''t want
to work on a implementing or fixing something that has already been addressed.

I think it would be great to have a more open environment where the community
knows what the members of the IronRuby team are working on and what
they''re currently thinking about, as well as what things they
aren''t able to get to yet but are higher priority.  This would help the
community understand what they should stay away from, as well as what would be a
good place to contribute.  In order to foster a community around IronRuby I
believe there needs to be something that can rally the community around a cause.
Right now, most of the people I''ve spoken to are in a wait and see mode
with IronRuby.  It would be great if we could do something to get people in a
"what can I do to contribute value to the project" mode.

This is coming from someone who has just recently "joined" the
IronRuby community, so I may not be looking in the right places.

Cheers,
Steve

On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) <jflam at
microsoft.com<mailto:jflam at microsoft.com>> wrote:
M. David Peterson:
> > It''s far more difficult (maybe impossible) to run an OSS
project well
> > if the community members can''t update their working copies to
exactly
> > what the core team sees day-to-day. This one is most likely an MS
> issue.
>
> It''s absolutely 100% an internal MSFT issue.  Can it be fixed?
While meta-level discussions are interesting, they generally don''t
offer much in the way of concrete guidance. So let me ask this question to the
larger community:

Has working on the SVN sources (with the attendant delays in propagating to /
from our version of ''the truth'') blocked you from working on a
contribution?

Thanks,
-John
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/b3887225/attachment.html>

Yes, Yes, Yes. Do it!

Specifically,  mirroring the repo would help.   Using rubyforge has
the main repo would be better.

A blog would be fantastic, though most of the "core" team already have
blogs.. still an official IronRuby blog will regular updates would be
awesome.

Alpha binaries always encourage people to at least download and try it
out.  Some projects use this crazy thing called daily builds...

On Mon, Apr 28, 2008 at 2:41 PM, Jim Deville <jdeville at microsoft.com>
wrote:
>
>  So, as the new guy on the other (MSFT) side of the fence, I am interested
> in all of these suggestions and ideas. In addition, I have some
> questions/suggestions for you.
>
> * Would mirroring our internal repo on a commit-by-commit basis help with
> the repository issues? Would it help with the ownership feelings?
> * How can we be more transparent about what we are working on, and where we
> are heading? A blog? A weekly posting?
> * Would mirroring the repo to other formats help? Would releasing alpha
> binaries be worthwhile?
>
> I''m new, but I want to help build a community, and show that this
is a real
> OSS project. So, I really appreciate the discource. I think that these meta
> discussions are worthwhile in helping define the community.
>
> Jim Deville
>
> -----Original Message-----
> From: "Steve Eichert" <steve.eichert at gmail.com>
> To: "ironruby-core at rubyforge.org" <ironruby-core at
rubyforge.org>
> Sent: 4/28/08 10:05 AM
> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
> this blog
>
>
>
>
> I can''t say that the delay has stopped me from working on a
contribution
> since I''ve just recently started investigating where I may be able
to lend a
> hand.  However, I can say that I''m much more reluctant to jump in
and start
> working on something since I don''t want to work on a implementing
or fixing
> something that has already been addressed.
>
>  I think it would be great to have a more open environment where the
> community knows what the members of the IronRuby team are working on and
> what they''re currently thinking about, as well as what things they
aren''t
> able to get to yet but are higher priority.  This would help the community
> understand what they should stay away from, as well as what would be a good
> place to contribute.  In order to foster a community around IronRuby I
> believe there needs to be something that can rally the community around a
> cause.  Right now, most of the people I''ve spoken to are in a wait
and see
> mode with IronRuby.  It would be great if we could do something to get
> people in a "what can I do to contribute value to the project"
mode.
>
>  This is coming from someone who has just recently "joined" the
IronRuby
> community, so I may not be looking in the right places.
>
>  Cheers,
>  Steve
>
>
> On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) <jflam at
microsoft.com>
> wrote:
>
> > M. David Peterson:
> >
> >
> > > > It''s far more difficult (maybe impossible) to run
an OSS project well
> > > > if the community members can''t update their working
copies to exactly
> > > > what the core team sees day-to-day. This one is most likely
an MS
> > > issue.
> > >
> > > It''s absolutely 100% an internal MSFT issue.  Can it be
fixed?
> >
> > While meta-level discussions are interesting, they generally
don''t offer
> much in the way of concrete guidance. So let me ask this question to the
> larger community:
> >
> > Has working on the SVN sources (with the attendant delays in
propagating
> to / from our version of ''the truth'') blocked you from
working on a
> contribution?
> >
> > 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

+1 for commit by commit mirror or using (even better) using rubyforge as
primary and mirroring it back to TFS. 

+1 for daily builds (preferably automated so that no one has to spend
much time on it)

 

I honestly think that until it is primarily hosted at rubyforge, people
will complain that the project isn''t "open enough."  That
definitely
won''t quiet down everyone, but it would make great strides towards it.
But, it may simply be too early to do so since the DLR is still
evolving.

 

From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Monday, April 28, 2008 12:41 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it
soundsfrom this blog

 

So, as the new guy on the other (MSFT) side of the fence, I am
interested in all of these suggestions and ideas. In addition, I have
some questions/suggestions for you.
 
* Would mirroring our internal repo on a commit-by-commit basis help
with the repository issues? Would it help with the ownership feelings?
* How can we be more transparent about what we are working on, and where
we are heading? A blog? A weekly posting?
* Would mirroring the repo to other formats help? Would releasing alpha
binaries be worthwhile?
 
I''m new, but I want to help build a community, and show that this is a
real OSS project. So, I really appreciate the discource. I think that
these meta discussions are worthwhile in helping define the community.
 
Jim Deville
 
-----Original Message-----
From: "Steve Eichert" <steve.eichert at gmail.com>
To: "ironruby-core at rubyforge.org" <ironruby-core at
rubyforge.org>
Sent: 4/28/08 10:05 AM
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds
from      this blog
 

I can''t say that the delay has stopped me from working on a
contribution
since I''ve just recently started investigating where I may be able to
lend a hand.  However, I can say that I''m much more reluctant to jump
in
and start working on something since I don''t want to work on a
implementing or fixing something that has already been addressed. 

I think it would be great to have a more open environment where the
community knows what the members of the IronRuby team are working on and
what they''re currently thinking about, as well as what things they
aren''t able to get to yet but are higher priority.  This would help the
community understand what they should stay away from, as well as what
would be a good place to contribute.  In order to foster a community
around IronRuby I believe there needs to be something that can rally the
community around a cause.  Right now, most of the people I''ve spoken to
are in a wait and see mode with IronRuby.  It would be great if we could
do something to get people in a "what can I do to contribute value to
the project" mode.

This is coming from someone who has just recently "joined" the
IronRuby
community, so I may not be looking in the right places.

Cheers,
Steve

On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY)
<jflam at microsoft.com> wrote:

M. David Peterson:

> > It''s far more difficult (maybe impossible) to run an OSS
project
well
> > if the community members can''t update their working copies to
exactly
> > what the core team sees day-to-day. This one is most likely an MS
> issue.
>
> It''s absolutely 100% an internal MSFT issue.  Can it be fixed?
While meta-level discussions are interesting, they generally don''t
offer
much in the way of concrete guidance. So let me ask this question to the
larger community:

Has working on the SVN sources (with the attendant delays in propagating
to / from our version of ''the truth'') blocked you from working
on a
contribution?

Thanks,
-John

_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/b4448404/attachment-0001.html>

On Mon, 28 Apr 2008 12:41:02 -0600, Jim Deville <jdeville at
microsoft.com>
wrote:
> So, as the new guy on the other (MSFT) side of the fence,
Welcome, Jim! :D
> I am interested in all of these suggestions and ideas.
Great!
> In addition, I have some questions/suggestions for you.
>
> * Would mirroring our internal repo on a commit-by-commit basis help  
> with the repository issues?
Depends on which issues you are referring to, though I can''t imagine it
would hurt any of the issues, and will certainly help with many, if not  
all of them.
> Would it help with the ownership feelings?
Yes, especially if the external repository was seen as the master  
repository with daily, hourly, or per-commit syncs with the internal MSFT  
repository, not vice-versa.
> * How can we be more transparent about what we are working on, and where  
> we are heading? A blog? A weekly posting?
This is always going to be somewhat of a gray area due to the fact that  
there will always be things (e.g. new features un-related to the Ruby  
language, related products such as development tools, DLR-specific  
extensions, Silverlight, etc.) that the powers that be @ MSFT will not  
want exposed to the outside community and/or given to the community to  
control.  These are both fair and understood concerns, but I believe easy  
enough to work around.  In this regard, if a line in the sand could be  
drawn that stated something like,

  * The community owns the Ruby implementation as it relates to the  
external specs and existing Ruby applications.
  * MSFT owns the rest.

And the community was then given control -- with John and associates  
leading the way, of course -- of pushing forward the portion of the  
repository they were in control of, I believe we would all be in the exact  
position we''ve been jockeying for, that of controlling each of our  
destinies and primary areas of drive and interest.
> * Would mirroring the repo to other formats help? Would releasing alpha  
> binaries be worthwhile?
I think a per-check-in build process monitored and implemented by  
something similar to CruiseControl.NET would be ideal.  This would ensure  
that the state of the repository at any given time was well understoood,  
providing access to the resulting binaries with each new build for further  
analysis and testing by anyone who felts so inclined to access the  
binaries and begin running tests against them.  In this regard, it would  
be *great* to implement and Atom-based subscription service for keeping a  
local cache of binaries up-to-date with the repository head.  In fact,  
I''ll write that service if enough interest exists in having access to
just
such a service.
> I''m new, but I want to help build a community, and show that this
is a
> real OSS project. So, I really appreciate the discource. I think that  
> these meta discussions are worthwhile in helping define the community.
Agreed.  Looking forward to see what you are able to make of all this!   
And thanks!

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, 28 Apr 2008 12:53:55 -0600, Michael Letterle  
<michael.letterle at gmail.com> wrote:
> still an official IronRuby blog will regular updates would be
> awesome.
Not sure what legal barriers, if any, might stand in the way of using the  
existing ironruby.net domain to host a community-driven blog, but if they  
do exist yet could somehow be overcome, that would be ideal.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

Jeff Lewis wrote:
>
> +1 for commit by commit mirror or using (even better) using rubyforge as
> primary and mirroring it back to TFS.
>
> +1 for daily builds (preferably automated so that no one has to spend
> much time on it)

+1 I complete agree with David and Jeff.

-- 
Ryan Riley
ryan.riley at panesofglass.org
http://www.panesofglass.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/68524829/attachment.html>

> * Would mirroring our internal repo on a commit-by-commit basis help with
the repository issues? Would it help with the ownership feelings?
>
> I think it would help for sure.
> * How can we be more transparent about what we are working on, and where we
are heading? A blog? A weekly posting?
>
> I''m not as concerned with the medium of the information (blog,
this
mailing list, wiki) as long as the community has access to the information.
A daily or weekly or as often as possible scrum like status update that the
community would be able to see would be cool.

What did you work on since the last update
What will you be working on until the next scheduled update
What''s getting in the way of progress

This would provide the benefit of letting people have a glimpse of where the
team is focusing their attention, as well as potential areas that they could
lend a hand.  As an example, if Tomas says he''s working on X, but the
fact
that Y isn''t done yet is making it a little more difficult, and he also
makes it clear that Y isn''t something he or anyone else is going to be
able
to get to in the near future Y could be something the community tries to
lend a hand with.  I could see someone like Wayne doing a similar status
since at least from the sounds of it he''s trying to spearhead some of
the
work on ruby gems + rails.
> * Would mirroring the repo to other formats help? Would releasing alpha
binaries be worthwhile?
>
> <warning_thinking_out loud_without_giving_it_much_thought>
Conceptually a git like repo seems like it would offer some interesting
advantages.  I''m a git newbie, but from what I''ve heard and
read it really
encourages people to fork projects and play around with different ideas.
Currently, I can''t see what anyone else in the community is working on,
let
alone the IronRuby team itself.  I think  in order to foster a real
community around IronRuby we need to not only make the ironRuby team itself
more transparent, but increase the transparency of the community as a
whole.  Perhaps IronRuby should jump on the github bandwagon? :)
</warning_thinking_out_loud_without_giving_it_much_thought>
> I''m new, but I want to help build a community, and show that this
is a real OSS project. So, I really appreciate the discource. I think that these
meta discussions are worthwhile in helping define the community.
>
> I''m new (on the opposite side) and feel the same way.
Cheers,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/e9eafc17/attachment.html>

On Mon, 28 Apr 2008 15:44:26 -0500, "Ryan Riley" <ryan.riley at
panesofglass.org> wrote:
>> +1 for commit by commit mirror or using (even better) using rubyforge
as
>> primary and mirroring it back to TFS.
>>
>> +1 for daily builds (preferably automated so that no one has to spend
>> much time on it)
I also strongly agree on both points.

-mental

So, one of the "details" that are wrong is that we don''t
support multiple isolated engines in a single process.
It''s actually quite simple to do so via DLR Hosting API. The main
concept here is ScriptRuntime. This class represents the world for a dynamic
language. The class holds on loaded assemblies, .NET namespace references, etc.
Each language could also associate its own global state with the runtime.
IronRuby has all Ruby global state there: global variables table, class
hierarchy etc. So, unless you use CLR interop, there is no way how the script
could get outside this sandbox. If you want to isolate the runtimes even more
(for CLR interop) you can always create a ScriptRuntime inside a separate
app-domain.

Let''s show some example (a self-contained C# source code of a simple
IronRuby host follows):

using System.IO;
using Microsoft.Scripting.Hosting;

    class RubyHostingExample {
        public static void Main() {
            const string write = @"C:\Temp\write.rb";
            const string read = @"C:\Temp\read.rb";

            File.WriteAllText(write, @"
$x = ''Hello from runtime #1!''
C = ''some constant''

module Kernel
  def say_bye
     puts ''bye''
  end
end
");

            File.WriteAllText(read, @"
puts $x
if defined? C
  puts C
else
  puts ''C not defined''
end
say_bye rescue puts $!
puts
");

            ScriptRuntime runtime1 = ScriptRuntime.Create();
            ScriptRuntime runtime2 = ScriptRuntime.Create();

            runtime1.ExecuteFile(write);
            runtime2.ExecuteFile(read);
            runtime1.ExecuteFile(read);
        }
   }

---

Let''s compile and run it:

C:\IronRuby\Bin\Debug>csc /r:Microsoft.Scripting.dll
/r:Microsoft.Scripting.Core.dll /r:IronRuby.dll rt.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.21022.8
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.

C:\IronRuby\Bin\Debug>rt.exe
nil
C not defined
undefined local variable or method `say_bye'' for main:Object

Hello from runtime #1!
some constant
bye
---

And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).

That was easy, wasn''t it?

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of John Lam (IRONRUBY)
Sent: Monday, April 28, 2008 7:05 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog

Sanghyeon Seo:
> It seems to be a rather good overview of the status to me. I mostly
> agree, except for the accusation that "Microsoft would never back an
> OSS web framework like Rails in preference to its own".
He also gets a number of important technical details wrong about IronRuby,
I''ll respond later today.

Thanks,
-John


_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Tomas Matousek wrote:
> [snip...]
>
> And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
>
>   
Does this actually work? No one has been able to post working code on 
creating an IronPython engine in another app domain on the IronPython 
mailing list.

Can you use this to place restrictions on the app domain - like restrict 
which assemblies can be loaded and control network / filesystem access?

A working example would be a wonderful thing...

The reason I am dubious is that it seems that the code generation used 
by the DLR requires pretty much full trust in .NET 2, so *any* 
restrictions (which is usually the point of running in another app 
domain) blow up. I would dearly love to be proved wrong on this of course.

Michael Foord

> That was easy, wasn''t it?
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces
at rubyforge.org] On Behalf Of John Lam (IRONRUBY)
> Sent: Monday, April 28, 2008 7:05 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
this blog
>
> Sanghyeon Seo:
>
>   
>> It seems to be a rather good overview of the status to me. I mostly
>> agree, except for the accusation that "Microsoft would never back
an
>> OSS web framework like Rails in preference to its own".
>>     
>
> He also gets a number of important technical details wrong about IronRuby,
I''ll respond later today.
>
> 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
>

On Mon, Apr 28, 2008 at 4:19 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Tomas Matousek wrote:
> > [snip...]
> >
> > And if you want app-domain isolation, just do
> ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
> Does this actually work? No one has been able to post working code on
> creating an IronPython engine in another app domain on the IronPython
>  mailing list.
Actually, I seem to recall that this works fine in IronPython --
provided that you''re running under FullTrust.  (Which, as you pointed
out, needs to be addressed.)

--
Curt Hagenlocher
curt at hagenlocher.org

Here''s a working example (no partial trust) in Python:

import clr
clr.AddReference(''Microsoft.Scripting.Core'')

import System
from Microsoft.Scripting import SourceCodeKind
from Microsoft.Scripting.Hosting import ScriptRuntime

ad = System.AppDomain.CreateDomain(''foo'')
sr = ScriptRuntime.Create(ad)
sr.LoadAssembly(clr.GetClrType(str).Assembly)
py = sr.GetEngine(''py'')
su = py.CreateScriptSourceFromString(''import System\nprint
System.AppDomain.CurrentDomain\n'', SourceCodeKind.File)
su.Execute()

Indeed partial trust might be a problem - we''ve run into a few bugs
there on the desktop CLR where we have divergent code paths from Silverlight. 
It''s also only available on Orcas / .NET 2.0 Sp1 or later where
we''ll use anonymously hosted dynamic methods if they''re
available.  Finally I believe our "optimized module" and other
subclassing of .NET standard types won''t work because those need full
reflection.emit but I haven''t verified that.

Anyway, the issue of partial trust has been brought up with various people on
the DLR side of things and there should be a push at some point to ensure this
works.

But there are other advantages w/ app domains than just security.  You also get:
        the ability to unload code w/ a decreased worry of corruption
                This is using Thread.Abort safely.  Large amounts of code can be
safely unloaded because there''s no shared state outside of the app
domain which can be corrupted (note there''s some code in the world that
this doesn''t apply to, but it applies to most of the .NET framework).
        isolation of static variables that live outside of the script
environment
                I think Tomas alluded to this
        the ability to unload assemblies
                Ye-olde-reason to use app domains on the CLR


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Michael Foord
Sent: Monday, April 28, 2008 4:20 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog

Tomas Matousek wrote:
> [snip...]
>
> And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
>
>
Does this actually work? No one has been able to post working code on
creating an IronPython engine in another app domain on the IronPython
mailing list.

Can you use this to place restrictions on the app domain - like restrict
which assemblies can be loaded and control network / filesystem access?

A working example would be a wonderful thing...

The reason I am dubious is that it seems that the code generation used
by the DLR requires pretty much full trust in .NET 2, so *any*
restrictions (which is usually the point of running in another app
domain) blow up. I would dearly love to be proved wrong on this of course.

Michael Foord

> That was easy, wasn''t it?
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces
at rubyforge.org] On Behalf Of John Lam (IRONRUBY)
> Sent: Monday, April 28, 2008 7:05 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
this blog
>
> Sanghyeon Seo:
>
>
>> It seems to be a rather good overview of the status to me. I mostly
>> agree, except for the accusation that "Microsoft would never back
an
>> OSS web framework like Rails in preference to its own".
>>
>
> He also gets a number of important technical details wrong about IronRuby,
I''ll respond later today.
>
> 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
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

On Mon, 28 Apr 2008 13:57:21 -0600, "M. David Peterson" <m.david at
xmlhacker.com> wrote:
> On Mon, 28 Apr 2008 12:53:55 -0600, Michael Letterle
> <michael.letterle at gmail.com> wrote:
> 
>> still an official IronRuby blog will regular updates would be
>> awesome.
> 
> Not sure what legal barriers, if any, might stand in the way of using the
> existing ironruby.net domain to host a community-driven blog, but if they
> do exist yet could somehow be overcome, that would be ideal.
A Planet Venus instance set up on planet.ironruby.net might be appropriate.

-mental

Dino Viehland wrote:
> Here''s a working example (no partial trust) in Python:
>
>   
Cool! Thanks Dino. I don''t normally speak to you here. :-)

Michael
> import clr
> clr.AddReference(''Microsoft.Scripting.Core'')
>
> import System
> from Microsoft.Scripting import SourceCodeKind
> from Microsoft.Scripting.Hosting import ScriptRuntime
>
> ad = System.AppDomain.CreateDomain(''foo'')
> sr = ScriptRuntime.Create(ad)
> sr.LoadAssembly(clr.GetClrType(str).Assembly)
> py = sr.GetEngine(''py'')
> su = py.CreateScriptSourceFromString(''import System\nprint
System.AppDomain.CurrentDomain\n'', SourceCodeKind.File)
> su.Execute()
>
> Indeed partial trust might be a problem - we''ve run into a few
bugs there on the desktop CLR where we have divergent code paths from
Silverlight.  It''s also only available on Orcas / .NET 2.0 Sp1 or later
where we''ll use anonymously hosted dynamic methods if they''re
available.  Finally I believe our "optimized module" and other
subclassing of .NET standard types won''t work because those need full
reflection.emit but I haven''t verified that.
>
> Anyway, the issue of partial trust has been brought up with various people
on the DLR side of things and there should be a push at some point to ensure
this works.
>
> But there are other advantages w/ app domains than just security.  You also
get:
>         the ability to unload code w/ a decreased worry of corruption
>                 This is using Thread.Abort safely.  Large amounts of code
can be safely unloaded because there''s no shared state outside of the
app domain which can be corrupted (note there''s some code in the world
that this doesn''t apply to, but it applies to most of the .NET
framework).
>         isolation of static variables that live outside of the script
environment
>                 I think Tomas alluded to this
>         the ability to unload assemblies
>                 Ye-olde-reason to use app domains on the CLR
>
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces
at rubyforge.org] On Behalf Of Michael Foord
> Sent: Monday, April 28, 2008 4:20 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
this blog
>
> Tomas Matousek wrote:
>   
>> [snip...]
>>
>> And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
>>
>>
>>     
> Does this actually work? No one has been able to post working code on
> creating an IronPython engine in another app domain on the IronPython
> mailing list.
>
> Can you use this to place restrictions on the app domain - like restrict
> which assemblies can be loaded and control network / filesystem access?
>
> A working example would be a wonderful thing...
>
> The reason I am dubious is that it seems that the code generation used
> by the DLR requires pretty much full trust in .NET 2, so *any*
> restrictions (which is usually the point of running in another app
> domain) blow up. I would dearly love to be proved wrong on this of course.
>
> Michael Foord
>
>
>   
>> That was easy, wasn''t it?
>>
>> Tomas
>>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY)
>> Sent: Monday, April 28, 2008 7:05 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds
from this blog
>>
>> Sanghyeon Seo:
>>
>>
>>     
>>> It seems to be a rather good overview of the status to me. I mostly
>>> agree, except for the accusation that "Microsoft would never
back an
>>> OSS web framework like Rails in preference to its own".
>>>
>>>       
>> He also gets a number of important technical details wrong about
IronRuby, I''ll respond later today.
>>
>> 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
>>
>>     
>
> _______________________________________________
> 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
>

On Mon, 28 Apr 2008 17:48:38 -0600, MenTaLguY <mental at rydia.net> wrote:
>
> A Planet Venus instance set up on planet.ironruby.net might be  
> appropriate.
I had one set-up at planet.rubyon.net but them phukt things up when I  
added elastic IP''s to the various EC2 instances I had running which now
points that same domain to the wrong server.

I''ll get that fixed later this evening, but regardless, I do agree that
a
planet-style approach is the right overall approach.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, 28 Apr 2008 17:48:38 -0600, MenTaLguY <mental at rydia.net> wrote:
> A Planet Venus
BTW... Wouldn''t it be the right thing to do to get Planet Mars running
instead of Planet Venus? > http://intertwingly.net/code/mars/

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Mon, Apr 28, 2008 at 08:50:48 -0600, M. David Peterson <
m.david at xmlhacker.com> wrote:
>
> So while Charlie is correct: The IronRuby
> project needs to become more community oriented, that community
> orientation needs to come from not only MSFT''s direction, but the
> communities direction as well.
>
Very well stated. And Wayne''s list certainly helps in giving a better
understanding of what is left. Such a status sent weekly (at a minimum)
could certainly help keep everyone up-to-date. Also, nothing prevents anyone
from starting their own git or mercurial branch. If the community wants to
actively work by that method, by all means we should. That could potentially
even help with the community aspect. The only thing holding anyone back is a
desire to stay completely on the same page (a la subversion and rubyforge).
Better and more frequent communication would better serve the community in
this case.

-- 
Ryan Riley
ryan.riley at panesofglass.org
http://www.panesofglass.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080428/5820e871/attachment.html>

2008/4/29 Peter Bacon Darwin <bacondarwin at
googlemail.com>:
> I believe one of the key problems is the DLR.  As I understand, it MS makes
> a distinction between "important" stuff (i.e. the DLR) and
"peripheral"
> stuff (i.e. IronXxxx).  MS wants to have complete control over the DLR and
> is not interested in making it Open Source.  Rather the DLR code is just
> community viewable, much like the rest of the .NET framework code.  I can
> understand this since core .NET Framework code is central to the MS
strategy
> and they don''t want things sneaking in the sides.
I disagree. I think DLR is a non-problem. Reality check: do you have
any change in your mind you would like to make to DLR?

For example, (sorry for using CPython as an example; I am not familiar
with Ruby world) many people contributes to CPython runtime without
touching CPython''s custom memory allocator. Still many people
contributes to CPython standard library and C extensions without
touching CPython runtime.

-- 
Seo Sanghyeon

My point wasn''t that one needs to have access to the DLR code.  It was
that
because IronRuby is so tightly coupled to DLR at the moment, it is not
possible to remove its tethers and let it free as a proper OSS.
Pete

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Sanghyeon Seo
Sent: Tuesday,29 April 29, 2008 06:23
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from
this blog

2008/4/29 Peter Bacon Darwin <bacondarwin at
googlemail.com>:
> I believe one of the key problems is the DLR.  As I understand, it MS
makes
> a distinction between "important" stuff (i.e. the DLR) and
"peripheral"
> stuff (i.e. IronXxxx).  MS wants to have complete control over the DLR and
> is not interested in making it Open Source.  Rather the DLR code is just
> community viewable, much like the rest of the .NET framework code.  I can
> understand this since core .NET Framework code is central to the MS
strategy
> and they don''t want things sneaking in the sides.
I disagree. I think DLR is a non-problem. Reality check: do you have
any change in your mind you would like to make to DLR?

For example, (sorry for using CPython as an example; I am not familiar
with Ruby world) many people contributes to CPython runtime without
touching CPython''s custom memory allocator. Still many people
contributes to CPython standard library and C extensions without
touching CPython runtime.

-- 
Seo Sanghyeon
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Peter Bacon Darwin:
> I believe one of the key problems is the DLR.  As I understand, it MS
> makes a distinction between "important" stuff (i.e. the DLR) and
> "peripheral" stuff (i.e. IronXxxx).  MS wants to have complete
control
> over the DLR and is not interested in making it Open Source.  Rather
> the DLR code is just community viewable, much like the rest of the
> .NET framework code.  I can understand this since core .NET Framework
> code is central to the MS strategy and they don''t want things
sneaking
> in the sides.
Minor correction to this point: The DLR is Open Source in as far as the license
is concerned (which is not like the .NET Framework libraries source which is
released under a much more restrictive read-only license), which works for folks
who are interested in packaging / redistributing / forking. The DLR is does not
accept contributions from the community, but feedback is certainly welcome.

That said, the bar for feedback is set rather high on the DLR. Most folks are
not compiler implementers, and that''s the feedback that is needed
there. Most folks working on libraries do not need to know anything about how
the DLR is implemented (which is useful since that is changing rapidly right
now). However, if you''re building a language (we''re doing 3)
you have valuable feedback for the DLR team and that''s one of the goals
of IronRuby - to provide feedback to the DLR team.

The reason why the DLR does not accept contributions from the community is
because we intend to ship it in the next version of the .NET framework. And that
means that it ships inside of our commercial products like Windows. Having
community contributions in Windows is something that we simply cannot do today.
> IronRuby, IronPython and so on are not so important to MS strategy and
> they are more happy to let the community muck about with the code.  I
> believe that the long term goal is to open up the IronXxxx code much
> more to the community but the problem is that the line between the DLR
> and the IronXxxx languages is not yet nailed down.  Therefore until
> that happens MS is unlikely to hand over the project to the community.
IronPython will move to an accept contributions from the community model soon.
> I would be interested to know how often an SVN dump is created
> compared to successful check-ins going through the SNAP process.
> Ideally, every successful SNAP check-in should get automatically
> dumped out on the RubyForge SVN repos, whether it added value or broke
> the tests or whatever.  You can always have SVN tags on the
"good"
> builds and also create downloadable "good" releases on the
RubyForge
> site - this point would probably help Justin Bailey''s access
problems too.
Today we do not push to SVN on every successful SNAP check-in. That said, the
process on my machine is more-or-less "rake to_svn", with a manual
check-in after that. I would be more than happy to push on a daily basis.
> Another scenario, which /M:D alludes to if I understand correctly, is
> to allow the community to modify the code in the RubyForge project and
> then let MS select "good" builds to check back into the Team
system
> via the SNAP process.  That way, the community feels ownership of the
> project and MS get that quality control on what finally goes into
> IronRuby.
> There are obviously many technical hurdles to overcome before this
> could become reality.  In particular, there needs to be a separation
> of DLR from IronXxxx, including, probably, some kind of stable release
> of the DLR for the IronXxxx projects to work off.
Exactly. Right now the integrated model is good since it means that we progress
faster. In the future, when we move to a modular model, it means that DLR
changes will break IronRuby which means more work for everyone on this end (the
DLR devs will be happier since they''ll spend less time fixing us). The
bottom line is that work is generated - it''s just who feels the pain.
> Any other ideas?  John what are you thinking here?
I collected my thoughts in the other thread that I started last night. Thanks
for your ideas!

-John

On Mon, Apr 28, 2008 at 1:36 PM, Peter Bacon Darwin
<bacondarwin at googlemail.com> wrote:
>
>
>
>
> I believe one of the key problems is the DLR.  As I understand, it MS makes
> a distinction between "important" stuff (i.e. the DLR) and
"peripheral"
> stuff (i.e. IronXxxx).  MS wants to have complete control over the DLR and
> is not interested in making it Open Source.  Rather the DLR code is just
> community viewable, much like the rest of the .NET framework code.  I can
> understand this since core .NET Framework code is central to the MS
strategy
> and they don''t want things sneaking in the sides.
>
The DLR sources are under the Microsoft Public License as well.

>
> Another scenario, which /M:D alludes to if I understand correctly, is to
> allow the community to modify the code in the RubyForge project and then
let
> MS select "good" builds to check back into the Team system via
the SNAP
> process.  That way, the community feels ownership of the project and MS get
> that quality control on what finally goes into IronRuby.  There are
> obviously many technical hurdles to overcome before this could become
> reality.  In particular, there needs to be a separation of DLR from
> IronXxxx, including, probably, some kind of stable release of the DLR for
> the IronXxxx projects to work off.
>
>
>
At some point the DLR and the languages will have to be separated,
once the DLR stabilizes to some point.  I don''t really think the
current arraignment is viable in the long term, not from an OSS point
of view anyway.

-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

The problem with trying to branch IronRuby like that is the DLR is
likely to change from underneath it.  Not that the idea hasn''t
occurred to me before, but it''s really not a viable option in this
scenario.

On Tue, Apr 29, 2008 at 12:34 AM, Ryan Riley
<ryan.riley at panesofglass.org> wrote:
> On Mon, Apr 28, 2008 at 08:50:48 -0600, M. David Peterson
> <m.david at xmlhacker.com> wrote:
> > So while Charlie is correct: The IronRuby
> > project needs to become more community oriented, that community
> > orientation needs to come from not only MSFT''s direction, but
the
> > communities direction as well.
> >
>
> Very well stated. And Wayne''s list certainly helps in giving a
better
> understanding of what is left. Such a status sent weekly (at a minimum)
> could certainly help keep everyone up-to-date. Also, nothing prevents
anyone
> from starting their own git or mercurial branch. If the community wants to
> actively work by that method, by all means we should. That could
potentially
> even help with the community aspect. The only thing holding anyone back is
a
> desire to stay completely on the same page (a la subversion and rubyforge).
> Better and more frequent communication would better serve the community in
> this case.
>
> --
> Ryan Riley
> ryan.riley at panesofglass.org
> http://www.panesofglass.org/
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

Michael Letterle:
> In a technical fashion?  No.  From an emotional standpoint?  Yes.
> Right now IronRuby is very unstable from the view of an outside
> contributor, you don''t know if the code you''re working on
now is going
> to need /major/ changes in the next drop, and you don''t know when
> that''s going to be.  Why work on a bug that "in truth"
may already be
> fixed?
Agreed. We do maintain our external bug list in Rubyforge which folks can
monitor (are you all receiving update mails on status changes in tracker?). So
you''ll know when we''ve fixed a bug when you see the Resolution
changes from None to Accepted along with some kind of comment that says
''fixed in next release''.
> The most important change that MSFT can do is let you push to rubyforge
> DIRECTLY, none of this internal updates pushed to rubyforge once in a
> while.  I assume it''s corporate preventing this, because it really
make
> no sense otherwise.  What we have here isn''t an OSS community
project
> in the traditional sense, what we have is a Microsoft project that
> they''ve so kindly, in their infinite wisdom allow us commoners to
work
> on now and then.  Oh but you can''t see or touch the real code
until
> we''re ready to let you.  This is HIGHLY discouraging.
I''ve set the releases traditionally based on whether we had something
''interesting'' to ship. Sometimes we might go a week or even
longer before substantive changes happen in the Ruby tree. Such is life when
working on compilers - you simply do not check in very often. Remember that we
have Tomas as a full time dev and me as a part time dev on this project.
We''re hiring as well - please send me mail off-list if you''re
interested.

You''ll see more frequent changes in the DLR tree since they have more
devs working on the project.

Thanks,
-John

Peter Bacon Darwin:
> My point wasn''t that one needs to have access to the DLR code.  It
was
> that because IronRuby is so tightly coupled to DLR at the moment, it is
> not possible to remove its tethers and let it free as a proper OSS.
> Pete
Yep. BTW, this is exactly the set of arguments that are used in making the
distinction between integrated and modular systems. We are integrated now
because we are optimizing for finishing our work on the DLR (and the first set
of languages) sooner. We will become modular in the future because it lets folks
build on top of us more easily.

If you''re curious listen to Clay Christensen''s most excellent
thoughts on this topic in this podcast:
http://itc.conversationsnetwork.org/shows/detail135.html

-John

On Tue, Apr 29, 2008 at 9:12 AM, John Lam (IRONRUBY)
<jflam at microsoft.com> wrote:
> Michael Letterle:
>
>
>  > In a technical fashion?  No.  From an emotional standpoint?  Yes.
>  > Right now IronRuby is very unstable from the view of an outside
>  > contributor, you don''t know if the code you''re
working on now is going
>  > to need /major/ changes in the next drop, and you don''t know
when
>  > that''s going to be.  Why work on a bug that "in
truth" may already be
>  > fixed?
>
>  Agreed. We do maintain our external bug list in Rubyforge which folks can
monitor (are you all receiving update mails on status changes in tracker?). So
you''ll know when we''ve fixed a bug when you see the Resolution
changes from None to Accepted along with some kind of comment that says
''fixed in next release''.
>
>
Is the internal bug list maintained on RubyForge? RubyForge has been
getting alot more love then before, but I would still like to see more
community members actively use it.

>  > The most important change that MSFT can do is let you push to
rubyforge
>  > DIRECTLY, none of this internal updates pushed to rubyforge once in a
>  > while.  I assume it''s corporate preventing this, because it
really make
>  > no sense otherwise.  What we have here isn''t an OSS
community project
>  > in the traditional sense, what we have is a Microsoft project that
>  > they''ve so kindly, in their infinite wisdom allow us
commoners to work
>  > on now and then.  Oh but you can''t see or touch the real
code until
>  > we''re ready to let you.  This is HIGHLY discouraging.
>
>  I''ve set the releases traditionally based on whether we had
something ''interesting'' to ship. Sometimes we might go a week
or even longer before substantive changes happen in the Ruby tree. Such is life
when working on compilers - you simply do not check in very often. Remember that
we have Tomas as a full time dev and me as a part time dev on this project.
We''re hiring as well - please send me mail off-list if you''re
interested.
"Check-in early and often", it doesn''t matter if the changes
are
interesting or there''s new features, maybe something that
isn''t
interesting to you that seems mundane is something that causes another
developer to be able to create something new and interesting.  OSS
development is all about collaboration, collaborating is hard when one
is left in the dark until something "interesting" happens :)



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

Steve Eichert:
>       * How can we be more transparent about what we are working on, and
> where we are heading? A blog? A weekly posting?
>
> I''m not as concerned with the medium of the information (blog,
this
> mailing list, wiki) as long as the community has access to the
> information.  A daily or weekly or as often as possible scrum like
> status update that the community would be able to see would be cool.
>
> What did you work on since the last update
> What will you be working on until the next scheduled update
> What''s getting in the way of progress
This is an excellent idea - would folks prefer a Monday or a Friday update?
> <warning_thinking_out loud_without_giving_it_much_thought>
> Conceptually a git like repo seems like it would offer some
> interesting advantages.  I''m a git newbie, but from what
I''ve heard
> and read it really encourages people to fork projects and play around
> with different ideas.  Currently, I can''t see what anyone else in
the
> community is working on, let alone the IronRuby team itself.  I think
> in order to foster a real community around IronRuby we need to not
> only make the ironRuby team itself more transparent, but increase the
> transparency of the community as a whole.  Perhaps IronRuby should
> jump on the github bandwagon? :)
> </warning_thinking_out_loud_without_giving_it_much_thought>
The nice thing about GIT is that you can use they''re GIT->SVN bridge
and work in a GIT repro on your own box while syncing changes to SVN. So
there''s nothing stopping you from using GIT today if you want ...

Thanks,
-John

M. David Peterson:
> I agree.  If I am remembering correctly, one of the primary reasons
> behind the dual-repository approach is the need to run a myriad of
> internal tests  from a test suite that reaches farther and deeper than
> just IronRuby, and therefore can not see the light of day outside the
> MSFT firewall.
There are several issues around this. We run our tests against internal drops of
Silverlight (remember we''re building IronRuby while simultaneously
building DLR *and* CoreCLR). Externals won''t be able to see this stuff,
and to keep our tree consistent we need to continue to test and run against
CoreCLR.
> John, is this an accurate assessment?  If yes, while I certainly
> recognize the need to run the code against internal test suites,
> couldn''t it be looked at from the opposite perspective?That of:
We, the
> community, tell you, the big bad corporate firewall, when you get to
> gain access to *our* code to run your tests.  We will continue on our
> way checking it whatever we want whenever we want, and you can use
> repository revisions as a marker to determine what can be viewed as
> "blessed" and what can not as far as releases are concerned.
This is largely a philosophical issue - do you want to resolve build breaks when
you sync or do you want to resolve build breaks when you commit. The former is
worse than the latter, especially when it takes a significant amount of time to
see if things work (40 minutes today).
> If it takes a few extra weeks to take a particular
> revision of the repository through the internal ringer before getting
> the official rubber stamp, then so be it.
> It wouldn''t be getting in the way of development progress, and if
not
> mistaken, this is really the core of the argument as to why the process
> is currently broken.
This will impede progress a lot more than you think it would ... remember -
you''re writing library code on top of a changing IronRuby compiler +
runtime which itself is built on top of a changing DLR which is itself built on
top of a changing CoreCLR (aka Silverlight CLR). One of our DLR devs recently
spent 30 hours debugging a buffer overrun in a daily build of CoreCLR that was
fixed in a subsequent build. Is this the world that you really want to live in?

Thanks,
-John

John Lam (IRONRUBY) wrote:
> The nice thing about GIT is that you can use they''re GIT->SVN
bridge and work in a GIT repro on your own box while syncing changes to SVN. So
there''s nothing stopping you from using GIT today if you want ...
I''ve been  using git-svn for a while now, and it''s pretty
nice. I''m not
using the branching all that much (don''t like having long periods of 
work live only on my machine) but the local committing is oddly satisfying.

- Charlie

Antonio Cangiano:
> The development
> process behind JRuby and Rubinius is very open, while IronRuby''s
one is
> not nearly enough so.
Impressions are important, and we''re working to fix that now.
> While granted IronRuby may appeal to less people than Rubinius or
> JRuby, I still feel that the development process could benefit a lot
> from incremental/daily commits, more transparency and a greater deal of
> control handed to the community.
Agreed - working on this too.
> As Charlie mentioned somewhere else, JRuby is not Sun''s, it
belongs to
> the community. That statement is entirely backed up by facts, but
I''m
> afraid that, at this stage, it isn'' possible to claim the same for
> IronRuby.
We will make this happen.
> This, coupled with the fact that ASP.NET and languages like
> C# are clearly Microsoft''s main interest, lead me to believe that
> IronRuby is not living up to its full potential.
Those are orthogonal issues. Microsoft isn''t "one" entity -
it''s many, many teams. Those teams that create a product are naturally
invested in its success. We have lots of 3rd party software that runs on our
platforms - we''re a platform company. We have lived in this
co-opetition space for a long, long time.

Thanks,
-John

Michael Letterle:
> Is the internal bug list maintained on RubyForge? RubyForge has been
> getting alot more love then before, but I would still like to see more
> community members actively use it.
We don''t have an internal bug list (well we do for DLR bugs etc but
those aren''t important around here). All of our bugs live on Rubyforge.
> "Check-in early and often", it doesn''t matter if the
changes are
> interesting or there''s new features, maybe something that
isn''t
> interesting to you that seems mundane is something that causes another
> developer to be able to create something new and interesting.  OSS
> development is all about collaboration, collaborating is hard when one
> is left in the dark until something "interesting" happens :)
Working on this now.

Thanks,
-John

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Lam (IRONRUBY) wrote:
| [...]
| We will make this happen.

Great.

|> This, coupled with the fact that ASP.NET and languages like
|> C# are clearly Microsoft''s main interest, lead me to believe that
|> IronRuby is not living up to its full potential.
|
| Those are orthogonal issues. Microsoft isn''t "one" entity -
it''s many,
many teams. Those teams that create a product are naturally invested in
its success. We have lots of 3rd party software that runs on our
platforms - we''re a platform company. We have lived in this
co-opetition
space for a long, long time.

Agreed, it''s the same in IBM, with many teams and many realities. I
mentioned Microsoft''s interest (in terms of resources allocated and
overall strategy) even if it''s orthogonal to the issue at hand because
I
think that, while not a deal breaker, this aspect can become an
aggravating factor if the project is not able to attract sustainable
contributions from the community.

Cheers,
Antonio
- --
http://antoniocangiano.com - Zen and the Art of Programming
http://stacktrace.it - Aperiodico di resistenza informatica
http://math-blog.com - Math Blog: Mathematics is wonderful!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgXNF0ACgkQqCqsu0qUj9S2LACffcNXPSi7uNh944mMNU2aOyrS
4vkAoNtmO2RVLqvzKgf24OwfKGtMg26J
=Oxop
-----END PGP SIGNATURE-----

> > What did you work on since the last update
> > What will you be working on until the next scheduled update
> > What''s getting in the way of progress
>
> This is an excellent idea - would folks prefer a Monday or a Friday
> update?
>
I don''t have a strong preference but I think I''d vote for a
Monday update.

>
> > <warning_thinking_out loud_without_giving_it_much_thought>
> > Conceptually a git like repo seems like it would offer some
> > interesting advantages.  I''m a git newbie, but from what
I''ve heard
> > and read it really encourages people to fork projects and play around
> > with different ideas.  Currently, I can''t see what anyone
else in the
> > community is working on, let alone the IronRuby team itself.  I think
> > in order to foster a real community around IronRuby we need to not
> > only make the ironRuby team itself more transparent, but increase the
> > transparency of the community as a whole.  Perhaps IronRuby should
> > jump on the github bandwagon? :)
> > </warning_thinking_out_loud_without_giving_it_much_thought>
>
> The nice thing about GIT is that you can use they''re GIT->SVN
bridge and
> work in a GIT repro on your own box while syncing changes to SVN. So
there''s
> nothing stopping you from using GIT today if you want ...

I''ve been thinking about this.  One of the things that triggered this
thought is some things I''ve seen going on in the Rails community.  It
seems
like a lot of people are forking the master to work on ideas.  Since
they''re
using github, everyone can see the forks that are out there and see what
people are working on, as well as checkout the actual code they''re
committing.  It would be cool to be able to see what the various community
members are working on, pull in their changes, and etc.

Cheers,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080429/45d6193f/attachment.html>

Agreed. On my last project I was using git-svn for everything except for merging
across SVN branches. Did that for months and loved it! Man I miss stash :)

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, April 29, 2008 7:15 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog

John Lam (IRONRUBY) wrote:
> The nice thing about GIT is that you can use they''re GIT->SVN
bridge and work in a GIT repro on your own box while syncing changes to SVN. So
there''s nothing stopping you from using GIT today if you want ...
I''ve been  using git-svn for a while now, and it''s pretty
nice. I''m not
using the branching all that much (don''t like having long periods of
work live only on my machine) but the local committing is oddly satisfying.

- Charlie
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

On Tue, 29 Apr 2008 08:06:57 -0600, John Lam (IRONRUBY)  
<jflam at microsoft.com> wrote:
> Is this the world that you really want to live in?
Can I think about it?  ;-)

I kid.  No, I do recognize your point.  It seems a lot of good things are  
becoming of this overall conversation, so regardless of how things are  
structured it seems we''re headed in the right direction.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Tue, 29 Apr 2008 07:53:29 -0600, John Lam (IRONRUBY)  
<jflam at microsoft.com> wrote:
> Friday update?
+1: Gives us something to hack on over the weekend.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

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

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

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

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

Michael Letterle:
> 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.
Agreed - we still have to build the require mechanism for libraries that are
hosted in different assemblies or within the same assembly.

Thanks,
-John

For consistency, can we also separate the other standard libraries such as
digest, openssl, etc (that require explicit loading) into separate assemblies?
This of course, first requires us to be able to load such assemblies.

There will of course be an ever increasing set of such libraries, so it would be
nice to have a relatively lightweight process to allow such new
directories/libraries to be created.

Note, some of these libraries might be implemented using a combination of Ruby
and C# code.

I hope this mechanism will enable people to upload prototypes of what
they''re working on, so that we don''t need to wait until
something is complete and polished before seeing it.

Perhaps we could have a generic IronRuby.Misc that people could create
directories  beneath initially, which could then be moved to top level status
once they''ve matured.

Cheers, Wayne.

I don''t think we should go crazy and create one dll per library.
Loading dlls has some overhead. Since digest and openssl are just IronRuby stubs
for functionality already implemented in BCL, it could be in one dll. I need to
figure out how to do loading of Ruby libraries contained in an assembly, but I
think it could be done.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Wayne Kelly
Sent: Wednesday, April 30, 2008 4:40 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Opening up our tree to external committers


For consistency, can we also separate the other standard libraries such as
digest, openssl, etc (that require explicit loading) into separate assemblies?
This of course, first requires us to be able to load such assemblies.

There will of course be an ever increasing set of such libraries, so it would be
nice to have a relatively lightweight process to allow such new
directories/libraries to be created.

Note, some of these libraries might be implemented using a combination of Ruby
and C# code.

I hope this mechanism will enable people to upload prototypes of what
they''re working on, so that we don''t need to wait until
something is complete and polished before seeing it.

Perhaps we could have a generic IronRuby.Misc that people could create
directories  beneath initially, which could then be moved to top level status
once they''ve matured.

Cheers, Wayne.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Are you suggesting that long term - modules like digest and openssl remain in
the IronRuby.Libraries and be automatically loaded at startup?

I had assumed that this was just a temporary hack and I think long term it is
the wrong way to go. There are both performance and compatibility arguments ...
Firstly, the overhead of loading non-builtin modules such as digest should only
be incurred for those applications that explicitly choose to require it.
Secondly, by automatically loading such modules, we are poluting the global
namespace and setting up possible collisions with programmer created classes.
In general, loading a module can have side effects. At present there are only a
handful of such modules, but long term there will be dozens, if not hundreds.
Matz should be the one that decides which modules get loaded automatically and
which require explicit loading.

Cheers, Wayne.
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
> Tomas Matousek
> Sent: Thursday, 1 May 2008 11:38 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Opening up our tree to external
> committers
>
> I don''t think we should go crazy and create one dll per
> library. Loading dlls has some overhead. Since digest and
> openssl are just IronRuby stubs for functionality already
> implemented in BCL, it could be in one dll. I need to figure
> out how to do loading of Ruby libraries contained in an
> assembly, but I think it could be done.
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
> Sent: Wednesday, April 30, 2008 4:40 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Opening up our tree to external
> committers
>
>
> For consistency, can we also separate the other standard
> libraries such as digest, openssl, etc (that require explicit
> loading) into separate assemblies?
> This of course, first requires us to be able to load such assemblies.
>
> There will of course be an ever increasing set of such
> libraries, so it would be nice to have a relatively
> lightweight process to allow such new directories/libraries
> to be created.
>
> Note, some of these libraries might be implemented using a
> combination of Ruby and C# code.
>
> I hope this mechanism will enable people to upload prototypes
> of what they''re working on, so that we don''t need to wait
> until something is complete and polished before seeing it.
>
> Perhaps we could have a generic IronRuby.Misc that people
> could create directories  beneath initially, which could then
> be moved to top level status once they''ve matured.
>
> Cheers, Wayne.
> _______________________________________________
> 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
>

It may not be /too/ bad if the intent is to load the CLR code, but not
expose it to the ruby runtime until a "require" is called for that
library.. though I agree, I''d rather have it implemented as separate
dlls.  This also becomes relevant when we start talking about IronRuby
and silverlight, not all silverlight apps are going to need all
libraries (or even most) keeping it small is important, but if a
library is needed it shouldn''t need to take a bunch of baggage with
it.

On Wed, Apr 30, 2008 at 10:55 PM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
>  Are you suggesting that long term - modules like digest and openssl remain
in the IronRuby.Libraries and be automatically loaded at startup?
>
>  I had assumed that this was just a temporary hack and I think long term it
is the wrong way to go. There are both performance and compatibility arguments
... Firstly, the overhead of loading non-builtin modules such as digest should
only be incurred for those applications that explicitly choose to require it.
Secondly, by automatically loading such modules, we are poluting the global
namespace and setting up possible collisions with programmer created classes.
>  In general, loading a module can have side effects. At present there are
only a handful of such modules, but long term there will be dozens, if not
hundreds. Matz should be the one that decides which modules get loaded
automatically and which require explicit loading.
>
>  Cheers, Wayne.
>
>  > -----Original Message-----
>  > From: ironruby-core-bounces at rubyforge.org
>  > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
>  > Tomas Matousek
>  > Sent: Thursday, 1 May 2008 11:38 AM
>  > To: ironruby-core at rubyforge.org
>  > Subject: Re: [Ironruby-core] Opening up our tree to external
>  > committers
>  >
>  > I don''t think we should go crazy and create one dll per
>  > library. Loading dlls has some overhead. Since digest and
>  > openssl are just IronRuby stubs for functionality already
>  > implemented in BCL, it could be in one dll. I need to figure
>  > out how to do loading of Ruby libraries contained in an
>  > assembly, but I think it could be done.
>  >
>  > Tomas
>  >
>  > -----Original Message-----
>  > From: ironruby-core-bounces at rubyforge.org
>  > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne
Kelly
>  > Sent: Wednesday, April 30, 2008 4:40 PM
>  > To: ironruby-core at rubyforge.org
>  > Subject: Re: [Ironruby-core] Opening up our tree to external
>  > committers
>  >
>  >
>  > For consistency, can we also separate the other standard
>  > libraries such as digest, openssl, etc (that require explicit
>  > loading) into separate assemblies?
>  > This of course, first requires us to be able to load such assemblies.
>  >
>  > There will of course be an ever increasing set of such
>  > libraries, so it would be nice to have a relatively
>  > lightweight process to allow such new directories/libraries
>  > to be created.
>  >
>  > Note, some of these libraries might be implemented using a
>  > combination of Ruby and C# code.
>  >
>  > I hope this mechanism will enable people to upload prototypes
>  > of what they''re working on, so that we don''t need
to wait
>  > until something is complete and polished before seeing it.
>  >
>  > Perhaps we could have a generic IronRuby.Misc that people
>  > could create directories  beneath initially, which could then
>  > be moved to top level status once they''ve matured.
>  >
>  > Cheers, Wayne.
>  > _______________________________________________
>  > 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

One advantage of having "one dll per library" is that you can make
decisions
about which DLL to load based solely on the library name.  Once you have
multiple libraries per DLL, you need a more complicated probing or mapping
scheme to know which assembly to load.

On Wed, Apr 30, 2008 at 6:38 PM, Tomas Matousek <
Tomas.Matousek at microsoft.com> wrote:
> I don''t think we should go crazy and create one dll per library.
Loading
> dlls has some overhead. Since digest and openssl are just IronRuby stubs
for
> functionality already implemented in BCL, it could be in one dll. I need to
> figure out how to do loading of Ruby libraries contained in an assembly,
but
> I think it could be done.
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
> Sent: Wednesday, April 30, 2008 4:40 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Opening up our tree to external committers
>
>
>  For consistency, can we also separate the other standard libraries such
> as digest, openssl, etc (that require explicit loading) into separate
> assemblies?
> This of course, first requires us to be able to load such assemblies.
>
> There will of course be an ever increasing set of such libraries, so it
> would be nice to have a relatively lightweight process to allow such new
> directories/libraries to be created.
>
> Note, some of these libraries might be implemented using a combination of
> Ruby and C# code.
>
> I hope this mechanism will enable people to upload prototypes of what
> they''re working on, so that we don''t need to wait until
something is
> complete and polished before seeing it.
>
> Perhaps we could have a generic IronRuby.Misc that people could create
> directories  beneath initially, which could then be moved to top level
> status once they''ve matured.
>
> Cheers, Wayne.
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080430/91173ea4/attachment.html>

On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher  
<curt at hagenlocher.org> wrote:
> One advantage of having "one dll per library" is that you can
make
> decisions about which DLL to load based solely on the library name.   
> Once you have multiple libraries per DLL, you need a more complicated  
> probing or mapping scheme to know which assembly to load.
Why not meet half way: Generate netmodules who''s primary purpose, if I
am
remembering correctly, is the ability to be merged together into a final  
assembly.  Again, if I remembering correctly, the original idea was that  
you could have one team writing code in VB.NET and another in C#, and they  
could both compile to netmodules which are then merged into a final  
assembly via a post compilation merging process.

WARNING: My memory of the purpose of netmodules might be completely out of  
whack.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Wed, 30 Apr 2008 19:38:02 -0600, Tomas Matousek  
<Tomas.Matousek at microsoft.com> wrote:
> I need to figure out how to do loading of Ruby libraries contained in an  
> assembly, but I think it could be done.
Didn''t we have this (or a very similar) conversation a while back?

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

David,
>  Why not meet half way: Generate netmodules who''s primary purpose,
if I am
> remembering correctly, is the ability to be merged together into a final
> assembly.  Again, if I remembering correctly, the original idea was that
you
> could have one team writing code in VB.NET and another in C#, and they
could
> both compile to netmodules which are then merged into a final assembly via
a
> post compilation merging process.
>
>  WARNING: My memory of the purpose of netmodules might be completely out of
> whack.
You can certainly do that way. I''ve worked with fairly large code
bases that do this, and you can certainly do the merging with link.exe
even. That said, this doesn''t really solve the loading issue Curt
mentions, which is probably the bigger deal.


-- 
Tomas Restrepo
http://www.winterdom.com/weblog/

Each library (like digest, openssl) would have its own initialize method.
Require would call that initializer. The initializer pollutes the global
namespace by types contained in the library.
Therefore there is no performance hit nor incompatibility if you don''t
do require. And loading of such library is a matter of running the initializer.
No probing for assemblies on disk. Therefore grouping libraries to a single
assembly is better performance-wise.

The size of IL of libraries that are just thin wrappers on top of functionality
that is already contained in Silverlight distribution is imo negligible. On the
other hand, e.g. Oniguruma or Yaml libraries are huge. Therefore it''s a
good idea to have them in a separate assembly.

The only issue that needs to be solved is how to efficiently discover libraries
embedded in .NET assemblies.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Curt Hagenlocher
Sent: Wednesday, April 30, 2008 8:14 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Opening up our tree to external committers

One advantage of having "one dll per library" is that you can make
decisions about which DLL to load based solely on the library name.  Once you
have multiple libraries per DLL, you need a more complicated probing or mapping
scheme to know which assembly to load.
On Wed, Apr 30, 2008 at 6:38 PM, Tomas Matousek <Tomas.Matousek at
microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:
I don''t think we should go crazy and create one dll per library.
Loading dlls has some overhead. Since digest and openssl are just IronRuby stubs
for functionality already implemented in BCL, it could be in one dll. I need to
figure out how to do loading of Ruby libraries contained in an assembly, but I
think it could be done.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Wayne Kelly
Sent: Wednesday, April 30, 2008 4:40 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] Opening up our tree to external committers

For consistency, can we also separate the other standard libraries such as
digest, openssl, etc (that require explicit loading) into separate assemblies?
This of course, first requires us to be able to load such assemblies.

There will of course be an ever increasing set of such libraries, so it would be
nice to have a relatively lightweight process to allow such new
directories/libraries to be created.

Note, some of these libraries might be implemented using a combination of Ruby
and C# code.

I hope this mechanism will enable people to upload prototypes of what
they''re working on, so that we don''t need to wait until
something is complete and polished before seeing it.

Perhaps we could have a generic IronRuby.Misc that people could create
directories  beneath initially, which could then be moved to top level status
once they''ve matured.

Cheers, Wayne.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080430/13b5bf73/attachment.html>

On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson <m.david at
xmlhacker.com>
wrote:
> On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher <curt at
hagenlocher.org>
> wrote:
>
> One advantage of having "one dll per library" is that you can
make
> > decisions about which DLL to load based solely on the library name. 
Once
> > you have multiple libraries per DLL, you need a more complicated
probing or
> > mapping scheme to know which assembly to load.
> >
>
> Why not meet half way: Generate netmodules who''s primary purpose,
if I am
> remembering correctly, is the ability to be merged together into a final
> assembly.

This isn''t dynamic, though.  There has to be a single manifest for the
assembly that lists all the netmodules.  I imagine it would be desirable to
be able to add a new library simply by copying it into the appropriate
directory without having to register it or relink the assembly.

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080430/a5159500/attachment.html>

On Wed, 30 Apr 2008 21:43:09 -0600, Tomas Restrepo <tomas at
winterdom.com>
wrote:
> You can certainly do that way. I''ve worked with fairly large code
> bases that do this, and you can certainly do the merging with link.exe
> even.
Cool :)  Glad to see my memory hasn''t completely failed me! ;-)
> That said, this doesn''t really solve the loading issue Curt
> mentions, which is probably the bigger deal.
Is this in reference to distributing a larger collection of Ruby libs  
inside of a DLL instead of distributing them as seperate .rb files? 
I''ll
read back through the thread to see if I can decipher, but if yes, it  
seems to me the easiest approach is to simply use embedded resources.  In  
fact, now that I think about it, this is definitely a conversation we have  
had in the past, and if not mistaken the general consensus was to  
implement a ''resload'' keyword to reference embedded resources
such that
the functionality of the load keyword could be left unmodified.

Please disregard the above if this is not what the conversation is related  
to.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Wed, 30 Apr 2008 21:49:46 -0600, Curt Hagenlocher  
<curt at hagenlocher.org> wrote:
> This isn''t dynamic, though.  There has to be a single manifest for
the
> assembly that lists all the netmodules.  I imagine it would be desirable  
> to be able to add a new library simply by copying it into the  
> appropriate directory without having to register it or relink the  
> assembly.
I obviously need to catch up on this thread to better understand the topic  
at hand.

/me is catching up...

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

On Wed, Apr 30, 2008 at 8:43 PM, Tomas Matousek <
Tomas.Matousek at microsoft.com> wrote:
>  The only issue that needs to be solved is how to efficiently discover
> libraries embedded in .NET assemblies.
>
It''s certainly the *primary* issue. :)

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080430/740056f3/attachment-0001.html>

On Wed, 30 Apr 2008 21:54:58 -0600, M. David Peterson  
<m.david at xmlhacker.com> wrote:
> load
did I say load keyword?  *YIKES*!  I need to stop being such a language  
whore. ;-)

I mean require and the related thread is @  
http://rubyforge.org/pipermail/ironruby-core/2008-February/000858.html

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

Actually couldn''t you have something like..

openssl.rb:

require ''IronRuby.Libraries.dll, version=xxxxxx, blahblabh''

and then just "require ''openssl''" in your app?

On Wed, Apr 30, 2008 at 11:58 PM, Curt Hagenlocher <curt at
hagenlocher.org> wrote:
>
> On Wed, Apr 30, 2008 at 8:43 PM, Tomas Matousek
> <Tomas.Matousek at microsoft.com> wrote:
>
>
> >
> >
> >
> >
> > The only issue that needs to be solved is how to efficiently discover
> libraries embedded in .NET assemblies.
>
> It''s certainly the *primary* issue. :)
>
> --
>
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

Yes, I think I''ve already mentioned it :)

You would need to identify the library inside the assembly. But that could be
easy - just add the type name:

require ''MyTypeThatContainsLibInitializer, IronRuby.Libraries,
version=xxxxxx, blahblabh''

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 9:06 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Opening up our tree to external committers

Actually couldn''t you have something like..

openssl.rb:

require ''IronRuby.Libraries.dll, version=xxxxxx, blahblabh''

and then just "require ''openssl''" in your app?

On Wed, Apr 30, 2008 at 11:58 PM, Curt Hagenlocher <curt at
hagenlocher.org> wrote:
>
> On Wed, Apr 30, 2008 at 8:43 PM, Tomas Matousek
> <Tomas.Matousek at microsoft.com> wrote:
>
>
> >
> >
> >
> >
> > The only issue that needs to be solved is how to efficiently discover
> libraries embedded in .NET assemblies.
>
> It''s certainly the *primary* issue. :)
>
> --
>
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
>  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

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

On Wed, 30 Apr 2008 22:18:54 -0600, Tomas Matousek  
<Tomas.Matousek at microsoft.com> wrote:
> Interesting has this e-mail just arrived?
Not sure. I''ve been away most of the day, so have no clue when it  
officially arrived.  The timestamp suggests it arrived soon after you sent  
it, but that, quite obviously, means nothing given the timestamp
wouldn''t
have been effected by a delayed delivery.

I''ve noticed there tends to be somewhat of a delay in delivery of mail
sent to the IronRuby list, though I haven''t seen anything quite as
delayed
as 9 hours.

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david at 3rdandUrban.com | m.david at amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |  
http://www.oreillynet.com/pub/au/2354

Splitting into different DLLs complicate things for Silverlight.

On the desktop you can have the assembly loading be dynamic with a foo.rb
wrapper for a library. However, Silverlight (today) requires the DLL would have
to be downloaded to the client first before loading. In other words, the
AppManifest.xaml (and the XAP, but that''s optional) would have to know
about ALL the IronRuby Library DLLs you "could" want to use. We
automate the generation of this file and XAP, so that tool (Chiron) would need
to know this. While this isn''t a direct problem, it does make the # of
assemblies you need to include with your app go from 2 to n. Splitting could
potentially save download size, but figuring out which DLLs to include is hard
(see below).

Are there other options for how to get DLLs onto a client machine?

To get this option out of the way, we can''t bake this logic (download
an assembly when you require it) into our Silverlight integration, or even push
the responsibility on the libraries themselves. Downloading in SL requires
asynchronous requests, and we can''t pause user code to do this (aka.
Continuations). We could technically implement it by hacking on XmlHttpRequest
directly to get synchronous support, but ugh. If network connection gets flakey
your browser hangs ... not very pleasant.

Do we introduce a config.rb to Silverlight that lets you define the closure of
all the assemblies you''ll need? This file gets loaded first, it
triggers the downloads the necessary assemblies, and then load the real program?

Again, the AppManifest solution will work, but it''s not very
dynamic-language-esc, and becomes more apparent if we split the libraries out.
I''m just brainstorming for better solutions to this. Ideas?

~Jimmy
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
> Sent: Wednesday, April 30, 2008 8:50 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Opening up our tree to external
> committers
>
> On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson
> <m.david at xmlhacker.com> wrote:
>
>
>       On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher
> <curt at hagenlocher.org> wrote:
>
>
>
>               One advantage of having "one dll per library" is
that you can make
> decisions about which DLL to load based solely on the library name.
> Once you have multiple libraries per DLL, you need a more complicated
> probing or mapping scheme to know which assembly to load.
>
>
>
>       Why not meet half way: Generate netmodules who''s primary
purpose, if
> I am remembering correctly, is the ability to be merged together into
> a final assembly.
>
>
> This isn''t dynamic, though.  There has to be a single manifest for
the
> assembly that lists all the netmodules.  I imagine it would be
> desirable to be able to add a new library simply by copying it into
> the appropriate directory without having to register it or relink the
> assembly.
>
> --
> Curt Hagenlocher
> curt at hagenlocher.org

Whoa, if you want to actually understand the first paragraph, read this version
=P
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Thursday, May 01, 2008 12:38 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Opening up our tree to external committers
>
> Splitting into different DLLs complicates things for Silverlight.
>
> On the desktop you can have the assembly loading be dynamic with a
> foo.rb wrapper for a library. However, Silverlight (today) requires
> DLLs to be downloaded to the client first before loading. In
> other words, the AppManifest.xaml
> would have to know about ALL the IronRuby Library DLLs you
"could" want
> to use (and the XAP, but that''s optional).
> We automate the generation of this file and XAP, so that tool
> (Chiron) would need to know this. While this isn''t a direct
problem, it
> does make the # of assemblies you need to include with your app go from
> 2 to n. Splitting could potentially save download size, but figuring
> out which DLLs to include is hard (see below).
>
> Are there other options for how to get DLLs onto a client machine?
>
> To get this option out of the way, we can''t bake this logic
(download
> an assembly when you require it) into our Silverlight integration, or
> even push the responsibility on the libraries themselves. Downloading
> in SL requires asynchronous requests, and we can''t pause user code
to
> do this (aka. Continuations). We could technically implement it by
> hacking on XmlHttpRequest directly to get synchronous support, but ugh.
> If network connection gets flakey your browser hangs ... not very
> pleasant.
>
> Do we introduce a config.rb to Silverlight that lets you define the
> closure of all the assemblies you''ll need? This file gets loaded
first,
> it triggers the downloads the necessary assemblies, and then load the
> real program?
>
> Again, the AppManifest solution will work, but it''s not very
dynamic-
> language-esc, and becomes more apparent if we split the libraries out.
> I''m just brainstorming for better solutions to this. Ideas?
>
> ~Jimmy
>
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> > bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
> > Sent: Wednesday, April 30, 2008 8:50 PM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] Opening up our tree to external
> > committers
> >
> > On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson
> > <m.david at xmlhacker.com> wrote:
> >
> >
> >       On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher
> > <curt at hagenlocher.org> wrote:
> >
> >
> >
> >               One advantage of having "one dll per library"
is that
> > you can make decisions about which DLL to load based solely on the
> library name.
> > Once you have multiple libraries per DLL, you need a more complicated
> > probing or mapping scheme to know which assembly to load.
> >
> >
> >
> >       Why not meet half way: Generate netmodules who''s
primary
> > purpose, if I am remembering correctly, is the ability to be merged
> > together into a final assembly.
> >
> >
> > This isn''t dynamic, though.  There has to be a single
manifest for
> the
> > assembly that lists all the netmodules.  I imagine it would be
> > desirable to be able to add a new library simply by copying it into
> > the appropriate directory without having to register it or relink the
> > assembly.
> >
> > --
> > Curt Hagenlocher
> > curt at hagenlocher.org
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

Would a multi-file assembly be a good fit for this? I haven''t worked
much
with them, so I''m not sure about including multiple namespaces within
one,
but I would imagine it''s entirely possible.

On Wed, Apr 30, 2008 at 10:02 PM, Michael Letterle <
michael.letterle at gmail.com> wrote:
> It may not be /too/ bad if the intent is to load the CLR code, but not
> expose it to the ruby runtime until a "require" is called for
that
> library.. though I agree, I''d rather have it implemented as
separate
> dlls.  This also becomes relevant when we start talking about IronRuby
> and silverlight, not all silverlight apps are going to need all
> libraries (or even most) keeping it small is important, but if a
> library is needed it shouldn''t need to take a bunch of baggage
with
> it.
>
> On Wed, Apr 30, 2008 at 10:55 PM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
> >
> >  Are you suggesting that long term - modules like digest and openssl
> remain in the IronRuby.Libraries and be automatically loaded at startup?
> >
> >  I had assumed that this was just a temporary hack and I think long
term
> it is the wrong way to go. There are both performance and compatibility
> arguments ... Firstly, the overhead of loading non-builtin modules such as
> digest should only be incurred for those applications that explicitly
choose
> to require it. Secondly, by automatically loading such modules, we are
> poluting the global namespace and setting up possible collisions with
> programmer created classes.
> >  In general, loading a module can have side effects. At present there
> are only a handful of such modules, but long term there will be dozens, if
> not hundreds. Matz should be the one that decides which modules get loaded
> automatically and which require explicit loading.
> >
> >  Cheers, Wayne.
> >
> >  > -----Original Message-----
> >  > From: ironruby-core-bounces at rubyforge.org
> >  > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
> >  > Tomas Matousek
> >  > Sent: Thursday, 1 May 2008 11:38 AM
> >  > To: ironruby-core at rubyforge.org
> >  > Subject: Re: [Ironruby-core] Opening up our tree to external
> >  > committers
> >  >
> >  > I don''t think we should go crazy and create one dll per
> >  > library. Loading dlls has some overhead. Since digest and
> >  > openssl are just IronRuby stubs for functionality already
> >  > implemented in BCL, it could be in one dll. I need to figure
> >  > out how to do loading of Ruby libraries contained in an
> >  > assembly, but I think it could be done.
> >  >
> >  > Tomas
> >  >
> >  > -----Original Message-----
> >  > From: ironruby-core-bounces at rubyforge.org
> >  > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
Wayne Kelly
> >  > Sent: Wednesday, April 30, 2008 4:40 PM
> >  > To: ironruby-core at rubyforge.org
> >  > Subject: Re: [Ironruby-core] Opening up our tree to external
> >  > committers
> >  >
> >  >
> >  > For consistency, can we also separate the other standard
> >  > libraries such as digest, openssl, etc (that require explicit
> >  > loading) into separate assemblies?
> >  > This of course, first requires us to be able to load such
assemblies.
> >  >
> >  > There will of course be an ever increasing set of such
> >  > libraries, so it would be nice to have a relatively
> >  > lightweight process to allow such new directories/libraries
> >  > to be created.
> >  >
> >  > Note, some of these libraries might be implemented using a
> >  > combination of Ruby and C# code.
> >  >
> >  > I hope this mechanism will enable people to upload prototypes
> >  > of what they''re working on, so that we don''t
need to wait
> >  > until something is complete and polished before seeing it.
> >  >
> >  > Perhaps we could have a generic IronRuby.Misc that people
> >  > could create directories  beneath initially, which could then
> >  > be moved to top level status once they''ve matured.
> >  >
> >  > Cheers, Wayne.
> >  > _______________________________________________
> >  > 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
>  _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Ryan Riley
ryan.riley at panesofglass.org
http://www.panesofglass.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/b343ba12/attachment-0001.html>

On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:
> Splitting into different DLLs complicate things for Silverlight.
>
> On the desktop you can have the assembly loading be dynamic with a foo.rb
> wrapper for a library. However, Silverlight (today) requires the DLL would
> have to be downloaded to the client first before loading. In other words,
> the AppManifest.xaml (and the XAP, but that''s optional) would have
to know
> about ALL the IronRuby Library DLLs you "could" want to use. We
automate the
> generation of this file and XAP, so that tool (Chiron) would need to know
> this. While this isn''t a direct problem, it does make the # of
assemblies
> you need to include with your app go from 2 to n. Splitting could
> potentially save download size, but figuring out which DLLs to include is
> hard (see below).
>
> Are there other options for how to get DLLs onto a client machine?
>
> To get this option out of the way, we can''t bake this logic
(download an
> assembly when you require it) into our Silverlight integration, or even
push
> the responsibility on the libraries themselves. Downloading in SL requires
> asynchronous requests, and we can''t pause user code to do this
(aka.
> Continuations). We could technically implement it by hacking on
> XmlHttpRequest directly to get synchronous support, but ugh. If network
> connection gets flakey your browser hangs ... not very pleasant.
>
> Do we introduce a config.rb to Silverlight that lets you define the
> closure of all the assemblies you''ll need? This file gets loaded
first, it
> triggers the downloads the necessary assemblies, and then load the real
> program?
>
> Again, the AppManifest solution will work, but it''s not very
> dynamic-language-esc, and becomes more apparent if we split the libraries
> out. I''m just brainstorming for better solutions to this. Ideas?
>
> ~Jimmy

 Wouldn''t this, then, lend itself toward a solution towards that
proposed by
/M:D? I don''t know multi-file assemblies that well, but it seems the
best
solution in that, iirc, only the .netmodules needed are loaded as they are
called, but they''re already linked by the primary assembly. This might
be
more complicated to maintain and cleanly build; I don''t know. I also
don''t
quite understand the "not dynamic" comment, but again, I''m
not too familiar
with multi-file assemblies.

(Also, apologies for the duplicate in the other thread.)

-R2
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/a6278c56/attachment.html>

Sorry, I see this is being discussed elsewhere. Kindly disregard. :)

-R2
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/ed444ec5/attachment.html>

IronPython has the following scheme for loading Python modules:

1.       IronPython looks for all the PythonModuleAttribute custom attributes
inside any assembly registered with IronPython using
"clr.AddReference(assemblyName)" which is similar to
"require" in Ruby. The assembly-level attributes point to all the
Python modules available inside the assembly. For eg, "[assembly:
PythonModuleAttribute("nt",
typeof(IronPython.Modules.PythonNT))]" indicates that the
"PythonNT" C# type implements the "nt" Python module. A
single assembly can contain multiple Python modules.

2.       On startup, IronPython registers IronPython.Modules.dll automatically.
Hence, all Python modules from the dll become accessible.

3.       Python loads site.py on startup. The site.py that ships with IronPython
looks inside a specific folder and registers all assemblies in that folder. So a
user can drop an assembly in this folder, and all the Python modules in the
assembly will become accessible. I believe Seo uses this to good measure in FePy
to make his own set of Python modules available to users.

4.       Accessible modules are put on a stand-by list. They get activated only
if the user does "import someModule" which is similar to
"require" in Ruby. Until then, the user is not exposed to the fact
that the modules are accessible.

Could a similar scheme work for IronRuby? All the small IronRuby libraries owned
by external committers could live in an assembly like
IronRuby.Libraries.Staging.dll, and this could be placed in some well-known
folder relative to IronRuby.dll. Size should not be much of an issue in
Silverlight as you would expect that the IronRuby runtime and libraries would be
cached on the user''s machine most of the time. If it does become an
issue, we can later break up IronRuby.Libraries.Staging.dll into smaller pieces.
Once the DLR gets more stable, IronRuby.Libraries.Staging.dll can be merged into
IronRuby.Libraries.dll.

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#<http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx>?
Visit http://blogs.msdn.com/ironpython/

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ryan Riley
Sent: Thursday, May 01, 2008 6:49 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Opening up our tree to external committers

On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi <Jimmy.Schementi at
microsoft.com<mailto:Jimmy.Schementi at microsoft.com>> wrote:
Splitting into different DLLs complicate things for Silverlight.

On the desktop you can have the assembly loading be dynamic with a foo.rb
wrapper for a library. However, Silverlight (today) requires the DLL would have
to be downloaded to the client first before loading. In other words, the
AppManifest.xaml (and the XAP, but that''s optional) would have to know
about ALL the IronRuby Library DLLs you "could" want to use. We
automate the generation of this file and XAP, so that tool (Chiron) would need
to know this. While this isn''t a direct problem, it does make the # of
assemblies you need to include with your app go from 2 to n. Splitting could
potentially save download size, but figuring out which DLLs to include is hard
(see below).

Are there other options for how to get DLLs onto a client machine?

To get this option out of the way, we can''t bake this logic (download
an assembly when you require it) into our Silverlight integration, or even push
the responsibility on the libraries themselves. Downloading in SL requires
asynchronous requests, and we can''t pause user code to do this (aka.
Continuations). We could technically implement it by hacking on XmlHttpRequest
directly to get synchronous support, but ugh. If network connection gets flakey
your browser hangs ... not very pleasant.

Do we introduce a config.rb to Silverlight that lets you define the closure of
all the assemblies you''ll need? This file gets loaded first, it
triggers the downloads the necessary assemblies, and then load the real program?

Again, the AppManifest solution will work, but it''s not very
dynamic-language-esc, and becomes more apparent if we split the libraries out.
I''m just brainstorming for better solutions to this. Ideas?

~Jimmy

Wouldn''t this, then, lend itself toward a solution towards that
proposed by /M:D? I don''t know multi-file assemblies that well, but it
seems the best solution in that, iirc, only the .netmodules needed are loaded as
they are called, but they''re already linked by the primary assembly.
This might be more complicated to maintain and cleanly build; I don''t
know. I also don''t quite understand the "not dynamic"
comment, but again, I''m not too familiar with multi-file assemblies.

(Also, apologies for the duplicate in the other thread.)

-R2
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/e61eadb8/attachment.html>