Ironruby core - Oct 2007 - IronRuby community and communications

Wow.

I was enjoying my day off with my family and my brother who was in town visiting
when I discovered this thread on my phone. It was fun reading things go by, but
there was no way that I was going to try and respond via T9. But now that
I''m back in the office let''s begin anew to address some of the
issues that were raised yesterday:

Charlie Nutter:
>> Are there development discussions happening on private lists,
>> say inside Microsoft within the IronRuby or DLR team? If so,
>> you should really think about moving as much of those discussions
>> as possible into the open.
When I first joined the company back in January, we had a regular set of F2F
meetings called the DLR Design Discussions. Culturally at Microsoft, we do tend
to do a lot of technical discussions F2F since, well, we all work within about
50 feet or so of each other :) Almost all complex code reviews and technical
design are done in front of a computer/whiteboard in someone''s office.
Given a choice, like most people, we will take the path of least resistance.

That said, I do think that there are a number of things that we can do to
improve how we communicate with y''all. So let''s address some
of the issues raised on the thread and then I''ll summarize with some
proposals at the end.

Charlie Nutter:
>> there doesn''t appear to be any discussion about the runtime
and
>> compiler subsystems.
Guilty as charged. Partly because of cultural things above, and partly due to
lack of bandwidth in driving these discussions in the open. I did have the crazy
idea of videotaping our design meetings, but I''m not convinced
that''s the best way of getting information out to folks - it''s
really unfiltered and if you lack context they''re really rather
useless. But wait until the end of this mail to see some ideas.

Curt Hagenlocher:
>> I think some of what we''re seeing is a result of
IronRuby''s dependence
>> on the DLR -- which appears to be far from finalized, and which is not
>> going to be driven by the community at all.
This is true in the sense that the *implementation* of the DLR will not be
driven by the community. However, the *design* of the DLR is absolutely driven
by community feedback. The IronRuby compiler is technically
''community'' insofar as the DLR itself is concerned, and
there''s been lots of design changes in DLR due to IronRuby.

Jb Evain:
>> I''m a little frustrated as well by this situation, and
I''d like to
>> see more technical discussions *between MS engineers* on this list.
Charlie Nutter:
>> I heard five developers, but perhaps that was a couple testers/QA
>> as well.
I''m pretty sure that I talked about our org chart before, but here it
is again:

Tomas Matousek: compiler dev
Haibo Luo: compiler test
John Lam: program manager

John Messerly from our larger team contributes code as well, but only between
stints in his ''real job''.

Most of our discussions happen on the whiteboard in 41/5612. I agree that we
need to fix this, see end of mail.


Some ideas:
==========
1. We hold a bi-weekly (soon to become weekly I think due to the # of times that
I cancel it) meeting for the IronRuby team. We can make this available via a
toll-free conference call # if folks want to dial into it. We can''t do
Skype etc. from inside of corpnet.

2. We can put together a weekly summary of changes to IronRuby/DLR so that folks
can see the changes. Right now due to the way we sync with svn, we''re
losing some information from checkin mails.

3. In the same weekly summary, we can post about what we''re planning on
working on next and folks outside can chime in with status reports on what
they''re working on and how it''s going.

I''d love to hear some more ideas about how we can improve our
communications / transparency.

Thanks,
-John

