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
On Tue, Apr 29, 2008 at 9:12 AM, John L. (IRONRUBY)
[email protected] wrote:
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 L.
[Polymath Prokrammer]
http://blog.prokrams.com
Antonio C.:
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 L.:
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 L. (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-----
On Tue, 29 Apr 2008 08:06:57 -0600, John L. (IRONRUBY)
[email protected] 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 P.
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [email protected] | [email protected]
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
M. David Peterson
M. David P.:
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
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
Peter Bacon D.:
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 L.
ironi: Peter Bacon D.
yaml: John M.
There may be others - thoughts?
Thanks,
-John
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 M.
[email protected] wrote:
Cc: Qing Ye
add in the smaller patches to the core that are not getting people
…There may be others - thoughts?
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
–
Michael L.
[Polymath Prokrammer]
http://blog.prokrams.com
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.
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.
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
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 K. [email protected]
wrote:
[mailto:[email protected]] On Behalf Of
out how to do loading of Ruby libraries contained in an
committers
to be created.
be moved to top level status once they’ve matured.
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
–
Michael L.
[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 M. <
On Wed, 30 Apr 2008 21:14:23 -0600, Curt H.
[email protected] 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 P.
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [email protected] | [email protected]
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
M. David Peterson
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: [email protected]
[mailto:[email protected]] On Behalf Of Curt
Hagenlocher
Sent: Wednesday, April 30, 2008 8:14 PM
To: [email protected]
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 M.
<[email protected]mailto:[email protected]>
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
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.
On Wed, Apr 30, 2008 at 8:36 PM, M. David P.
[email protected]
wrote:
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.
On Wed, 30 Apr 2008 21:43:09 -0600, Tomas R. [email protected]
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 P.
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [email protected] | [email protected]
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
M. David Peterson