Thread: RE: [Rubydotnet-developer] [ANN] Ruby/.NET bridge release 4 now available
Status: Alpha
Brought to you by:
thomas
Menu
▾
▴
rubydotnet-developer
|
From: John R. P. <jo...@pi...> - 2003-09-24 00:54:11
|
On Wed, 24 Sep 2003 01:02:42 +0200, "Thomas Sondergaard" wrote:
> Great! Things are moving along nicely. It's a tell tale sign that you
> are getting quite feature complete now that you can devote time to
> documentation.
This was cheaper than expected! Our swiki lets us render itself to static HTML
pages which made this an hour project -- good thing!
> I have a couple of ideas. I think both our bridges are getting
> reasonably feature complete. I think there are two significant things
> that could contribute to both our projects and the ultimate goal the
> best possible integration with .net from ruby:
One major feature we've yet to implement is class inheritance. We have
interface inheritance, but we'll be adding class inheritance soon. Beyond that
we have some tidying up to do (GC and performance could be a rathole for a
while).
> 1) A dogfood project - as in eating our own. A large or largish
> application written in ruby using the .net facilities. Unit tests are
> great but it would be interesting to flush out the bugs you only find
> with use and get a feel for the runtime performance etc.
Hmm, what sort of largish application could you imagine we should write?
Internally we've used the .NET bridge to build tools to make our development go
faster (e.g. source control coordination, agile development tools, etc...). Are
you thinking about building a web application (for broad acceptance)?
We have a running joke at work about conserving GUIDs. Springing off this idea,
maybe we could develop a Web Application to "Save the Guids" using our bridges.
Users could register an account with the site, return Guids to a master pool,
get new GUIDs when they need them, get credits for returning the ones when they
are done, have a top 100 users who conserve on GUIDs, etc.... It is crazy for
sure -- maybe too goofy, but a thought.
> 2) Contributing to ruby itself to improve it's threading on Windows. I
> have run some experiments using ruby (no .net) on Windows and linux with
> ruby threads. On linux things appear to work sanely. Take for instance
> this small script:
>
> t = Thread.new { loop { sleep 1; puts "hello world" } }
> loop { puts gets }
> t.join
Gosh, we second this! Agreed! Why does it have to block? This needs fixed in
either Ruby or the underlying platform. Any thoughts on how to proceed? Should
we work with the Pragmatic Programmers? This has been quite annoying to us and
limits what we can do.
> I am also thinking about a Mono port using the mono hosting API. The
> managed C++ extension wont work on non-windows platforms and I think the
> cross platform aspect is important to the ruby community. Unix support
> in itself certainly is important to the community.
Certainly Mono is a new direction to take the bridge technology. I fear that
the Ruby community at large might not have interest in what Microsoft is doing
-- so maybe Mono doesn't interest anyone anymore than .NET. I don't know, but
it could be a big rathole for limited acceptance. What do you really think?
> I have also been lobbying around the Python, Tcl and Lua camps to hear
> if they have similar projects as ours and suggested that we collaborate
> on the bits that are similar across projects. I have been sending them
> the following lines:
We certainly would love to collaborate more with other languages gurus. As you
said, much of the technology and techniques applied to Ruby/.NET are applicable
when bridging VMs. For instance, we built a Squeak Smalltalk interface to the
backend .NET bridge real quick and easy once we understood the issues in Ruby.
I wonder if we should seriously consider joining efforts more closely before
seriously considering offering a helping hand to other language enthusiasts? The
trouble is, we both have a lot invested in what we've done and merging is never
an easy task. Maybe it doesn't matter, but I just wonder.
Regards,
John
|
|
From: Lee F. <le...@mi...> - 2003-09-24 01:07:58
|
pointer to Brad's .NET compiler developer page: http://gotdotnet.com/team/lang/ pointer to Brad and Peter's OScon dynamic languages BOF: http://conferences.oreillynet.com/cs/os2003/view/e_sess/4557 BOF story that has quotes from Brad and Peter: http://idevnews.com/IntegrationNews.asp?ID=3D78 other info on this BOF: http://www.google.com/search?hl=3Den&ie=3DUTF-8&oe=3DUTF-8&q=3DOScon+micr= osoft+d ynamic+languages=20 -----Original Message----- From: rub...@li... [mailto:rub...@li...] On Behalf Of John R. Pierce Sent: Tuesday, September 23, 2003 5:54 PM To: rub...@li... Cc: ben...@ac... Subject: RE: [Rubydotnet-developer] [ANN] Ruby/.NET bridge release 4 now available On Wed, 24 Sep 2003 01:02:42 +0200, "Thomas Sondergaard" wrote: > Great! Things are moving along nicely. It's a tell tale sign that you > are getting quite feature complete now that you can devote time to > documentation. This was cheaper than expected! Our swiki lets us render itself to static HTML pages which made this an hour project -- good thing! > I have a couple of ideas. I think both our bridges are getting > reasonably feature complete. I think there are two significant things > that could contribute to both our projects and the ultimate goal the > best possible integration with .net from ruby: One major feature we've yet to implement is class inheritance. We have interface inheritance, but we'll be adding class inheritance soon. Beyond that we have some tidying up to do (GC and performance could be a rathole for a while). > 1) A dogfood project - as in eating our own. A large or largish > application written in ruby using the .net facilities. Unit tests are > great but it would be interesting to flush out the bugs you only find > with use and get a feel for the runtime performance etc. Hmm, what sort of largish application could you imagine we should write? Internally we've used the .NET bridge to build tools to make our development go faster (e.g. source control coordination, agile development tools, etc...). Are you thinking about building a web application (for broad acceptance)?=20 We have a running joke at work about conserving GUIDs. Springing off this idea, maybe we could develop a Web Application to "Save the Guids" using our bridges.=20 Users could register an account with the site, return Guids to a master pool, get new GUIDs when they need them, get credits for returning the ones when they are done, have a top 100 users who conserve on GUIDs, etc.... It is crazy for sure -- maybe too goofy, but a thought. > 2) Contributing to ruby itself to improve it's threading on Windows. I > have run some experiments using ruby (no .net) on Windows and linux with > ruby threads. On linux things appear to work sanely. Take for instance > this small script: >=20 > t =3D Thread.new { loop { sleep 1; puts "hello world" } } > loop { puts gets } > t.join =20 Gosh, we second this! Agreed! Why does it have to block? This needs fixed in either Ruby or the underlying platform. Any thoughts on how to proceed? Should we work with the Pragmatic Programmers? This has been quite annoying to us and limits what we can do. > I am also thinking about a Mono port using the mono hosting API. The > managed C++ extension wont work on non-windows platforms and I think the > cross platform aspect is important to the ruby community. Unix support > in itself certainly is important to the community. Certainly Mono is a new direction to take the bridge technology. I fear that the Ruby community at large might not have interest in what Microsoft is doing -- so maybe Mono doesn't interest anyone anymore than .NET. I don't know, but it could be a big rathole for limited acceptance. What do you really think? > I have also been lobbying around the Python, Tcl and Lua camps to hear > if they have similar projects as ours and suggested that we collaborate > on the bits that are similar across projects. I have been sending them > the following lines: We certainly would love to collaborate more with other languages gurus. As you said, much of the technology and techniques applied to Ruby/.NET are applicable when bridging VMs. For instance, we built a Squeak Smalltalk interface to the backend .NET bridge real quick and easy once we understood the issues in Ruby. I wonder if we should seriously consider joining efforts more closely before seriously considering offering a helping hand to other language enthusiasts? The trouble is, we both have a lot invested in what we've done and merging is never an easy task. Maybe it doesn't matter, but I just wonder. Regards, John ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Rubydotnet-developer mailing list Rub...@li... https://lists.sourceforge.net/lists/listinfo/rubydotnet-developer |
|
From: Lee F. <le...@mi...> - 2003-09-24 01:14:58
|
[Sorry, about that last message, pressed the wrong key, didn't meant to send that last message as it was... The key bindings from one programmer's editor -- burned into my hands -- occasionally conflicts with Outlook, causing me grief like this occasionally. I need to file a bug for users to be able to override Outlook's send-message feature...] Anyway, I wanted to make sure that the Ruby/.NET people here knew about a .NET-centric mailing list for people writing .NET IL compilers. This site http://gotdotnet.com/team/lang/ has a pointer to the list. Or see http://discuss.microsoft.com/archives/dotnet-language-devs.html (you have to subscribe to get access to the archives.) There are a bunch of good people on this list, people with lots of compiler experience (from the .NET and Visual Studio teams as well as numerous commercial companies and open source compiler projects), and .NET IL experience. It would be worthwhile for people on this list to leverage the experience they have. Lee |
|
From: Ben S. <bsc...@pr...> - 2003-09-26 13:34:18
|
Hi Thomas, Thanks for your mail - sorry for the late reply. > I think it is worth considering too. So lets talk about it=20 > and see what we can agree on. >=20 > When I started I was aware of your project and I have=20 > attempted to factor my code so it is relatively easy to=20 > separate parts and merge into other projects. The parts that=20 > are mostly independent of my rubydotnet extension are >=20 > 1) The type resolution system and the interface 'implements'=20 > statement is independent of .net and my rubydotnet module and=20 > would work with your extension or the java equivalent, for=20 > that matter. I know that you like the namespace "flattening"=20 > that your extension provides, but I prefer having full=20 > control and more importantly I like the fact that accessing=20 > the .net classes from ruby is completely equivalent to the=20 > way ordinary ruby classes are accessed. I'd like to say a little more about why I like the namespace-independent binding, discuss some objections, and comment on some ways we might be able to provide options. I'll discuss the "implements" clauses separately. We write a fair amount of C# here, and one of my least favorite things is writing "using" statements. It feels a bit like I am telling the compiler something it should already know: where to find a particular class I want to use. I think of StreamWriter, for example, more readily as "StreamWriter" than as "System.IO.StreamWriter", even though it is in fact the latter. This was also my experience when I worked with Java. One of the things we frequently use our bridge for is exploratory work. When I fire up irb or one of our Evaluator windows, it is nice to be able to just start typing "ArrayList" or "DataGrid" without having to qualify anything. Also, for a new user, it's one thing fewer to learn before starting to work productively. This is similar to one reason that having global access (which our latest releases do) is so nice: there's no need to say "start DotNet" or "here's the DotNet instance where you can find ArrayList". One objection to the above is that ambiguities can result. Our canonical example is the difference between System.Reflection.Emit.Label and System.Windows.Forms.Label; the bridge prefers the former as a binding for the name "Label", as it gets loaded first. This is rare, but annoying and confusing when it does happen. Another objection is that it gives .NET's namespace mechanism no analog in Ruby. Modules seem like a natural way to provide this analog. Namespaces do lack some features of modules, of course, like the ability to mix in functions. The conceptual impurity introduced by these, especially by the first, is troubling. Why should the name-binding rule be A name binds to a Ruby class first, then a DotNet class anywhere, but only the first one that is found. When it could be A name binds to a Ruby class first, then to a DotNet class in one of the namespace-modules you've included. or even A name binds to a class in one of the modules you've included, whether they're DotNet ones or not? Despite that, I still have come down lately at least slightly, and perhaps more than that, on the pragmatic side of namespaces - preferring the ease-of-use introduced by the flattening. (Perhaps it is a different aspect of simplicity.) Could we provide ways to disambiguate things? One that we have discussed here is to say something like Label =3D System.Windows.Forms.Label for specific cases. Another would be for the bridge to refuse to choose between ambiguous names itself, but rather to raise an exception when a clash occurred. --- I have a couple of thoughts about the "implements" clause. One is that I like the extra documentation: "this is an IList". Ruby's open classes would even make the clauses easy to add later. However, I wonder whether requiring such a clause is in the spirit of Ruby's dynamic, duck-typing type system. Without requiring an "implements" clause, any object that has the right methods can participate as an IList, just as any Ruby object can stand in for another. > 2) ScriptingExtensions for .net depends on two narrow/small=20 > interfaces IObject and IProc. There is significant overlap=20 > with your code when it concerns typed delegate creation and=20 > .net interface implementation, but it is not much code and we=20 > should adopt interface and implementation to the more robust=20 > and flexible of the two, if we were to merge. I would very=20 > much like to keep all the non-ruby specific stuff in a=20 > separate project. I have joined the modules using the CVS=20 > facility for doing so, I'm sure Perforce has the same=20 > ability. I am very certain that the Lua and TCL camps and=20 > others will soon desire .net interop and we may as well share=20 > functionality that is common across all scripting languages. I like the idea of sharing common pieces across different scripting bridges. Our usual practice is to design such common pieces by doing two things, then by removing duplication, in the spirit of what an Extreme Programmer would do. This kind of design is given the benefit of more experience with what is common; it also does not constrain earlier implementations based on a supposition about what might come in the future. We did recently write a second client interface to our bridge, for Squeak Smalltalk. Squeak's object system is similar to Ruby's, which probably made the task easier than for a system with a different feel. We found some places in the design that needed smoothing (and there are probably still more). We haven't yet done an "embedding", .NET-to-Ruby interface for Squeak, although .NET code that happened to take one of our ClientObject instances could probably use its Call method to call Squeak. (This is how interface implementation is handled.) > So my position is that I would want to keep these two aspects=20 > of my project. Next on my work agenda are >=20 > * Embedding interface, so you can embed the ruby interpreter=20 > in a .net application. Do you all ready have an interface for=20 > embedding the interpreter without the use of sockets? > * Mono support > * Take a look at ruby threading on Windows > * Ruby support in Visual Studio .net - primarily indentation=20 > and syntax highlighting. All of these look interesting. Regarding the first point: we don't have that kind of interface yet. What is missing, I think, is startup code and the ability to ask the bridge to eval an arbitrary piece of code. Once you have a ClientObject in hand, everything should work using the normal callback facilities. > The last two bullit points are not really within the scope of=20 > rubydotnet. Agreed, but also agreed that they could be important or interesting. --- Well, those are some of my thoughts - they might be too long. They're in no way the final thing I have to say on these matters; I write them in hope of encouraging discussion. What are your thoughts? Regards, Ben Schroeder |
|
From: Thomas S. <th...@th...> - 2003-09-26 16:36:58
|
It is my wish that rubydotnet is as transparent as possible and I have succeeded if people using it think of .net classes and objects as no different from other ruby classes and objects. Therefore I don't want to make distinctions and namespace flattening in one hierarchy, ie. the .net class hierarchy, and not in the other, ie. other ruby modules. Personally I want to be pure about this. On the other hand ruby is all about being pragmatic and if someone prefers the namespace flattening they should be able to choose so. Since this is all hooked up using Module#const_missing it is trivial to support both and allow the user to choose. We could just have a switch Object#flatten_namespace=true/false. When the value is changed we replace the definition of const_missing to one that does one or the other. Performance-wise I think there are clear advantages to not using flattening. For one thing, once a namespace or class has been looked up once using const_missing it is instantiated into the ordinary lookup mechanism and is everybit as fast as ruby normally is. This is not generally possible with the flattened namespace as you would collide with Object, String, Array, Exception, GC and maybe more. > Another objection is that it gives .NET's namespace mechanism > no analog in Ruby. Modules seem like a natural way to > provide this analog. Namespaces do lack some features of > modules, of course, like the ability to mix in functions. It is conventional to use modules as namespaces, and the fact that modules are more general than namespaces is not a problem it would be worse if it was the other way around :-) > Could we provide ways to disambiguate things? One that we > have discussed here is to say something like > > Label = System.Windows.Forms.Label > > for specific cases. Another would be for the bridge to > refuse to choose between ambiguous names itself, but rather > to raise an exception when a clash occurred. We probably could, but again I feel that we should not try to over-do ruby. In ruby there is no ambiguity because scopes are searched in a well-known order and the same constant cannot have different values in the same scope. > I have a couple of thoughts about the "implements" clause. > One is that I like the extra documentation: "this is an > IList". Ruby's open classes would even make the clauses easy > to add later. > > However, I wonder whether requiring such a clause is in the > spirit of Ruby's dynamic, duck-typing type system. Without > requiring an "implements" clause, any object that has the > right methods can participate as an IList, just as any Ruby > object can stand in for another. Okay, I'm confused. I added the implements clause because I needed it, not for documentation. How do you guys manage to figure out which interfaces to implement otherwise? Do you base it which methods are actually implemented by an object? If so I at least want to say.. wow. > I like the idea of sharing common pieces across different > scripting bridges. Our usual practice is to design such > common pieces by doing two things, then by removing > duplication, in the spirit of what an > Extreme Programmer would do. This kind of design is given > the benefit > of more experience with what is common; it also does not > constrain earlier implementations based on a supposition > about what might come in the future. I am an XP/Agile coder myself, though normally more pragmatic than XP-dogmatic. All the same I like to orthogonalize early and push things out into supporting functions, that simplify the main task I have to accomplish. What I am promoting with ScriptingExtensions for .net is a class library of utilities that are useful for tying scripting languages to .net. There is probably less reuse than your framework for reuse, but there is also more freedom and less policy. It is the difference between a framework for interoperation vs a support library for interoperation. It is easier to match a support library to different languages, as you are not forced to use features that do not match your environment. > All of these look interesting. Regarding the first point: we > don't have that kind of interface yet. What is missing, I > think, is startup code and the ability to ask the bridge to > eval an arbitrary piece of code. Once you have a ClientObject > in hand, everything should work using the normal callback facilities. Agreed, it should simply be a matter of starting the interpreter in-process and providing an interface for eval'ing/executing scripts. I have answered somewhat selectively to keep the conversation managable. Cheers, Thomas |
|
From: John R. P. <jo...@pi...> - 2003-09-28 21:57:51
|
On Fri, 26 Sep 2003 18:32:06 +0200, "Thomas Sondergaard" wrote: > It is my wish that rubydotnet is as transparent as possible and I have > succeeded if people using it think of .net classes and objects as no > different from other ruby classes and objects. Therefore I don't want to > make distinctions and namespace flattening in one hierarchy, ie. the > .net class hierarchy, and not in the other, ie. other ruby modules. Agreed...we actually want to make the bridge transparent as well. What doesn't seem clear to me is that transparency is somehow lost or less if we flatten namespaces. After all, namespaces in .NET and Ruby modules are not exactly one to one. > Personally I want to be pure about this. On the other hand ruby is all > about being pragmatic and if someone prefers the namespace flattening > they should be able to choose so. Since this is all hooked up using > Module#const_missing it is trivial to support both and allow the user to > choose. We could just have a switch Object#flatten_namespace=true/false. > When the value is changed we replace the definition of const_missing to > one that does one or the other. We could do this, as you say, very easily, but I suspect you would not agree with our choice of default value (flatten_namespace = true)! By the way, if we provided the option, who would prefer to not flatten the namespaces? > Performance-wise I think there are clear advantages to not using > flattening. For one thing, once a namespace or class has been looked up > once using const_missing it is instantiated into the ordinary lookup > mechanism and is everybit as fast as ruby normally is. This is not > generally possible with the flattened namespace as you would collide > with Object, String, Array, Exception, GC and maybe more. I don't see how flattening a namespace prevents peformance optimizations. What makes you think you can't look up the constant once then keep a hash or define a new global in either approach? > > Another objection is that it gives .NET's namespace mechanism > > no analog in Ruby. Modules seem like a natural way to > > provide this analog. Namespaces do lack some features of > > modules, of course, like the ability to mix in functions. I have yet to find it anything but natural to type the following code at the top of every C# file: using System; using System.Collection; It always gets me! Gosh -- I've even heard of IDE's on the market that automatically include using statements -- what a nice idea! So then, why do language inventors make us do this anyways? > It is conventional to use modules as namespaces, and the fact that > modules are more general than namespaces is not a problem it would be > worse if it was the other way around :-) Agreed, but do we always have to be so pure? I just like to be able to type programs in real fast that work with POLS (principle of least surprise). I am always shocked when the C# compiler tells me it doesn't know who ArrayList is when I just got done using it every else in the program. Silly compiler! > We probably could, but again I feel that we should not try to over-do > ruby. In ruby there is no ambiguity because scopes are searched in a > well-known order and the same constant cannot have different values in > the same scope. So do you know what happens if you include System.Reflection.Emit and System.Windows.Forms? What does Label resolve to? Is an ambiguity introduced manually less ambiguous than an ambiguity introduced automatically? > Okay, I'm confused. I added the implements clause because I needed it, > not for documentation. How do you guys manage to figure out which > interfaces to implement otherwise? Do you base it which methods are > actually implemented by an object? If so I at least want to say.. wow. Maybe you'd be disappointed if we told you. It's actually worse than that! We take the programmers word for it! If you try to use a Ruby object as IDisposable then we just build the interface wrapper and give it a whirl. What could go wrong? > It is easier to match a support library to different languages, as you > are not forced to use features that do not match your environment. But until I know the features in those other environments that might not work, it seems way too speculative for us to design for them. You might be more familiar with those other languages than us -- so we'd value your input! Regards, John |
|
From: Thomas S. <th...@th...> - 2003-09-28 23:05:23
|
> Agreed...we actually want to make the bridge transparent as
> well. What doesn't seem clear to me is that transparency is
> somehow lost or less if we flatten namespaces. After all,
> namespaces in .NET and Ruby modules are not exactly one to one.
True. But think of it this way. I want to say to the ruby developer that
knows the .net framework. Just do what you would do if you thought the
.net framework was actually implemented in ruby. I am pretty sure that
people would expect the namespace hierarchy to be conserved and modules
are the namespaces in ruby - they also do other things, but they *are*
the namespaces of ruby.
> We could do this, as you say, very easily, but I suspect you
> would not agree with our choice of default value
> (flatten_namespace = true)! By the way, if we provided the
> option, who would prefer to not flatten the namespaces?
I would probably use it in irb, but not in a script. I would be
indifferent to the default value.
> I don't see how flattening a namespace prevents peformance
> optimizations. What makes you think you can't look up the
> constant once then keep a hash or define a new global in
> either approach?
Of course you are right. I was just thinking that resolving classes
using constants would be the fastest possible way, but it is probably
implemented with a hash by ruby :-)
> So do you know what happens if you include
> System.Reflection.Emit and System.Windows.Forms? What does
> Label resolve to? Is an ambiguity introduced manually less
> ambiguous than an ambiguity introduced automatically?
In C#? Yes sure, if there is an ambiguity you have to used the fully
qualified form. In ruby the ambiguity cannot exist. The same constant
can only reference one type in a given scope. The "innermost" constant
wins when the scopes are searched outwards for the constant. At least
thats how I understand it.
> Maybe you'd be disappointed if we told you. It's actually
> worse than that! We take the programmers word for it! If you
> try to use a Ruby object as IDisposable then we just build
> the interface wrapper and give it a whirl. What could go wrong?
Nothing. Things will fail nicely at runtime, as we are used to in ruby.
If I understand you correctly you are determining the interface at
binding time when a .net method is invoked from ruby. What if I want to
fill up an ArrayList of IKeyMaps (I made that up). I mean, the
conversion can only happen at the boundary between ruby and .net, so
what if you have to go indirectly via something like a list of Objects?
But I think it might be a cool idea all the same. I'll have to digest
it, but it could be good :-)
Now that I'm caving in to your design decisions :-) ... I'd like to know
how the other people on this list feels about the namespace flattening
feature. Is it what we want for ruby with .net? Why is it that we want
this with ruby, when the .net folks to great measures to make the
hierarchy?
Be honest, but not brutal :-)
> > It is easier to match a support library to different
> languages, as you
> > are not forced to use features that do not match your environment.
>
> But until I know the features in those other environments
> that might not work, it seems way too speculative for us to
> design for them. You might be more familiar with those other
> languages than us -- so we'd value your input!
Probably not. I know a bit of Python and Perl and next to nothing about
Lua and Tcl. What I do know is that services such as generation of
managed interfaces and delegates that forward to a dynamic object can be
implemented based on two extremely generic interfaces:
namespace ScriptingExtensions {
public interface IObject {
object send(string message, object[] args);
}
public interface IProc {
object call(object[] args);
}
}
Designing for multiple languages or not, I want to keep stuff as
orthogonal as possible for my own sake. Similarly the basic support for
writing C# and VB from inside the scripting languages is easy to factor
out too. I'm not saying that you should always do it, but when it is
down-right obvious it is worth doing even if you don't ever reuse the
code for another language.
I am going to diverge from rubydotnet pretty soon. I will probably do
Mono support and an optimization that keeps week references to proxies
to avoid creating them over and over and then I'll take a look at
something else. What I'm saying is that the duplication of effort will
stop pretty soon, anyway.
I have discovered that there is going to be a presentation about ruby
and Visual Studio .net 2003 at RubyConf. Are any of you guys going?
Anyway, I have been thinking about adding editor support to visual
studio .net 2003 my self, but maybe I wont have to. I think this is
quite exciting as my fingers always gets confused when I jump between
ruby/emacs and C#/C++/Visual Studio. So if ruby threading could just be
worked out ruby would really be shining on Windows!
|
|
From: Rodrigo B. de O. <rb...@ac...> - 2003-09-28 23:47:49
|
----- Original Message ----- From: "Thomas Sondergaard" <th...@th...> > ... > Now that I'm caving in to your design decisions :-) ... I'd like to know > how the other people on this list feels about the namespace flattening > feature. Is it what we want for ruby with .net? Why is it that we want > this with ruby, when the .net folks to great measures to make the > hierarchy? > I spend most of my time writing C# code nowadays and it just feels natural to include System::Windows::Forms and reference 'System.Windows.Forms' whenever I need them. > Be honest, but not brutal :-) > Well, I don't know how this will sound but I must tell you that I switched bridges because of the namespace flattening behavior alone. > ... > Anyway, I have been thinking about adding editor support to visual > studio .net 2003 my self, but maybe I wont have to. I think this is > quite exciting as my fingers always gets confused when I jump between > ruby/emacs and C#/C++/Visual Studio. > Personally, I'd rather see ruby support to a cross-platform free ide such as eclipse. > So if ruby threading could just be > worked out ruby would really be shining on Windows! > Yes!! all the best, Rodrigo |
|
From: Thomas S. <th...@th...> - 2003-09-28 23:55:06
|
> > Be honest, but not brutal :-) > > > > Well, I don't know how this will sound but I must tell you > that I switched bridges because of the namespace flattening > behavior alone. Sounds pretty brutal to me! LOL :-) Cheers, Tom |
|
From: Richard K. <ri...@in...> - 2003-09-29 11:48:19
|
I will chime in here as someone who has written a lot of Ruby code.
When I first started with Ruby, I did not use modules (as namespaces)
much at all. Now I use them all the time. I used to use a lot of
include <module> (as namespace...not mixin) now I don't do that much.
The reason is this. From 95-01 I did mostly Java coding, and not only
did you have to place stuff in packages, but anyone that wanted to use
your classes either had to import your package, or fully qualify the
class. You had a lot of imports just to satisfy casting objects to
type. In Ruby because its dynamically typed, you can pass objects
around (regardless of their originating namespace) and use them,
without the import. This makes me do this quite often:
module Foo
class Bar
class AnotherClass
end
end
end
And deeply nest the classes in namespaces without worries because I
make sure that the consumption of those "inner" classes is simple (like
adding a method to class Bar that accepts parameters and builds an
instance of AnotherClass).
I hope this makes some sense, and there is more that I could go into
(like using the fxRuby API to build FreeRIDE)...but I will leave it at
that for now.
Now, there are lots of namespace modules in Ruby right now. Those
namespaces are there for a reason...to disambiguate/group function. It
would be very simple to provide a module that was a flat namespace for
those that wanted to just script .NET, but if you are writing lots and
lots of Ruby code (and .NET), I don't believe you would want a flat
namespace. I would recommend syntax like..
include DotNet::AllClasses # (or something)
...that if you had in a script would give you what you want, but the
default should be hierarchical. If I had to choose a library that made
everything flat vs. allowed hierarchy, I would chose the latter. Also
remember that folks may be building Ruby libraries on top of your .NET
bridge to 'rubify' the .NET API. If they did this they would likely
not want/need the .NET classes all available in a single namespace,
because folks would not be directly using them.
-rich
On Sunday, September 28, 2003, at 07:03 PM, Thomas Sondergaard wrote:
> Now that I'm caving in to your design decisions :-) ... I'd like to
> know
> how the other people on this list feels about the namespace flattening
> feature. Is it what we want for ruby with .net? Why is it that we want
> this with ruby, when the .net folks to great measures to make the
> hierarchy?
|
|
From: Ben S. <bsc...@pr...> - 2003-09-29 03:22:33
|
Hi Rodrigo, >> Be honest, but not brutal :-) >>=20 > >Well, I don't know how this will sound but I must tell you that I = switched >bridges because of the namespace flattening behavior alone. I wasn't sure from your message which bridge you were now using - = whether you preferred the flattening or the modules. Could you say a = little more about your thoughts? >> So if ruby threading could just be >> worked out ruby would really be shining on Windows! >>=20 > > Yes!! Add my vote too ... :) Thanks, Ben Schroeder |
|
From: Thomas S. <th...@th...> - 2003-09-29 11:29:40
|
> >Well, I don't know how this will sound but I must tell you that I > >switched bridges because of the namespace flattening behavior alone. > > I wasn't sure from your message which bridge you were now > using - whether you preferred the flattening or the modules. > Could you say a little more about your thoughts? I read it as if he favoured the namespace flattening. But now you mention it, I can see that it is a little ambiguous. Cheers, Tom |
|
From: Rodrigo B. de O. <rb...@ac...> - 2003-09-29 12:11:14
|
Sorry for the confusion... I meant I'm now using rubydotnet[1] instead of RubyDotNet[2] (I hope you are case sensitive readers ;-)), in other words, I find it far more intuitive to have .NET namespaces translated to ruby modules. best regards, Rodrigo [1] http://sf.net/projects/rubydotnet [2] http://www.saltypickle.com/rubydotnet ----- Original Message ----- From: "Thomas Sondergaard" <th...@th...> To: <rub...@li...> Sent: Monday, September 29, 2003 7:55 AM Subject: RE: [Rubydotnet-developer] [ANN] Ruby/.NET bridge release 4 now available > > >Well, I don't know how this will sound but I must tell you that I > > >switched bridges because of the namespace flattening behavior alone. > > > > I wasn't sure from your message which bridge you were now > > using - whether you preferred the flattening or the modules. > > Could you say a little more about your thoughts? > > I read it as if he favoured the namespace flattening. But now you > mention it, I can see that it is a little ambiguous. > > Cheers, > > Tom > |
|
From: Ben S. <bsc...@pr...> - 2003-09-29 13:26:05
|
> Sorry for the confusion... >=20 > I meant I'm now using rubydotnet[1] instead of RubyDotNet[2]=20 > (I hope you are > case sensitive readers ;-)), in other words, I find it far=20 > more intuitive to > have .NET namespaces translated to ruby modules. It is as I feared. :) Thanks, Rodrigo and Rich, for your mails. I will have to think on these = things for a while - I'll try to get some thoughts out soon. Regards, Ben Schroeder |
|
From: Richard K. <ri...@in...> - 2003-09-24 05:33:07
|
This is caused by the getchar stuff under win32 using blocking IO, and since Ruby is single (native) threaded it locks up that thread. All the other IO (net specific, etc) uses non-blocking. I am sure if you search RubyTalk you will see this discussed over and over. No one has created a good solution...also popen3 would be great to have on win32. This has been tried but still nothing. -rich On Tuesday, September 23, 2003, at 08:53 PM, John R. Pierce wrote: > Gosh, we second this! Agreed! Why does it have to block? This needs > fixed in > either Ruby or the underlying platform. Any thoughts on how to > proceed? Should > we work with the Pragmatic Programmers? This has been quite annoying > to us and > limits what we can do. |
|
From: Thomas S. <th...@th...> - 2003-09-24 16:11:04
Attachments:
winmail.dat
|
> I wonder if we should seriously consider joining efforts more > closely before seriously considering offering a helping hand=20 > to other language enthusiasts? The trouble is, we both have a=20 > lot invested in what we've done and merging is never an easy=20 > task. Maybe it doesn't matter, but I just wonder. I think it is worth considering too. So lets talk about it and see what = we can agree on. When I started I was aware of your project and I have attempted to = factor my code so it is relatively easy to separate parts and merge into other projects. The parts that are mostly independent of my rubydotnet = extension are 1) The type resolution system and the interface 'implements' statement = is independent of .net and my rubydotnet module and would work with your extension or the java equivalent, for that matter. I know that you like = the namespace "flattening" that your extension provides, but I prefer having full control and more importantly I like the fact that accessing the = .net classes from ruby is completely equivalent to the way ordinary ruby = classes are accessed. 2) ScriptingExtensions for .net depends on two narrow/small interfaces IObject and IProc. There is significant overlap with your code when it concerns typed delegate creation and .net interface implementation, but = it is not much code and we should adopt interface and implementation to the more robust and flexible of the two, if we were to merge. I would very = much like to keep all the non-ruby specific stuff in a separate project. I = have joined the modules using the CVS facility for doing so, I'm sure = Perforce has the same ability. I am very certain that the Lua and TCL camps and others will soon desire .net interop and we may as well share = functionality that is common across all scripting languages. So my position is that I would want to keep these two aspects of my = project. Next on my work agenda are * Embedding interface, so you can embed the ruby interpreter in a .net application. Do you all ready have an interface for embedding the interpreter without the use of sockets? * Mono support * Take a look at ruby threading on Windows * Ruby support in Visual Studio .net - primarily indentation and syntax highlighting. The last two bullit points are not really within the scope of = rubydotnet. Thomas |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X