Have you guys seen the way how mono report their compatibility? I think this
is one thing I really missed. I only know some basic ruby syntax works, but
then a lot of the methods are not implemented. If you want everyone know
whats going on for a language port, perhaps the best bet is show us a list
of all the ruby methods and then the compatibility status. I think with some
reflection implementation this thing could be largely automated. For example
I keep trying public_instance_methods on class and hope it would bring me
the list of implemented methods, with no luck so far :(

I, as a user expecting IronRuby to be used by my projects, doesn''t
really
care a lot about how DLR are designed. As long as IronRuby is going to be as
close as 100% compatible as possible in shortest time, with reasonable to
believe verification result, I don''t care. I guess thats most
people''s
concerns too, so if you talk about communications between expecting users
and IronRuby team I think that feature list thing is the most concerned.

On 10/3/07, John Lam (DLR) <jflam at microsoft.com>
wrote:
>
> Wow.
>
> I was enjoying my day off with my family and my brother who was in town
> visiting when I discovered this thread on my phone. It was fun reading
> things go by, but there was no way that I was going to try and respond via
> T9. But now that I''m back in the office let''s begin anew
to address some of
> the issues that were raised yesterday:
>
> Charlie Nutter:
> >> Are there development discussions happening on private lists,
> >> say inside Microsoft within the IronRuby or DLR team? If so,
> >> you should really think about moving as much of those discussions
> >> as possible into the open.
>
> When I first joined the company back in January, we had a regular set of
> F2F meetings called the DLR Design Discussions. Culturally at Microsoft, we
> do tend to do a lot of technical discussions F2F since, well, we all work
> within about 50 feet or so of each other :) Almost all complex code reviews
> and technical design are done in front of a computer/whiteboard in
someone''s
> office. Given a choice, like most people, we will take the path of least
> resistance.
>
> That said, I do think that there are a number of things that we can do to
> improve how we communicate with y''all. So let''s address
some of the issues
> raised on the thread and then I''ll summarize with some proposals
at the end.
>
> Charlie Nutter:
> >> there doesn''t appear to be any discussion about the
runtime and
> >> compiler subsystems.
>
> Guilty as charged. Partly because of cultural things above, and partly due
> to lack of bandwidth in driving these discussions in the open. I did have
> the crazy idea of videotaping our design meetings, but I''m not
convinced
> that''s the best way of getting information out to folks -
it''s really
> unfiltered and if you lack context they''re really rather useless.
But wait
> until the end of this mail to see some ideas.
>
> Curt Hagenlocher:
> >> I think some of what we''re seeing is a result of
IronRuby''s dependence
> >> on the DLR -- which appears to be far from finalized, and which is
not
> >> going to be driven by the community at all.
>
> This is true in the sense that the *implementation* of the DLR will not be
> driven by the community. However, the *design* of the DLR is absolutely
> driven by community feedback. The IronRuby compiler is technically
> ''community'' insofar as the DLR itself is concerned, and
there''s been lots of
> design changes in DLR due to IronRuby.
>
> Jb Evain:
> >> I''m a little frustrated as well by this situation, and
I''d like to
> >> see more technical discussions *between MS engineers* on this
list.
>
> Charlie Nutter:
> >> I heard five developers, but perhaps that was a couple testers/QA
> >> as well.
>
> I''m pretty sure that I talked about our org chart before, but here
it is
> again:
>
> Tomas Matousek: compiler dev
> Haibo Luo: compiler test
> John Lam: program manager
>
> John Messerly from our larger team contributes code as well, but only
> between stints in his ''real job''.
>
> Most of our discussions happen on the whiteboard in 41/5612. I agree that
> we need to fix this, see end of mail.
>
>
> Some ideas:
> ==========>
> 1. We hold a bi-weekly (soon to become weekly I think due to the # of
> times that I cancel it) meeting for the IronRuby team. We can make this
> available via a toll-free conference call # if folks want to dial into it.
> We can''t do Skype etc. from inside of corpnet.
>
> 2. We can put together a weekly summary of changes to IronRuby/DLR so that
> folks can see the changes. Right now due to the way we sync with svn,
we''re
> losing some information from checkin mails.
>
> 3. In the same weekly summary, we can post about what we''re
planning on
> working on next and folks outside can chime in with status reports on what
> they''re working on and how it''s going.
>
> I''d love to hear some more ideas about how we can improve our
> communications / transparency.
>
> 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/20071003/a2caffcb/attachment-0001.html

On 10/2/07, John Lam (DLR) <jflam at microsoft.com>
wrote:
>
> Wow.
>
> I was enjoying my day off with my family and my brother who was in town
> visiting when I discovered this thread on my phone. It was fun reading
> things go by, but there was no way that I was going to try and respond via
> T9. But now that I''m back in the office let''s begin anew
to address some of
> the issues that were raised yesterday:
>
> Charlie Nutter:
> >> Are there development discussions happening on private lists,
> >> say inside Microsoft within the IronRuby or DLR team? If so,
> >> you should really think about moving as much of those discussions
> >> as possible into the open.
>
> When I first joined the company back in January, we had a regular set of
> F2F meetings called the DLR Design Discussions. Culturally at Microsoft, we
> do tend to do a lot of technical discussions F2F since, well, we all work
> within about 50 feet or so of each other :) Almost all complex code reviews
> and technical design are done in front of a computer/whiteboard in
someone''s
> office. Given a choice, like most people, we will take the path of least
> resistance.
>
> That said, I do think that there are a number of things that we can do to
> improve how we communicate with y''all. So let''s address
some of the issues
> raised on the thread and then I''ll summarize with some proposals
at the end.
>
> Charlie Nutter:
> >> there doesn''t appear to be any discussion about the
runtime and
> >> compiler subsystems.
>
> Guilty as charged. Partly because of cultural things above, and partly due
> to lack of bandwidth in driving these discussions in the open. I did have
> the crazy idea of videotaping our design meetings, but I''m not
convinced
> that''s the best way of getting information out to folks -
it''s really
> unfiltered and if you lack context they''re really rather useless.
But wait
> until the end of this mail to see some ideas.
>
> Curt Hagenlocher:
> >> I think some of what we''re seeing is a result of
IronRuby''s dependence
> >> on the DLR -- which appears to be far from finalized, and which is
not
> >> going to be driven by the community at all.
>
> This is true in the sense that the *implementation* of the DLR will not be
> driven by the community. However, the *design* of the DLR is absolutely
> driven by community feedback. The IronRuby compiler is technically
> ''community'' insofar as the DLR itself is concerned, and
there''s been lots of
> design changes in DLR due to IronRuby.
>
> Jb Evain:
> >> I''m a little frustrated as well by this situation, and
I''d like to
> >> see more technical discussions *between MS engineers* on this
list.
>
> Charlie Nutter:
> >> I heard five developers, but perhaps that was a couple testers/QA
> >> as well.
>
> I''m pretty sure that I talked about our org chart before, but here
it is
> again:
>
> Tomas Matousek: compiler dev
> Haibo Luo: compiler test
> John Lam: program manager
>
> John Messerly from our larger team contributes code as well, but only
> between stints in his ''real job''.
>
> Most of our discussions happen on the whiteboard in 41/5612. I agree that
> we need to fix this, see end of mail.
>
>
> Some ideas:
> ==========>
> 1. We hold a bi-weekly (soon to become weekly I think due to the # of
> times that I cancel it) meeting for the IronRuby team. We can make this
> available via a toll-free conference call # if folks want to dial into it.
> We can''t do Skype etc. from inside of corpnet.

