IronRuby community and communications

On Wed, 03 Oct 2007 08:36:45 -0600, William Y.
[email protected] 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!
:smiley:

Any thoughts from the community at large?


/M:D

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

On Wed, 03 Oct 2007 09:26:31 -0600, Mike M. [email protected]
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 P.
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155

On Wed, 03 Oct 2007 10:03:28 -0600, Phil H. [email protected]
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 P.
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 H.

From: [email protected]
[mailto:[email protected]] On Behalf Of Mike M.
Sent: Wednesday, October 03, 2007 8:27 AM
To: [email protected]
Subject: Re: [Ironruby-core] IronRuby community and communications

On 10/3/07, M. David P. [email protected] wrote:

On Wed, 03 Oct 2007 08:36:45 -0600, William Y.
[email protected] 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!
:smiley:

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 P.
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

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 :slight_smile:

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

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

On Fri, 05 Oct 2007 12:54:00 -0600, John L. (DLR) [email protected]
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 P.
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
:slight_smile:

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/!/ self) {
return self.Count == 0 ? null : self[self.Count - 1];
}

[RubyMethodAttribute(“last”, RubyMethodAttributes.PublicInstance)]
public static object Last(List/!/ 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/!/
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