rubydotnet-developer Mailing List for rubydotnet (Page 2)
Status: Alpha
Brought to you by:
thomas
Menu
▾
▴
rubydotnet-developer — rubydotnet developer list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(26) |
Aug
(3) |
Sep
(41) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(6) |
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
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-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: 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: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: 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 19:11:49
|
Rodrigo,
The ruby interpreter is not thread safe so access needs to be
serialized. If you access the ruby interpreter from multiple threads
without some form of synchronization it will like cause a core dump.
The thing is, as the ruby interpreter is now, it is most annoying to
work with it from multiple threads. There are all sorts of hacks that
you can do, but I'm pushing it to the back of the work stack, because
I'm naively hoping that someone will come and fix it :-)
Thomas
> -----Original Message-----
> From: rub...@li...
> [mailto:rub...@li...] On
> Behalf Of Rodrigo B. de Oliveira
> Sent: 28. september 2003 20:54
> To: rub...@li...
> Subject: Re: [Rubydotnet-developer] [ANN] rubydotnet-0.3.0
>
>
> Great work!
>
> What are the implications of calling eval from multiple threads?
>
> Thanks,
> Rodrigo
>
> ----- Original Message -----
> From: "Thomas Sondergaard" <th...@th...>
> To: <rub...@li...>
> Sent: Sunday, September 28, 2003 3:16 PM
> Subject: [Rubydotnet-developer] [ANN] rubydotnet-0.3.0
>
>
> > Hi guys,
> >
> > I've made a new release with an interface for embedding the ruby
> > interpreter in a .net application. RubyInterpreter.dll is
> installed in
> > the ruby bindir - the interface is fairly straightforward:
> >
> > RubyInterpreter.instance.eval("your ruby code here")
> >
> > or
> >
> > RubyInterpreter.instance.eval("your ruby code here", new object[] {
> > your args here })
> >
> > Just for the kick of it I made this in C# using P/Invoke to
> make the
> > few ruby initialization calls and rather than linking to my
> rubydotnet
> > library to access the marshalling code I use the facility for
> > implementing managed interfaces in ruby.
> >
> > http://rubydotnet.sourceforge.net
> >
> > Cheers,
> >
> > Tom
>
>
> -------------------------------------------------------
> 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: Rodrigo B. de O. <rb...@ac...> - 2003-09-28 18:57:43
|
Great work!
What are the implications of calling eval from multiple threads?
Thanks,
Rodrigo
----- Original Message -----
From: "Thomas Sondergaard" <th...@th...>
To: <rub...@li...>
Sent: Sunday, September 28, 2003 3:16 PM
Subject: [Rubydotnet-developer] [ANN] rubydotnet-0.3.0
> Hi guys,
>
> I've made a new release with an interface for embedding the ruby
> interpreter in a .net application. RubyInterpreter.dll is installed in
> the ruby bindir - the interface is fairly straightforward:
>
> RubyInterpreter.instance.eval("your ruby code here")
>
> or
>
> RubyInterpreter.instance.eval("your ruby code here", new object[] { your
> args here })
>
> Just for the kick of it I made this in C# using P/Invoke to make the few
> ruby initialization calls and rather than linking to my rubydotnet
> library to access the marshalling code I use the facility for
> implementing managed interfaces in ruby.
>
> http://rubydotnet.sourceforge.net
>
> Cheers,
>
> Tom
|
|
From: Thomas S. <th...@th...> - 2003-09-28 18:25:53
|
Hi guys,
I've made a new release with an interface for embedding the ruby
interpreter in a .net application. RubyInterpreter.dll is installed in
the ruby bindir - the interface is fairly straightforward:
RubyInterpreter.instance.eval("your ruby code here")
or
RubyInterpreter.instance.eval("your ruby code here", new object[] { your
args here })
Just for the kick of it I made this in C# using P/Invoke to make the few
ruby initialization calls and rather than linking to my rubydotnet
library to access the marshalling code I use the facility for
implementing managed interfaces in ruby.
http://rubydotnet.sourceforge.net
Cheers,
Tom
|
|
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: 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-24 16:11:04
|
> 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 |
|
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: 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: 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: 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: Thomas S. <th...@th...> - 2003-09-23 23:04:02
|
> I'd like to announce release 4 of our Ruby/.NET bridge. It includes
>
> - Offline documentation
> - An Evaluator Transcript window
> - New syntax for creating .NET delegates
> - A Samples Browser with a few lessons and samples
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.
> Hope everything is well with all of you - if you have any questions or
> ideas, please post them!
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:
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.
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
On linux it happily prints out "hello world" once a second no matter
what else you do. On Windows (the pragproc VC build of ruby, I'm using
at least) the entire process is blocked in the call to gets().
We need to fix this to make ruby threading tolerable on windows!
These are things worthwhile doing. Currently I'm also working on a small
project for embedding ruby in a .net project. It is mostly independent
on the bridge implementation, it is merely an interface for creating a
ruby interpreter instance and setting it to work.
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.
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:
There is a range of things you want to do when you bind a dynamic
language like ruby to .net using a dual-runtime approach, that is not
ruby specific, but specific to the dynamic nature of the language. I
have been building ScriptingExtensions for .net as I needed things for
rubydotnet. Currently it has the following classes/services:
1) ScriptingExtensions.ScriptEngine/Evaluator - for dynamically
evaluating C#, VB, and JScript from the script side. Primarily to allow
the script writer to express performance critical sections in .net
rather than in the scripting language, without having to create e.g. a
C# project and compile it to .net. This uses
Microsoft.CSharp(/VisualBasic/JScript) to compile code at runtime.
2) ScriptingExtensions.TypeFinder - simple class for looking up types
and namespaces. (Type.GetType doesn't look in dynamically loaded
assemblies, and there is no built-in mechanism for looking up a
namespace, as far as I can
tell)
3) ScriptingExtensions.TypedDelegateFactory.getDelegate(Type
delegateType, IProc proc) - creates typed delegates that invoke
IProc.invoke(object[] args). ScriptingExtensions.Binder implements a
binder that can be used with Type.InvokeMember to allow automatic
conversion of IProc's to the relevant delegate type.
4) ScriptingExtensions.DynamicClassFactory.getType(Type baseType, Type[]
interfaces) - automatically create wrapper type objects with base
baseType that implements interfaces. This is necessary if you want
script objects to implement .net interfaces. This is based on
implementing all members of the interfaces in terms of
IObject.send(string msg, object[] args). baseType must implement
IObject.
I don't see why language bindings for Python, Perl, TCL, PHP, Lua etc
wouldn't need the same services.
Cheers,
Thomas
|
|
From: Ben S. <bsc...@pr...> - 2003-09-23 21:37:29
|
Hi everyone, I'd like to announce release 4 of our Ruby/.NET bridge. It includes - Offline documentation - An Evaluator Transcript window - New syntax for creating .NET delegates - A Samples Browser with a few lessons and samples There are other changes as well - please see=20 http://www.saltypickle.com/RubyDotNet/R4 for more information. Hope everything is well with all of you - if you have any questions or = ideas, please post them! Regards, Ben Schroeder |
|
From: Richard K. <ri...@in...> - 2003-09-22 20:39:44
|
you should check out this URL for hints on embedding Ruby in a C++ framework: http://aeditor.rubyforge.org/ruby_cplusplus/index.html great work btw... -rich On Monday, September 22, 2003, at 04:16 PM, Thomas Sondergaard wrote: > > No, you can't embed the ruby interpreter yet. It is a very good idea, > though. I wonder what it would take to make it happen? The marshalling > code is essentially the same and the same services are necessary for > calling back to .net from ruby. Wouldn't it be a simple matter of > creating a managed C++ extension that hosts the .net interpreter and > makes it require 'dotnet'. The API would then be |
|
From: Thomas S. <th...@th...> - 2003-09-22 20:16:40
|
Hi Tim,
> Hi Thomas. This looks really great! I've suspended my project
> in favour of yours. I like the "implements
> System::IDisposable" example.
Thanks.
> Does your project support calling Ruby from C#?
No, you can't embed the ruby interpreter yet. It is a very good idea,
though. I wonder what it would take to make it happen? The marshalling
code is essentially the same and the same services are necessary for
calling back to .net from ruby. Wouldn't it be a simple matter of
creating a managed C++ extension that hosts the .net interpreter and
makes it require 'dotnet'. The API would then be
namespace RubyDotNet {
class RubyInterpreter {
// Ideally you would have a static createInstance
// or just a ctor, but ruby is non-reentrant, so we
// would have to settle for
public static RubyInterpreter instance { get { ... } }
private RubyInterpreter() { ... }
public object eval(string rubyString, object[] args) {
... }
// Perhaps some convenience methods
public object eval(string rubyString) {
return eval(rubyString, null);
}
public bool require(string fileName) {
eval("require '"+fileName+"'");
}
...
}
}
Initializing the ruby interpreter is not difficult, so I think it should
be relatively easy to implement the necessary method eval() and the
ctor.
Cheers,
Thomas
|
|
From: Ben S. <bsc...@pr...> - 2003-09-22 12:55:49
|
> > Your feedback is welcome. I have included a sample of the=20 > main features > > below. >=20 > Hi Thomas. This looks really great! I've suspended my project=20 > in favour > of yours. I like the "implements System::IDisposable" example. Thomas, I agree - looks like a nice project! I think my favorite parts are = cs_compile and cs_eval (and their vb_ and js_ cousins). I think we forgot to mention it here (and not to plug too much ;) but we = recently released Release 3 of our own bridge, which includes a "direct" = managed C++ extension mode as well as .NET interface implementation. If = you haven't seen it, it's at http://www.saltypickle.com/RubyDotNet/downloads I'd be interested in any feedback! By the way - I should also mention that I have new respect for what = you've been saying about Ruby threading from extensions. We were = working last week on an experiment to do a bridge in the style of our = sockets bridge - that is, string-based - but using an extension. Aargh! = :) (Our standard direct extension uses a different model, and only works on = one thread. That still lets us do a fair amount of work, though, = including windowing.) Regards, Ben Schroeder |
|
From: Tim S. <ti...@ih...> - 2003-09-22 10:40:20
|
On Sat, Sep 20, 2003 at 12:37:13AM +0200, Thomas Sondergaard wrote: > I have released rubydotnet-0.2.0 which is my take on a .net interop ruby > extension. > > Website: http://rubydotnet.sourceforge.net. > Download: http://sourceforge.net/project/showfiles.php?group_id=85733 > > Your feedback is welcome. I have included a sample of the main features > below. Hi Thomas. This looks really great! I've suspended my project in favour of yours. I like the "implements System::IDisposable" example. Does your project support calling Ruby from C#? |
|
From: Thomas S. <th...@th...> - 2003-09-19 22:38:00
|
I have released rubydotnet-0.2.0 which is my take on a .net interop ruby extension. Website: http://rubydotnet.sourceforge.net. Download: http://sourceforge.net/project/showfiles.php?group_id=85733 Your feedback is welcome. I have included a sample of the main features below. Cheers, Tom # This sample demonstrates a lot of rubydotnet features # including: instantiating objects from .net classes, accessing # the features on the objects, implementing .net interfaces in ruby, # .net delegates that call ruby. It also shows how to include C# # directly in the ruby script require 'dotnet' # Lesson 1: Instatiating and using objects arrayList = System::Collections::ArrayList.new include System::Collections arrayList2 = ArrayList.new 1000.times { |i| arrayList2.add(i*i) } puts "arrayList2[10] = #{arrayList2[10]}" # Lesson 2: Using C# (or VB.net or JScript) directly # within a ruby script. # cs_compile has vb_compile and js_compile cousins for # Visual Basic .net and JScript.net cs_compile <<-EOF using System; public delegate void MyDelegate(string arg); public class MyClass { public static string aProperty { get { return "propValue"; } } public static event MyDelegate myEvent; public static void fireMyEvent(string arg) { if (myEvent != null) myEvent(arg); } } EOF puts "MyClass.aProperty = #{MyClass.aProperty}" # Lesson 3: Using events and call backs MyClass.add_myEvent(proc { |s| puts "proc1 called with s=#{s}" }) MyClass.add_myEvent(proc { |s| puts "proc2 called with s=#{s}" }) MyClass.fireMyEvent("hello world") # Lesson 4: Implementing .net interfaces with a ruby object # and using cs_eval to evaluate a small C# fragment. Notice # the same can be achieved with vb_eval or js_eval for # VisualBasic.net and JScript.net class MyDisposableRubyClass implements System::IDisposable def Dispose puts "Dispose called" end end myDisposableInstance = MyDisposableRubyClass.new # cs_eval(script, *args) - script must return a value (e.g. null). # args are available as an System::Object[] array cs_eval("((IDisposable)args[0]).Dispose(); return null;", myDisposableInstance) |
|
From: Ben S. <bsc...@pr...> - 2003-09-12 14:20:50
|
Hi Thomas, > I just grepped through your code and you don't seem to use the > rb_gc_(register|unregister)_address functions. Do you know=20 > another trick for > keeping the ruby GC from reaping the ruby objects that are=20 > only referenced > from .net? We keep a hash of all of the Ruby objects we've ever referenced from = .NET. It is pretty low-tech, but works to keep the GC from harvesting = the objects. (We actually never release them - proper GC is something = we still need to work on.) This may not have been in any version that you have - there are some = Ruby-in-.NET improvements in our R3 release (due soon). > Btw, I have just thought of something! The .net GC runs=20 > asynchronously and > the finalizer may just be invoked on a bad time causing=20 > everything to bomb > because ruby is not thread safe. That sounds like it could be the case - I hope you find the problem! If = you want to bounce any other ideas off us - just send them ... Regards, Ben |
|
From: Tim S. <ti...@ih...> - 2003-09-12 05:04:02
|
On Fri, Sep 12, 2003 at 01:52:54AM +0200, Thomas Sondergaard wrote: [...] > Btw, I have just thought of something! The .net GC runs asynchronously and > the finalizer may just be invoked on a bad time causing everything to bomb > because ruby is not thread safe. [...] Yes, this definitely does happen. |
|
From: Thomas S. <th...@th...> - 2003-09-11 23:53:13
|
Hi,
If you follow the ruby-talk mailing list you may have noticed that I have
asked around about garbage collection, because I sometimes get a core dump
that seems to be related to garbage collection on either the .net or ruby
side.
When I pass a ruby object by reference to .net I wrap it up in a .net object
that has a constructor and a finalizer that takes care of 'locking' the ruby
object so it is not reaped by the ruby gc:
public __gc class Object : public DynamicLanguageSupport::IObject {
public:
explicit Object(VALUE handle) {
_handle = ALLOC(VALUE);
*_handle = handle;
rb_gc_register_address(_handle);
}
~Object() {
rb_gc_unregister_address(_handle);
free(_handle);
}
// stuff for invoking ruby methods from .net removed
private:
VALUE __nogc *_handle;
};
I just grepped through your code and you don't seem to use the
rb_gc_(register|unregister)_address functions. Do you know another trick for
keeping the ruby GC from reaping the ruby objects that are only referenced
from .net?
Btw, I have just thought of something! The .net GC runs asynchronously and
the finalizer may just be invoked on a bad time causing everything to bomb
because ruby is not thread safe.
Cheers,
Thomas
|