I think this is a great idea.  I''d certainly block my schedule to call
in
and listen.  If this works then perhaps the community could help with note
taking and information dissemination.

2. We can put together a weekly summary of changes to IronRuby/DLR so
that
> folks can see the changes. Right now due to the way we sync with svn,
we''re
> losing some information from checkin mails.

I do think this would be helpful.

3. In the same weekly summary, we can post about what we''re planning
on
> working on next and folks outside can chime in with status reports on what
> they''re working on and how it''s going.
>
> I''d love to hear some more ideas about how we can improve our
> communications / transparency.

I agree with William Yeung''s response about the desire for a status
mechanism at the module/class/method level.  Again, maybe this is something
that folks outside of Microsoft can maintain once we know the plan.  I think
this would really help us know when features are scheduled to be
implemented, and where we can contribute.

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/20071002/f2f5b033/attachment.html

Getting access to original commit emails would be a very useful way of
seeing what changes are being made. Is it possible to put that on a mailing
list, if it isn''t already?

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (DLR)
Sent: Tuesday, October 02, 2007 9:36 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby community and communications

Wow.

I was enjoying my day off with my family and my brother who was in town
visiting when I discovered this thread on my phone. It was fun reading
things go by, but there was no way that I was going to try and respond via
T9. But now that I''m back in the office let''s begin anew to
address some of
the issues that were raised yesterday:

Charlie Nutter:
>> Are there development discussions happening on private lists,
>> say inside Microsoft within the IronRuby or DLR team? If so,
>> you should really think about moving as much of those discussions
>> as possible into the open.
When I first joined the company back in January, we had a regular set of F2F
meetings called the DLR Design Discussions. Culturally at Microsoft, we do
tend to do a lot of technical discussions F2F since, well, we all work
within about 50 feet or so of each other :) Almost all complex code reviews
and technical design are done in front of a computer/whiteboard in
someone''s
office. Given a choice, like most people, we will take the path of least
resistance.

That said, I do think that there are a number of things that we can do to
improve how we communicate with y''all. So let''s address some
of the issues
raised on the thread and then I''ll summarize with some proposals at the
end.

Charlie Nutter:
>> there doesn''t appear to be any discussion about the runtime
and
>> compiler subsystems.
Guilty as charged. Partly because of cultural things above, and partly due
to lack of bandwidth in driving these discussions in the open. I did have
the crazy idea of videotaping our design meetings, but I''m not
convinced
that''s the best way of getting information out to folks - it''s
really
unfiltered and if you lack context they''re really rather useless. But
wait
until the end of this mail to see some ideas.

Curt Hagenlocher:
>> I think some of what we''re seeing is a result of
IronRuby''s dependence
>> on the DLR -- which appears to be far from finalized, and which is not
>> going to be driven by the community at all.
This is true in the sense that the *implementation* of the DLR will not be
driven by the community. However, the *design* of the DLR is absolutely
driven by community feedback. The IronRuby compiler is technically
''community'' insofar as the DLR itself is concerned, and
there''s been lots of
design changes in DLR due to IronRuby.

Jb Evain:
>> I''m a little frustrated as well by this situation, and
I''d like to
>> see more technical discussions *between MS engineers* on this list.
Charlie Nutter:
>> I heard five developers, but perhaps that was a couple testers/QA
>> as well.
I''m pretty sure that I talked about our org chart before, but here it
is
again:

Tomas Matousek: compiler dev
Haibo Luo: compiler test
John Lam: program manager

John Messerly from our larger team contributes code as well, but only
between stints in his ''real job''.

Most of our discussions happen on the whiteboard in 41/5612. I agree that we
need to fix this, see end of mail.


Some ideas:
==========
1. We hold a bi-weekly (soon to become weekly I think due to the # of times
that I cancel it) meeting for the IronRuby team. We can make this available
via a toll-free conference call # if folks want to dial into it. We
can''t do
Skype etc. from inside of corpnet.

2. We can put together a weekly summary of changes to IronRuby/DLR so that
folks can see the changes. Right now due to the way we sync with svn,
we''re
losing some information from checkin mails.

3. In the same weekly summary, we can post about what we''re planning on
working on next and folks outside can chime in with status reports on what
they''re working on and how it''s going.

I''d love to hear some more ideas about how we can improve our
communications
/ transparency.

Thanks,
-John

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

> Behalf Of William Yeung:
>
> Have you guys seen the way how mono report their compatibility? I
> think this is one thing I really missed.
I really like the way MOMA works. I agree that we can automate much of this
stuff. Essentially we just have to run a script over the Ruby libraries and
implement some methods on Class and diff the output.

In fact we already have an internal tool that sort of does this and generates
some of the comments that you''ll see in sources under Builtins/

I''ll look at what it would take to automate generating HTML reports out
of this so that folks can quickly get a feel for what is and isn''t
implemented.

Thanks,
-John

Hi!

First of all, Mr. Lam, your attitude is really refreshing. Such
upfront honest feedback is always good. Thank you! =)

On 10/2/07, Mike Moore <blowmage at gmail.com>
wrote:
> If this works then perhaps the community could help with note
> taking and information dissemination.
This would be wonderful, specially for foreigners like me. I could
lend a hand in transcriptions.

On Tue, 02 Oct 2007 10:35:58 -0600, John Lam (DLR) <jflam at
microsoft.com>
wrote:
> I''d love to hear some more ideas about how we can improve our  
> communications / transparency.
Sounds like the perfect opportunity to dogfood from the Masters Bowl ;-)

http://office.microsoft.com/en-us/livemeeting/

http://office.microsoft.com/en-us/groove/

BTW... While I have to admit that I am not surprised to see your response,  
it''s *FANTASTIC* to see your level of activism on this matter, John!   
Obviously I can''t claim that anything I said or did helped spur this  
response, so I won''t**.  But I''m certainly happy that the end
result seems
to be exactly what it needed to be.

** CREDIT: Charlie "Is *NOT* A Troll" Nutter and Jb "I''d
Prefer
IronAspect, But IronRuby Will Do For Now" Evain

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

On Tue, 02 Oct 2007 10:42:32 -0600, William Yeung  
<william.yeung.hk at gmail.com> wrote:
> Have you guys seen the way how mono report their compatibility?
The thing I dislike about this particular implementation[1] is that it  
requires you to drill-down through the class heirarchy manually.   
Personally I prefer the JAPI-style overview[2], but none-the-less agree  
this would be a *FANTASTIC* tool to have available.

Pat (Eyler, Cc''d): Do you know if something like this exists for
comparing
the various Ruby implementations against cRuby (is that the proper  
reference to Matz''s Ruby runtime+library?)

[1] http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/
[2] http://www.frijters.net/IKVM-0.36-vs-JDK-1.6.html

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

2007/10/3, M. David Peterson <m.david at
xmlhacker.com>:
> cRuby (is that the proper reference to Matz''s Ruby
runtime+library?)
It is often referred as MRI (Matz''s Ruby Interpreter/Implementation),
although CRuby is also used.

-- 
Seo Sanghyeon

On Wed, 03 Oct 2007 03:44:53 -0600, Sanghyeon Seo <sanxiyn at gmail.com>  
wrote:
> It is often referred as MRI (Matz''s Ruby
Interpreter/Implementation),
> although CRuby is also used.
Ahh, got it.  Thanks, Seo! :D

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

M. David Peterson wrote:
> On Tue, 02 Oct 2007 10:42:32 -0600, William Yeung  
> <william.yeung.hk at gmail.com> wrote:
> 
>> Have you guys seen the way how mono report their compatibility?
> 
> The thing I dislike about this particular implementation[1] is that it  
> requires you to drill-down through the class heirarchy manually.   
> Personally I prefer the JAPI-style overview[2], but none-the-less agree  
> this would be a *FANTASTIC* tool to have available.
> 
> Pat (Eyler, Cc''d): Do you know if something like this exists for
comparing
> the various Ruby implementations against cRuby (is that the proper  
> reference to Matz''s Ruby runtime+library?)
I''m not Pat, but I know we''ve never found anything. There have
been
various scripts bandied about to compare method lists, but that''s a 
fairly superficial measurement. We would *love* to have a more 
definitive tool that can check completion level.

- Charlie

On Wed, 03 Oct 2007 04:00:08 -0600, Charles Oliver Nutter  
<charles.nutter at sun.com> wrote:
> We would *love* to have a more
> definitive tool that can check completion level.
So where do we begin?

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

On Wed, 03 Oct 2007 04:31:22 -0600, M. David Peterson  
<m.david at xmlhacker.com> wrote:
> So where do we begin?
BTW... If we could get a similar XML output to  
http://mdavid.googlecode.com/svn/trunk/IronRuby/IronRuby.xml that  
represents the MRI/CRuby language runtime it would at very least give us a  
simple foundation to build and extend from.  Of course this particular  
format does nothing to specify whether the class/method has actually been  
implemented or if it''s simply a skeleton framework that throws  
class/method not implemented exceptions, though there are enough tools out  
there that are able to introspect the inner workings of an API that leads  
me to believe that there''s got to be an off-the-shelf tool out there
that
can drill down deeper and report its findings.

Anyone know of just such a tool?

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

M. David Peterson wrote:
> On Wed, 03 Oct 2007 04:00:08 -0600, Charles Oliver Nutter  
> <charles.nutter at sun.com> wrote:
> 
>> We would *love* to have a more
>> definitive tool that can check completion level.
> 
> So where do we begin?
Great question!

- Charlie

On Wed, 03 Oct 2007 05:02:36 -0600, Charles Oliver Nutter  
<charles.nutter at sun.com> wrote:
> Great question!
Thanks! :D

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

pat eyler wrote:
> ---------- Forwarded message ----------
> From: pat eyler <pat.eyler at gmail.com>
> Date: Oct 3, 2007 6:46 AM
> Subject: Re: [Ironruby-core] IronRuby community and communications
> To: "M. David Peterson" <m.david at xmlhacker.com>
> Cc: ironruby-core at rubyforge.org
> 
> 
> On 10/3/07, M. David Peterson <m.david at xmlhacker.com> wrote:
>> The thing I dislike about this particular implementation[1] is that it
>> requires you to drill-down through the class heirarchy manually.
>> Personally I prefer the JAPI-style overview[2], but none-the-less agree
>> this would be a *FANTASTIC* tool to have available.
>>
>> Pat (Eyler, Cc''d): Do you know if something like this exists
for comparing
>> the various Ruby implementations against cRuby (is that the proper
>> reference to Matz''s Ruby runtime+library?)
>>
> 
> This is kind of a work in progress, but the ruby spec project is the
> basis for this kind of testing/reporting.  I''ll pass the idea
along to
> Charlie and Evan.  Is anyone from the IronRuby core coming to
> RubyConf this year?  I think this is one of the ideas that really
> ought to be discussed during the implementers summit.
Ok ok, I''ll weigh in now.

RubySpec is a human-readable spec wiki I put up for community members to 
collaboratively build a Ruby specification. It''s made fairly good
progress.

http://www.headius.com/rubyspec

Rubinius contains a number of rspec specs that form the testing half of 
the equation. The hope is that this suite of specs will continue to grow 
to provide a complete specification test suite for Ruby implementations. 
Evan can talk more about that side of things.

The rspec specs will probably be more useful as a measure of 
completeness, but they do require that an implementation can at least 
successfully run them (albeit not perfectly) so that errors and missing 
features can be gathered. I''m not sure if IronRuby is to that point yet
or not. We have been running some of Rubinius''s specs in JRuby for 
several months, along with just about every test suite we can get our 
hands on.

I''d love to see us cooperate here.

- Charlie

I dont think dogfood groove is a good idea unless a lot of users would be
entitled for such tool. Otherwise people see this is a way to sell more MS
products than helping the community. Don''t forget you are facing a lot
of
geeks who expect everything could be done in source code :)

On 10/3/07, M. David Peterson <m.david at xmlhacker.com>
wrote:
>
> On Tue, 02 Oct 2007 10:35:58 -0600, John Lam (DLR) <jflam at
microsoft.com>
> wrote:
>
> > I''d love to hear some more ideas about how we can improve our
> > communications / transparency.
>
> Sounds like the perfect opportunity to dogfood from the Masters Bowl ;-)
>
> http://office.microsoft.com/en-us/livemeeting/
>
> http://office.microsoft.com/en-us/groove/
>
> BTW... While I have to admit that I am not surprised to see your response,
> it''s *FANTASTIC* to see your level of activism on this matter,
John!
> Obviously I can''t claim that anything I said or did helped spur
this
> response, so I won''t**.  But I''m certainly happy that the
end result seems
> to be exactly what it needed to be.
>
> ** CREDIT: Charlie "Is *NOT* A Troll" Nutter and Jb
"I''d Prefer
> IronAspect, But IronRuby Will Do For Now" Evain
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155
> _______________________________________________
> 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/20071003/927fde6c/attachment-0001.html

On Wed, 03 Oct 2007 07:30:40 -0600, William Yeung  
<william.yeung.hk at gmail.com> wrote:
> I dont think dogfood groove is a good idea unless a lot of users would  
> be entitled for such tool.
Oh, I agree that there would need to be some sort of license that could be  
allocated for use by IronRuby community members at no cost.  Maybe signing  
a contributor agreement could be used as a definitive market as to those  
who are serious about being involved and as such would benefit from a  
Groove license for the purpose of community collaboration?

Not sure, but it seems like if nothing else it could be an interesting  
use-case for the Groove team.  And a good use-case can be worth it''s  
weight in gold, so if nothing else there would at least be that.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

On Wed, 03 Oct 2007 07:45:28 -0600, M. David Peterson  
<m.david at xmlhacker.com> wrote:
> market
s/market/marker

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

If you can make this happen like how ReSharper did on the CastleProject
community, that''s really a good idea. (Obviously I am from Castle
project
community as you can see :P I am not the contributors though, so I
don''t
have ReSharper license. However its all because of their praise to the tool
makes me did the purchase and never regret afterwards!)

On 10/3/07, M. David Peterson <m.david at xmlhacker.com>
wrote:
>
> On Wed, 03 Oct 2007 07:30:40 -0600, William Yeung
> <william.yeung.hk at gmail.com> wrote:
>
> > I dont think dogfood groove is a good idea unless a lot of users would
> > be entitled for such tool.
>
> Oh, I agree that there would need to be some sort of license that could be
> allocated for use by IronRuby community members at no cost.  Maybe signing
> a contributor agreement could be used as a definitive market as to those
> who are serious about being involved and as such would benefit from a
> Groove license for the purpose of community collaboration?
>
> Not sure, but it seems like if nothing else it could be an interesting
> use-case for the Groove team.  And a good use-case can be worth
it''s
> weight in gold, so if nothing else there would at least be that.
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155
> _______________________________________________
> 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/20071003/a62fc547/attachment.html

On Wed, 03 Oct 2007 08:36:45 -0600, William Yeung  
<william.yeung.hk at gmail.com> wrote:
> If you can make this happen like how ReSharper did on the CastleProject  
> community, that''s really a good idea.
There''s nothing I can do other than speak up and state my case as to
why I
might think one thing or another would be good/bad/indifferent.  As  
Charlie has proven, sometimes the best way to get something accomplished  
is to find ways to get people vocal about a particular topic of interest.

To be honest I''m not 100% that Groove is the perfect fit in this  
particular use-case.  But I think it might be.  Would be fun to find out!  
:D

Any thoughts from the community at large?

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

On 10/3/07, M. David Peterson <m.david at xmlhacker.com>
wrote:
>
> On Wed, 03 Oct 2007 08:36:45 -0600, William Yeung
> <william.yeung.hk at gmail.com> wrote:
>
> > If you can make this happen like how ReSharper did on the
CastleProject
> > community, that''s really a good idea.
>
> There''s nothing I can do other than speak up and state my case as
to why I
> might think one thing or another would be good/bad/indifferent.  As
> Charlie has proven, sometimes the best way to get something accomplished
> is to find ways to get people vocal about a particular topic of interest.
>
> To be honest I''m not 100% that Groove is the perfect fit in this
> particular use-case.  But I think it might be.  Would be fun to find out!
> :D
>
> Any thoughts from the community at large?

I''m not opposed to Groove.  It does limit contributors to those on
Windows,
or have access to running Windows.  I doubt that is much of a restriction
though, as testing IronRuby on *only* Mono seems rather risky.  If Microsoft
could pony up Groove licenses for all contributors I''d certainly try to
make
it work.

But, I''m also not opposed to running development using Trac, or some
other
well known PM tool, either.  The tools aren''t as important to me as
having a
bit more structure.

--
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155
> _______________________________________________
> 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/20071003/6b879d3e/attachment.html

On Wed, 03 Oct 2007 09:26:31 -0600, Mike Moore <blowmage at gmail.com>
wrote:
> But, I''m also not opposed to running development using Trac, or
some
> other well known PM tool, either.  The tools aren''t as important
to me
> as having a bit more structure.
+1

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

Forgive me if this seems like a na?ve question, but since the project is
hosted on RubyForge, why not use its facilities to run the project. Is it
not up to snuff?

 

Phil Haack

http://haacked.com/

 

From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Mike Moore
Sent: Wednesday, October 03, 2007 8:27 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby community and communications

 

On 10/3/07, M. David Peterson <m.david at xmlhacker.com> wrote:

On Wed, 03 Oct 2007 08:36:45 -0600, William Yeung
<william.yeung.hk at gmail.com> wrote:
> If you can make this happen like how ReSharper did on the CastleProject 
> community, that''s really a good idea.
There''s nothing I can do other than speak up and state my case as to
why I
might think one thing or another would be good/bad/indifferent.  As
Charlie has proven, sometimes the best way to get something accomplished 
is to find ways to get people vocal about a particular topic of interest.

To be honest I''m not 100% that Groove is the perfect fit in this
particular use-case.  But I think it might be.  Would be fun to find out! 
:D

Any thoughts from the community at large?


I''m not opposed to Groove.  It does limit contributors to those on
Windows,
or have access to running Windows.  I doubt that is much of a restriction
though, as testing IronRuby on *only* Mono seems rather risky.  If Microsoft
could pony up Groove licenses for all contributors I''d certainly try to
make
it work. 

But, I''m also not opposed to running development using Trac, or some
other
well known PM tool, either.  The tools aren''t as important to me as
having a
bit more structure.

 

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
_______________________________________________
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/20071003/396b16da/attachment-0001.html

On Wed, 03 Oct 2007 10:03:28 -0600, Phil Haack <haacked at gmail.com>
wrote:
> Forgive me if this seems like a na?ve question, but since the project is  
> hosted on RubyForge, why not use its facilities to run the project. Is  
> it not up to snuff?
This conversation stems mostly from the "How can external folks get  
involved with participating in meetings and collaborating on design  
docs?".  RubyForge is fine for the standard bug tracking, doc  
developement, etc, but as far as I know there are no tools in place to  
allow for any type of decentralized communication and collaboration type  
features.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

Ah, thanks for the clarification! 

Well for any artifacts such as design docs, I''d love to see them in the
SVN repository since they should be versioned anyways.

As for actual real-time meetings, I''ve always liked Skype, but
there''s a limit in the # of users in a conf call. Live Meeting ought to
work for that, though it''s a pain to set up properly.

Anyone play around with BaseCamp for this sort of thing?

Phil

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of M. David Peterson
Sent: Wednesday, October 03, 2007 9:29 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby community and communications

On Wed, 03 Oct 2007 10:03:28 -0600, Phil Haack <haacked at gmail.com>
wrote:
> Forgive me if this seems like a na?ve question, but since the project is  
> hosted on RubyForge, why not use its facilities to run the project. Is  
> it not up to snuff?
This conversation stems mostly from the "How can external folks get  
involved with participating in meetings and collaborating on design  
docs?".  RubyForge is fine for the standard bug tracking, doc  
developement, etc, but as far as I know there are no tools in place to  
allow for any type of decentralized communication and collaboration type  
features.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Basecamp does not change your experience a lot comparing to rubyforge. I
think Groove would give you better ability in terms of collaborative
documentation exchange. I know there is one more product created by the big
search engine guy for collaborative documentation, but calling this out
might seriously making our MS friends unhappy :)

On 10/4/07, Phil Haack <haacked at gmail.com>
wrote:
>
> Ah, thanks for the clarification!
>
> Well for any artifacts such as design docs, I''d love to see them
in the
> SVN repository since they should be versioned anyways.
>
> As for actual real-time meetings, I''ve always liked Skype, but
there''s a
> limit in the # of users in a conf call. Live Meeting ought to work for
that,
> though it''s a pain to set up properly.
>
> Anyone play around with BaseCamp for this sort of thing?
>
> Phil
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] On Behalf Of M. David Peterson
> Sent: Wednesday, October 03, 2007 9:29 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby community and communications
>
> On Wed, 03 Oct 2007 10:03:28 -0600, Phil Haack <haacked at gmail.com>
wrote:
>
> > Forgive me if this seems like a na?ve question, but since the project
is
> > hosted on RubyForge, why not use its facilities to run the project. Is
> > it not up to snuff?
>
> This conversation stems mostly from the "How can external folks get
> involved with participating in meetings and collaborating on design
> docs?".  RubyForge is fine for the standard bug tracking, doc
> developement, etc, but as far as I know there are no tools in place to
> allow for any type of decentralized communication and collaboration type
> features.
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155
> _______________________________________________
> 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/20071004/873a6115/attachment.html

> The rspec specs will probably be more useful as a measure of
> completeness, but they do require that an implementation can at least
> successfully run them (albeit not perfectly) so that errors and missing
> features can be gathered. I''m not sure if IronRuby is to that
point yet
> or not. We have been running some of Rubinius''s specs in JRuby for
> several months, along with just about every test suite we can get our
> hands on.
Early on when I was actively working on libraries I was porting the Rubinius
specs to work on my stripped down version of mini-spec. It''s been a
couple of months since I visited that code, and we have a lot more core language
features working now. It''s on my list of things to do next week to see
what the gap looks like to run mini-spec natively on IronRuby.

Thanks,
-John

Rebooting this thread.

I''m not convinced that folks really want to use Groove for this kind of
collaboration. While I think that Ray''s a great guy for the company,
anecdotal evidence I hear about Groove is that it''s way too heavyweight
to work effectively unless you have some kind of Groove guru who knows how to
keep the thing running.

Let''s just stick to simpler collaboration tools for the time being ...

Thanks,
-John

> What are the chances of the Ruby.NET folks being able to
> see/use/help with that work?
Not sure what you mean here ... the Rubinius specs are available from their svn
tree, along with mini-spec, which is their driver. I wrote my own simple test
driver that is available in our test tree. The license lets you use that code
however you wish ... :)

I had to modify some of the specs since they were using language features that
we didn''t have working yet at the time (like instance variables :). I
suspect we''re likely to be in a much better position to run the native
specs today, but I haven''t looked yet.

-John

One thought that just crossed my mind is this:

We could write a code generator that generates the appropriate C# stubs for our
built-ins. The generator would generate a default stub based on the arity of the
original Ruby method (our real implementations rely on our binder to locate the
correct strongly typed method). That method would be marked with something like
a NotImplementedAttribute, and throw a NotImplementedException by default.

This way we could run a tool over the library assembly to report progress (or an
estimate of progress). We could also introduce a NotCompletedAttribute to
indicate methods that are a work-in-progress.

Thoughts?
-John

On Fri, 05 Oct 2007 12:54:00 -0600, John Lam (DLR) <jflam at
microsoft.com>
wrote:
> Thoughts?
I think that''s a great idea!  If it would be helpful, I would be happy
to
write the code generation tool.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

Sounds like a good idea to me. I''d like to suggest my codebuilder gem
for
code generation. It''s based on John''s previous RubyCLR, and
takes
inspiration from the xmlbuilder in Rails,  for building .NET classes. For
example, running the little script below:

require ''rubygems''
require ''codebuilder''

@not_implemented = { "RubyString" => ["public_methods"],
                     "RubyInteger" => ["ancestors"]}

result = CodeDOM::Builder.new.build do |builder|
  builder.namespace "IronRuby" do
    @not_implemented.each do |klass, methods|
      builder.partial_klass klass do
        methods.each do |meth|
          builder.method meth do # Array of parameters for the method
            builder.csharp "throw new NotImplementedException();"
          end
        end
      end
    end
  end
end

puts(result.render :csharp)

Gives you C# code like this:

namespace IronRuby {
    using System;
    using System.Data;
    using System.Windows.Forms;


    public partial class RubyString {

        public virtual void public_methods() {
throw new NotImplementedException();
        }
    }

    public partial class RubyInteger {

        public virtual void ancestors() {
throw new NotImplementedException();
        }
    }
}

The tool is based on the CodeDOM framework in .NET. The script above builds
a representation of the classes, methods, properties etc. that are defined
and then ''renders'' them to a source language (in this case,
C#).

It''s not able to do attributes on methods but I bet I could add that
fairly
easily. It''s also not seen a lot of use (I use for an internal project
at
work but otherwise I''m not sure if anyone else ever has) but
I''d be glad to
provide whatever support would be needed.

I just uploaded my latest (5.0.10), which probably won''t be available
via
gem for a few hours, but the project itself is hosted at
http://rubyforge.org/projects/codedombuilder.

Justin

p.s. Just to re-iterate, this tool is based on C-Ruby and uses the rubyclr
project. I fully intend to port it when IronRuby becomes capable enough :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20071005/6b145fb4/attachment.html

After talking it over with Tomas and John over lunch, we figured that it would
be best if all we did was introduce a NotCompletedAttribute rather than create a
code generator. The challenge is in deciding what the correct signatures for the
methods should be, with an eye toward not confusing casual readers of the code.

For example, consider Array#last:

[RubyMethodAttribute("last", RubyMethodAttributes.PublicInstance)]
public static object Last(List<object>/*!*/ self) {
    return self.Count == 0 ? null : self[self.Count - 1];
}

[RubyMethodAttribute("last", RubyMethodAttributes.PublicInstance)]
public static object Last(List<object>/*!*/ self, int count) {
    if (count < 0)
        throw RubyExceptions.CreateArgumentError("negative array size (or
size too big)");

    count = count > self.Count ? self.Count : count;
    return self.GetRange(self.Count - count, count);
}

[RubyMethodAttribute("last", RubyMethodAttributes.PublicInstance)]
public static object Last(CodeContext/*!*/ context, List<object>/*!*/
self, object count) {
    return Last(self, Protocols.CastToFixnum(context, count));
}

Note that there are multiple overloads of this method, and the variation in the
argument types.

We can easily tell if a method is not implemented since the binder will not find
it. We can reflect over the target method at runtime to look for the
NotCompleted attribute, and issue a warning if you try to call a method that
isn''t complete as well.

-John