rubydotnet-developer Mailing List for rubydotnet
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: Tim S. <ti...@ih...> - 2004-10-29 11:11:32
|
On Fri, Oct 29, 2004 at 10:36:45PM +1300, Tim Sutherland wrote: > On Fri, Oct 29, 2004 at 09:30:59PM +1300, Tim Sutherland wrote: > [...] > > The first set of numbers is from my head and may be a wrong: > > my bridge was getting ~500 calls per second, the other two were a bit > > faster, maybe 800 or 1500. > [...] > > And now for the nice numbers... > > > > Using Hashtable with Equals: ~86,000 calls per second. > > Using GCHandle: ~58,000 calls per second. > [...] > > I think Thomas' was around 5000 or so calls per second. It was > definitely the best (because of the other bridges' Hashtable problem). > But even that bridge can probably be made 10x faster or more pretty > easily, as shown by my second set of results. I checked my actual numbers... I ran each program with whatever number of iterations made it run in around 10 seconds. Then I repeated with twice as many iterations, expecting around 20 seconds. (This was not always the case.) My original bridge was getting between 445 and 888 calls per second. (It varied a lot depending on the number of iterations, for gc reasons?) Adding in ``lazy DotNet::Instance initialisation'' actually made it slower, between 258 and 409 calls per second. This surprised me since the things we're avoiding initialising are never actually used by the benchmark. I think it's changing the gc somehow... When I added some debugging to print out around 20,000 lines, the bridge was about twice as fast. Again, gc reasons I think, with the linearity of the hashtable lookups. Changing the Hashtable to use Equals instead of == resulted in 21,000 calls per second. Adding in lazyness gave 47,000. Using GCHandles, but not lazy: 26,000 calls per second Using GCHandle, and also lazy: 60,000 calls per second (So GCHandles are actually faster, contrary to my previous post.) [Hopefully I won't have to followup quickly to this post!] |
|
From: Tim S. <ti...@ih...> - 2004-10-29 09:37:02
|
On Fri, Oct 29, 2004 at 09:30:59PM +1300, Tim Sutherland wrote: [...] > The first set of numbers is from my head and may be a wrong: > my bridge was getting ~500 calls per second, the other two were a bit > faster, maybe 800 or 1500. [...] > And now for the nice numbers... > > Using Hashtable with Equals: ~86,000 calls per second. > Using GCHandle: ~58,000 calls per second. [...] I think Thomas' was around 5000 or so calls per second. It was definitely the best (because of the other bridges' Hashtable problem). But even that bridge can probably be made 10x faster or more pretty easily, as shown by my second set of results. |
|
From: Tim S. <ti...@ih...> - 2004-10-29 08:31:12
|
I've done some performance tests.
- The bridges that SaltyPickle folks wrote, and the one I wrote, use a
Hashtable of ids.
- Thomas' bridge uses GCHandle.
The Hashtable bridges force pointer equality comparison with Object#==
rather than the default Object#Equals which can be overridden by
subclasses.
The reason we do this is that we think "if two objects happen to be the
same when they're created, and we give them the same id, then one is
mutated the other will also be mutated. That would be bad."
Now imagine what happens when you do
require 'dotnet'
r = DotNet.new('somestring')
1_000_000.times {
r.ToUpper
}
Each string returned by ToUpper() has a different pointer, so is
different wrt Object#==. But GetHashCode() returns the same value for
each!
This makes our Hashtable lookup linear instead of constant. So many
collisions.
Of course some of these values will be garbage collected as we go along,
but my tests showed we have up to several thousand strings in the
Hashtable at once. (It cycles small ... thousand .. small etc. as the gc
is invoked.)
This makes performance baaad.
One solution is to recognise that strings (and integers and ...) are not
mutable, so do a special case for strings - use Equals in that case.
A better solution is to note that the implementation of Equals in
standard .NET classes is always == for mutable objects. (I think...)
Therefore Equals should always be used by the hashtable.
Alternatively, use GCHandle like Thomas did. The nice thing about this
is it makes handling garbage collection very easy. Simply have the Ruby
free function for the proxy object call GCHandle.Free().
Hashtable with Equals can actually perform about 1.5 times the speed of
using GCHandles in the artificial benchmark above. (Where we're getting
the same value returned over and over again.)
And now for some numbers...
The first set of numbers is from my head and may be a wrong:
my bridge was getting ~500 calls per second, the other two were a bit
faster, maybe 800 or 1500.
I made two changes to my bridge:
1) Made some things in my DotNet::Instance initialisation "lazy".
(Getting FullName, AssemblyID, creating DotNet::Class.) A big win since
the above example was never calling the result of `r.ToUpper'.
2) The Hashtable change. Either to use Equals or GCHandle.
And now for the nice numbers...
Using Hashtable with Equals: ~86,000 calls per second.
Using GCHandle: ~58,000 calls per second.
I actually think GCHandle is better because
- Simpler to code
- This benchmark is in someways the best case for Hashtable with
Equals. I suspect GCHandle will perform better on average in real
life.
|
|
From: Thomas S. <th...@th...> - 2004-08-03 09:54:14
|
Sounds excellent! In other good news it appears that Jim Hugunin, the IronPython guy, has been hired by Microsoft to continue his work on IronPython and on the CLS/CLR/CTS-and-so-on with emphasis on it's use as a platform for execution of dynamic languages. br, Thomas On Tue, 2004-08-03 at 10:35, Tim Sutherland wrote: > Hi guys, > > Microsoft are running their "TechEd" conference in Auckland, NZ (where I > live) this week. > > I managed to beg my way into a session to do with 'low-level CLR stuff'. > They mentioned that they're considering adding a dynamic dispatch > instruction to IL to aid the compilation of dynamic languages for their > platform. That would be useful for a Ruby->IL compiler. > > Hopefully this would mean that if some C# code calls a method on a type > that has been declared 'dynamic' and the method has not already > been declared, the C# compiler will use 'dynamic_call'. |
|
From: Tim S. <ti...@ih...> - 2004-08-03 08:35:27
|
Hi guys, Microsoft are running their "TechEd" conference in Auckland, NZ (where I live) this week. I managed to beg my way into a session to do with 'low-level CLR stuff'. They mentioned that they're considering adding a dynamic dispatch instruction to IL to aid the compilation of dynamic languages for their platform. That would be useful for a Ruby->IL compiler. Hopefully this would mean that if some C# code calls a method on a type that has been declared 'dynamic' and the method has not already been declared, the C# compiler will use 'dynamic_call'. -- Tim Sutherland <ti...@ih...> 2004 President of SDKACM, the Software Developers' Klub Incorporated. This is the University of Auckland ACM Student Chapter and is AUSA affiliated. See http://www.sdkacm.com/ for information and resources. |
|
From: Rodrigo B. de O. <rb...@ac...> - 2004-07-01 11:52:58
|
----- Original Message ----- From: "Ron Jeffries" <ron...@ac...> > ... > ... > What does a person using Ruby with .NET really want and need? > Pretty much what you've already said, Ron, I'm just throwing one more vote: being able to consume and produce cli components with ruby like syntax and semantics. The syntactic part is somewhat easy but implementing the full ruby semantics in a way that still allows one to write .net consumable classes seems a bit hard. The approach I have used in boo (http://boo.codehaus.org/) was to drop the hard-to-mix-with-cli semantics in favor of a more tight integration with the type system. The type inference mechanism (still maturing) gives one the scripting feeling of a lighter syntax although most of the dynamic semantics are lost: import System.IO for line in File.OpenText("albatros.txt"): print(line) if line =~ /^Man/ While I'm pretty much happy with that I don't think most rubysts and pythonists for that matter are willing to give up the truly dynamic nature of their programming languages. Regards, Rodrigo |
|
From: Ron J. <ron...@ac...> - 2004-07-01 11:17:05
|
On Wednesday, June 30, 2004, at 11:48:18 PM, Tim Sutherland wrote: > On Wed, Jun 30, 2004 at 09:56:51AM -0400, Richard Kilmer wrote: >> You may want to contact Robert Feldt: <fe...@ce...> (I Cc'd him on >> this message). >> >> He has students working on a Ruby to CIL compiler (from his ruby-talk post): >> > [...] >> http://www.pronovomundo.com/htu/theses2004/ >> >> Jan-?ke Hedstr?m, "RubySharp ? A Ruby to CIL Compiler" > [...] >> This paper describes the development of RubySharp, a proof-of-concept >> compiler. It is able to compile a subset of features from the dynamic >> programming language Ruby into CIL (Common Intermediate Language), > [...] >> On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...> >> wrote: >> I think the most interesting project in this realm is IronPython. Rather >> than bridging it is a rewrite of Python targetting IL. I don't think it >> is available yet, but you could google for it and get in contact with >> the author for details. Fundamentally he (IronPython) has the right idea >> - bridging anything to the current ruby runtime will remain mostly a >> hack, because I don't think you will be able to satisfactorily solve at >> least the following fundamental problems >> >> 1) The dual-gc problem, >> 2) The ruby pseudo-threading versus .net native threading problem > [...] > Thanks to both of you for your comments. > The concern I have with dropping the current Ruby runtime entirely is > that then you're no longer dealing with Ruby, but instead have 'the > subset of Ruby that is currently supported by this .NET > compiler/interpreter'. > It would be interesting to combine a CIL compiler with the Ruby runtime > so we gain performance and integration when dealing with .NET stuff but can > also use normal Ruby code. I will certainly read the RubySharp paper. > A large part of my project will be considering what other people have > already done in this area, both by the people on this list and by projects > for other languages and systems. (e.g. Ruby and Python on Java projects.) I don't have an answer to the question I'm about to ask, but the question is this: What does a person using Ruby with .NET really want and need? Let me riff on that a bit. One might just need Ruby. If I just want to script some .NET programs with Ruby, it probably works fine as it is. Start programs, read and write files, no big deal. Probably not a project lurking there. Or, one might want to program in Ruby, mixing and matching with .NET programs and libraries in the "same way" one can mix C# and VB programs. (At least with managed programs, let's say.) Now here it gets interesting. There are in fact probably things that are in real Ruby that are "inappropriate" if one's doing a Ruby.NET. Very likely, almost everything should work the way it works in .NET, not the way it works in Ruby. Files and directories should use the .NET facilities. (This could be very important with upcoming changes to the file system in future versions of Windows.) Strings should use and work on .NET strings. This would come down to Ruby syntax, compiling to IL, running against the real .NET libraries, and -- I suppose -- producing libraries that can be used from other .NET languages. Thinking this way, I imagine that I might want to have .rb source files open in Visual Studio, the same way I have .cs or .vb files open. Build the app, they compile and build just like anything else. A real live compatible Ruby. A hard project but from some viewpoints, the only one. I don't mean that to be the answer to my question of what we want and need, but it might be ONE answer. Regards, Ron Jeffries www.XProgramming.com Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. --Albert Einstein |
|
From: Tim S. <ti...@ih...> - 2004-07-01 03:48:22
|
On Wed, Jun 30, 2004 at 09:56:51AM -0400, Richard Kilmer wrote: > You may want to contact Robert Feldt: <fe...@ce...> (I Cc'd him on > this message). > > He has students working on a Ruby to CIL compiler (from his ruby-talk post): > [...] > http://www.pronovomundo.com/htu/theses2004/ > > Jan-?ke Hedstr?m, "RubySharp ? A Ruby to CIL Compiler" [...] > This paper describes the development of RubySharp, a proof-of-concept > compiler. It is able to compile a subset of features from the dynamic > programming language Ruby into CIL (Common Intermediate Language), [...] > On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...> > wrote: > I think the most interesting project in this realm is IronPython. Rather > than bridging it is a rewrite of Python targetting IL. I don't think it > is available yet, but you could google for it and get in contact with > the author for details. Fundamentally he (IronPython) has the right idea > - bridging anything to the current ruby runtime will remain mostly a > hack, because I don't think you will be able to satisfactorily solve at > least the following fundamental problems > > 1) The dual-gc problem, > 2) The ruby pseudo-threading versus .net native threading problem [...] Thanks to both of you for your comments. The concern I have with dropping the current Ruby runtime entirely is that then you're no longer dealing with Ruby, but instead have 'the subset of Ruby that is currently supported by this .NET compiler/interpreter'. It would be interesting to combine a CIL compiler with the Ruby runtime so we gain performance and integration when dealing with .NET stuff but can also use normal Ruby code. I will certainly read the RubySharp paper. A large part of my project will be considering what other people have already done in this area, both by the people on this list and by projects for other languages and systems. (e.g. Ruby and Python on Java projects.) -- Tim Sutherland <ti...@ih...> 2004 President of SDKACM, the Software Developers' Klub Incorporated. This is the University of Auckland ACM Student Chapter and is AUSA affiliated. See http://www.sdkacm.com/ for information and resources. |
|
From: Richard K. <ri...@in...> - 2004-06-30 13:57:03
|
You may want to contact Robert Feldt: <fe...@ce...> (I Cc'd him on this message). He has students working on a Ruby to CIL compiler (from his ruby-talk post)= : =3D=3D original message =3D=3D Hi, I created a web page for the theses of the student projects I have talked about on the list during the last couple of months. Not all pdf are up yet but hopefully I'll have the time to add them before going on a 3-week vacation (with no/little Internet connection!) tomorrow. Feedback and comments appreciated. http://www.pronovomundo.com/htu/theses2004/ Jan-=C5ke Hedstr=F6m, "RubySharp =AD A Ruby to CIL Compiler" This paper describes the development of RubySharp, a proof-of-concept compiler. It is able to compile a subset of features from the dynamic programming language Ruby into CIL (Common Intermediate Language), which is a static assembler intermediate language in the .NET platform. The language constructs of Ruby and CIL are examined to see what similarities and differences that exist. To be able to support the correct Ruby behaviour in all compiled programs, a class hierarchy is developed for RubySharp. Additionally, basic goal programs are defined in Ruby and in CIL, forming a specification for the RubySharp compiler on how to compile the goal programs. Furthermore, other Ruby language constructs, besides these introduced by the goal programs, are also examined to see if and how they can be implemented on the .NET platform. =3D=3D clip MorphR stuff =3D=3D -Rich On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...> wrote: > Hi Tim, >=20 > I think the most interesting project in this realm is IronPython. Rather > than bridging it is a rewrite of Python targetting IL. I don't think it > is available yet, but you could google for it and get in contact with > the author for details. Fundamentally he (IronPython) has the right idea > - bridging anything to the current ruby runtime will remain mostly a > hack, because I don't think you will be able to satisfactorily solve at > least the following fundamental problems >=20 > 1) The dual-gc problem, > 2) The ruby pseudo-threading versus .net native threading problem >=20 > Furthermore, I think embedding a ruby interpreter in a .net application > would be a killer feature, and while it can be done, the ruby > interpreter is not reentrant. >=20 > So I think the best solution would be to ditch the ruby interpreter > alltogether and follow the same path as IronPython. I exchanged a few > emails with the IronPython author and as far as I recall he would like > to target other dynamic languages than Python in the future, if he has > the time. Maybe he would be interested in helping out a student project, > who knows? >=20 > Thomas >=20 > On Wed, 2004-06-30 at 06:55, Tim Sutherland wrote: >> Hi everyone. For those of you who've forgotten, I wrote the >> "rubydotnetproxy" library which allows Ruby to call .NET methods and >> vice versa. Several other people/groups wrote similar things, some of >> which supported more features than mind (e.g. a Ruby class can >> implement a .NET interface). >>=20 >> A couple of months ago I said I was going to port my code to Mono, spent >> one weekend working on it and then didn't have time to do any more work >> on it! >>=20 >> I'm an undergraduate student (University of Auckland), and I'm trying to >> decide what courses to do next semester (which starts in a few weeks). >> One of my options is an "Undergraduate Project in Computer Science". >>=20 >> I'd like to do a project about integrating Ruby and .NET. A semester >> lasts 12 weeks. (19 Jul 2004 to 23rd October 2004.) >>=20 >> In trying to be a good scientist, I would spend a lot of time looking at >> what other people have done (in Ruby, as well as other dynamic >> languages) and adapt/use their code/ideas. For example, I could use >> someone elses code and add features or improve the implementation. (e.g. >> considering different ways of implementing certain features). >>=20 >>=20 >> So my questions to you guys: >>=20 >> What is currently missing or undeveloped in the current Ruby-.NET >> bridging libraries? In my opinion: >>=20 >> 1) Mono support. This is important to me, since at home I only use >> Linux. I wouldn't want to just abandon my work at the end of the >> semester, so it would have to be runnable on Linux so that I remain >> motivated. >>=20 >> 2) Threading support. Dealing with the differences between threads in >> .NET and in Ruby is hard. >>=20 >> 3) Speed. There are some simple things (at least with my library) that >> can be done to improve speed. e.g. my library used Type#InvokeMember >> each time a .NET method was called from Ruby. Instead of that, the first >> time we call a .NET method we could use Type#GetMember (or whatever it's >> called) and subsequently used the cached result. >>=20 >> Potentially there are a bunch of low-level things that can be done as >> well. I'd have to become more familiar with the way .NET works (CLR >> stuff). >>=20 >>=20 >> 4) ??? >>=20 >>=20 >> As far as licensing goes, any code I write would be released under a >> license that's compatible with Ruby's. This whole scheme could come >> unstuck if my University won't agree to that, but hopefully I can >> negotiate with them. >>=20 >> With reusing code, I believe that while there are several different >> projects approaching this problem, the amount of code in each is not >> large. On the other hand, the code is very "dense", i.e. the code uses >> fairly complicated ideas and there are plenty of fairly subtle issues. >>=20 >> I suspect that it is less important whether or not I re-use actual code >> (though I will attempt to do this where possible) than that I re-use >> (steal) ideas from the implementations. >>=20 >> I think the best approach would be to take an existing implementation >> and then extend it, since then both the original authors and myself >> would be "supporting/promoting" the code. >>=20 >> The result of my project will be >> 1) Some code. >> 2) A written report on what I have learned. >>=20 >> (2) is going to be more important than (1), since everyone will be able >> to use the ideas for their own implementations, and it will be useful to >> people developing bridges in dynamic languages other than Ruby too. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Rubydotnet-developer mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubydotnet-developer >=20 |
|
From: Thomas S. <th...@th...> - 2004-06-30 07:50:42
|
Hi Tim, I think the most interesting project in this realm is IronPython. Rather than bridging it is a rewrite of Python targetting IL. I don't think it is available yet, but you could google for it and get in contact with the author for details. Fundamentally he (IronPython) has the right idea - bridging anything to the current ruby runtime will remain mostly a hack, because I don't think you will be able to satisfactorily solve at least the following fundamental problems 1) The dual-gc problem, 2) The ruby pseudo-threading versus .net native threading problem Furthermore, I think embedding a ruby interpreter in a .net application would be a killer feature, and while it can be done, the ruby interpreter is not reentrant. So I think the best solution would be to ditch the ruby interpreter alltogether and follow the same path as IronPython. I exchanged a few emails with the IronPython author and as far as I recall he would like to target other dynamic languages than Python in the future, if he has the time. Maybe he would be interested in helping out a student project, who knows? Thomas On Wed, 2004-06-30 at 06:55, Tim Sutherland wrote: > Hi everyone. For those of you who've forgotten, I wrote the > "rubydotnetproxy" library which allows Ruby to call .NET methods and > vice versa. Several other people/groups wrote similar things, some of > which supported more features than mind (e.g. a Ruby class can > implement a .NET interface). > > A couple of months ago I said I was going to port my code to Mono, spent > one weekend working on it and then didn't have time to do any more work > on it! > > I'm an undergraduate student (University of Auckland), and I'm trying to > decide what courses to do next semester (which starts in a few weeks). > One of my options is an "Undergraduate Project in Computer Science". > > I'd like to do a project about integrating Ruby and .NET. A semester > lasts 12 weeks. (19 Jul 2004 to 23rd October 2004.) > > In trying to be a good scientist, I would spend a lot of time looking at > what other people have done (in Ruby, as well as other dynamic > languages) and adapt/use their code/ideas. For example, I could use > someone elses code and add features or improve the implementation. (e.g. > considering different ways of implementing certain features). > > > So my questions to you guys: > > What is currently missing or undeveloped in the current Ruby-.NET > bridging libraries? In my opinion: > > 1) Mono support. This is important to me, since at home I only use > Linux. I wouldn't want to just abandon my work at the end of the > semester, so it would have to be runnable on Linux so that I remain > motivated. > > 2) Threading support. Dealing with the differences between threads in > .NET and in Ruby is hard. > > 3) Speed. There are some simple things (at least with my library) that > can be done to improve speed. e.g. my library used Type#InvokeMember > each time a .NET method was called from Ruby. Instead of that, the first > time we call a .NET method we could use Type#GetMember (or whatever it's > called) and subsequently used the cached result. > > Potentially there are a bunch of low-level things that can be done as > well. I'd have to become more familiar with the way .NET works (CLR > stuff). > > > 4) ??? > > > As far as licensing goes, any code I write would be released under a > license that's compatible with Ruby's. This whole scheme could come > unstuck if my University won't agree to that, but hopefully I can > negotiate with them. > > With reusing code, I believe that while there are several different > projects approaching this problem, the amount of code in each is not > large. On the other hand, the code is very "dense", i.e. the code uses > fairly complicated ideas and there are plenty of fairly subtle issues. > > I suspect that it is less important whether or not I re-use actual code > (though I will attempt to do this where possible) than that I re-use > (steal) ideas from the implementations. > > I think the best approach would be to take an existing implementation > and then extend it, since then both the original authors and myself > would be "supporting/promoting" the code. > > The result of my project will be > 1) Some code. > 2) A written report on what I have learned. > > (2) is going to be more important than (1), since everyone will be able > to use the ideas for their own implementations, and it will be useful to > people developing bridges in dynamic languages other than Ruby too. |
|
From: Tim S. <ti...@ih...> - 2004-06-30 04:55:59
|
Hi everyone. For those of you who've forgotten, I wrote the "rubydotnetproxy" library which allows Ruby to call .NET methods and vice versa. Several other people/groups wrote similar things, some of which supported more features than mind (e.g. a Ruby class can implement a .NET interface). A couple of months ago I said I was going to port my code to Mono, spent one weekend working on it and then didn't have time to do any more work on it! I'm an undergraduate student (University of Auckland), and I'm trying to decide what courses to do next semester (which starts in a few weeks). One of my options is an "Undergraduate Project in Computer Science". I'd like to do a project about integrating Ruby and .NET. A semester lasts 12 weeks. (19 Jul 2004 to 23rd October 2004.) In trying to be a good scientist, I would spend a lot of time looking at what other people have done (in Ruby, as well as other dynamic languages) and adapt/use their code/ideas. For example, I could use someone elses code and add features or improve the implementation. (e.g. considering different ways of implementing certain features). So my questions to you guys: What is currently missing or undeveloped in the current Ruby-.NET bridging libraries? In my opinion: 1) Mono support. This is important to me, since at home I only use Linux. I wouldn't want to just abandon my work at the end of the semester, so it would have to be runnable on Linux so that I remain motivated. 2) Threading support. Dealing with the differences between threads in .NET and in Ruby is hard. 3) Speed. There are some simple things (at least with my library) that can be done to improve speed. e.g. my library used Type#InvokeMember each time a .NET method was called from Ruby. Instead of that, the first time we call a .NET method we could use Type#GetMember (or whatever it's called) and subsequently used the cached result. Potentially there are a bunch of low-level things that can be done as well. I'd have to become more familiar with the way .NET works (CLR stuff). 4) ??? As far as licensing goes, any code I write would be released under a license that's compatible with Ruby's. This whole scheme could come unstuck if my University won't agree to that, but hopefully I can negotiate with them. With reusing code, I believe that while there are several different projects approaching this problem, the amount of code in each is not large. On the other hand, the code is very "dense", i.e. the code uses fairly complicated ideas and there are plenty of fairly subtle issues. I suspect that it is less important whether or not I re-use actual code (though I will attempt to do this where possible) than that I re-use (steal) ideas from the implementations. I think the best approach would be to take an existing implementation and then extend it, since then both the original authors and myself would be "supporting/promoting" the code. The result of my project will be 1) Some code. 2) A written report on what I have learned. (2) is going to be more important than (1), since everyone will be able to use the ideas for their own implementations, and it will be useful to people developing bridges in dynamic languages other than Ruby too. -- Tim Sutherland <ti...@ih...> 2004 President of SDKACM, the Software Developers' Klub Incorporated. This is the University of Auckland ACM Student Chapter and is AUSA affiliated. See http://www.sdkacm.com/ for information and resources. |
|
From: <ben...@id...> - 2004-05-22 12:25:33
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Curt H. <cu...@hi...> - 2004-04-16 12:32:28
|
Tim Sutherland wrote: > > FYI, I'm (attempting) to port rubydotnetproxy > (http://rubydotnetproxy.rubyforge.org/) to Mono. Very cool! I haven't had time to get into this yet, but I can see it sometime in my future. Anyway, I just wanted to let you know that your ground-breaking work is appreciated. Curt |
|
From: Tim S. <ti...@ih...> - 2004-04-16 05:25:41
|
FYI, I'm (attempting) to port rubydotnetproxy (http://rubydotnetproxy.rubyforge.org/) to Mono. So far, I get it to run and pass all my test cases (for Ruby calling .NET anyway) if I turn Ruby garbage collection off :-) [otherwise it crashes] The main problem is dealing with some differences between Microsoft and Mono implementations of libraries and I had to make a few changes to Mono to get it to work. (I'll send patches to Mono people later.) Just letting you guys know in case someone else is working with Mono and we run into the same bugs. A non-mono issue I noticed is that in .NET, sometimes the type of a variable is important when calling methods, as well as the type of the object. e.g. interface A {} interface B {} class C : A, B {} class Foo { public static string hello(A a) { return "A"; } public static string hello(B b) { return "B"; } } // ... C c = new C(); A a = c; B b = c; Foo.hello(a); // "A" Foo.hello(b); // "B" Foo.hello(c); // wouldn't compile Hence we need a "cast" interface. I plan to add one called something like "cast_to" so you can do e.g. c = C.new Foo.hello(c.cast_to(A)) This should be easy to do since my implementation of DotNet::Instance has a type_id and instance_id for each instance, so I will just need to make a new instance with a different type_id. -- Tim Sutherland <ti...@ih...> 2004 President of SDKACM, the Software Developers' Klub Incorporated. This is the University of Auckland ACM Student Chapter and is AUSA affiliated. See http://www.sdkacm.com/ for information and resources. |
|
From: Tim S. <ti...@ih...> - 2004-01-13 01:10:35
|
On Mon, Jan 12, 2004 at 01:32:58PM +0100, Thomas Sondergaard wrote: > I don't really understand how reference counting is error prone? Speaking > for my own implementation I use a System.Runtime.InteropServices.GCHandle in > the ruby-proxy-object to keep the .net object reference. The GCHandle > mechanism is a reference counting scheme for referencing .net objects > outside of the .net runtime. Similary, I use rb_gc_register_address in > the .net-proxy constructor to tell ruby that there is an external reference > to that object. I don't see any significant potential for forgetting to > update the reference count, the major problem is the circular references > problem. [...] Okay, I was exaggerating :) Reference counting was working perfectly well for me too. The hard part is avoiding race conditions with the garbage collector(s) [System.GC.KeepAlive etc.], and my idea doesn't help with this. However, when I was using reference counting I had (for Ruby calling .NET) about 7 C# methods which would increase a reference count and return an OBJ. It was assumed that the C code would store this in a struct DotNetData and decrease the reference count when freed. I didn't like that these methods depended on their callers to do the right thing. -- The pigeonhole principle: If you have N pigeons and drill at least N + 1 holes in them, you will have at least one pigeon with at least two holes in it. |
|
From: Thomas S. <th...@th...> - 2004-01-12 12:33:03
|
I don't really understand how reference counting is error prone? Speaking for my own implementation I use a System.Runtime.InteropServices.GCHandle in the ruby-proxy-object to keep the .net object reference. The GCHandle mechanism is a reference counting scheme for referencing .net objects outside of the .net runtime. Similary, I use rb_gc_register_address in the .net-proxy constructor to tell ruby that there is an external reference to that object. I don't see any significant potential for forgetting to update the reference count, the major problem is the circular references problem. Cheers, Thomas ---------- Original Message ----------- From: Tim Sutherland <ti...@ih...> To: rub...@li... Sent: Fri, 9 Jan 2004 00:40:10 +1300 Subject: [Rubydotnet-developer] GC ideas > Hello. I changed the way I deal with the GC in my rubydotnetproxy > object. (I haven't uploaded a version using these new changes.) > > I was previously using reference counting[*]. This was error prone > and ugly. (It was not easy to be sure that I hadn't made a mistake > somewhere.) > > [*] This would all be easy if I had a rule like "for each VALUE, > there is at most one RbType wrapping it", but then I couldn't use implicit > constructors for type conversions. > > Now for .NET calling Ruby: > In .NET I have a collection of weakreferences of RbTypes. (I add > to it whenever a RbType is constructed.) > > Whenever Ruby's GC is running, I call rb_gc_mark for each VALUE > where the RbType has not yet been collected. (And remove those > which have been collected.) > > In this way, as long as .NET has access to the RbType, Ruby will > not collect the associated VALUE. > > For Ruby calling .NET > In .NET I have a hashtable from .NET OBJ id => object. > > Roughly as often as the .NET GC is run, I create a C array of > OBJs, assign it to a global variable and then rb_gc_start(). > > My mark_DotNetData() function adds its type_id/instance_id to > the array. > > Then I pass this array to .NET and it removes all objects from > the hashtable whose ids don't appear in the array. > > This still suffers from the circular references memory leak that > reference counting had. > > BTW: I saw (on a webpage somewhere? I seem to recall it was Thomas') > someone say they added a feature to allow you to do things like the > following Ruby > require 'dotnet' > > class Foo > end > foo = Foo.new > > h = Hashtable.new > h[foo] = 12345 > > i.e. have arbitrary Ruby objects as arguments to .NET methods by > wrapping them up as `.NET wrapper around Ruby object` and unwrapping > on the other end. > > This seems like a really great idea. It does raise issues like > "should we still convert arguments which are Ruby strings into .NET strings > automatically. Similarly for integers etc. > > -- > Q: What is normed, complete, and yellow? > A: A Bananach space... > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System > offering advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Rubydotnet-developer mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubydotnet-developer ------- End of Original Message ------- |
|
From: Tim S. <ti...@ih...> - 2004-01-08 11:40:10
|
Hello. I changed the way I deal with the GC in my rubydotnetproxy object. (I haven't uploaded a version using these new changes.) I was previously using reference counting[*]. This was error prone and ugly. (It was not easy to be sure that I hadn't made a mistake somewhere.) [*] This would all be easy if I had a rule like "for each VALUE, there is at most one RbType wrapping it", but then I couldn't use implicit constructors for type conversions. Now for .NET calling Ruby: In .NET I have a collection of weakreferences of RbTypes. (I add to it whenever a RbType is constructed.) Whenever Ruby's GC is running, I call rb_gc_mark for each VALUE where the RbType has not yet been collected. (And remove those which have been collected.) In this way, as long as .NET has access to the RbType, Ruby will not collect the associated VALUE. For Ruby calling .NET In .NET I have a hashtable from .NET OBJ id => object. Roughly as often as the .NET GC is run, I create a C array of OBJs, assign it to a global variable and then rb_gc_start(). My mark_DotNetData() function adds its type_id/instance_id to the array. Then I pass this array to .NET and it removes all objects from the hashtable whose ids don't appear in the array. This still suffers from the circular references memory leak that reference counting had. BTW: I saw (on a webpage somewhere? I seem to recall it was Thomas') someone say they added a feature to allow you to do things like the following Ruby require 'dotnet' class Foo end foo = Foo.new h = Hashtable.new h[foo] = 12345 i.e. have arbitrary Ruby objects as arguments to .NET methods by wrapping them up as `.NET wrapper around Ruby object` and unwrapping on the other end. This seems like a really great idea. It does raise issues like "should we still convert arguments which are Ruby strings into .NET strings automatically. Similarly for integers etc. -- Q: What is normed, complete, and yellow? A: A Bananach space... |
|
From: Tim S. <ti...@ih...> - 2004-01-08 11:02:59
|
On Wed, Oct 08, 2003 at 04:31:17PM +0200, Thomas Sondergaard wrote: [...] > Nothing much has happened on my end. I have started porting my extension > to use C# with P/Invoke instead of C++ with managed extensions so it > will be easier to port between Microsoft, Mono and dotgnu. I am > currently trying to figure out how safe it is to use P/Invoke with the > ruby API. I am especially concerned about the ruby garbage collector, so > I am trying to understand how it works. [...] Sorry for replying so late to this thread... I believe[*] that if a C function returns a char* and you tell .NET that it returns a string, .NET takes responsibility for freeing the buffer. This is bad if the char* was an RSTRING(s)->ptr. Instead, have it return a System.IntPtr and then use string s = System.Runtime.InteropServices.Marshal.PtrToStringAnsi(ptr); Similar issues exist with other types. [*] This is my interpretation of the .NET documentation. |
|
From: Tim S. <ti...@ih...> - 2004-01-05 08:20:06
|
On Mon, Jan 05, 2004 at 07:50:16PM +1300, Tim Sutherland wrote: > If anyone's interested, I've put my rubydotnetproxy library at > http://rubydotnetproxy.rubyforge.org/ > > I've only used it for simple things so far, but we plan to use it at > work for an upcoming project. NB: As I've mentioned previously (some time ago!), I'm not planning to add new features to my library - it already does everything I want. |
|
From: Tim S. <ti...@ih...> - 2004-01-05 06:50:20
|
If anyone's interested, I've put my rubydotnetproxy library at http://rubydotnetproxy.rubyforge.org/ I've only used it for simple things so far, but we plan to use it at work for an upcoming project. -- Q: Why didn't Newton discover group theory? A: Because he wasn't Abel. |
|
From: Thomas S. <th...@th...> - 2003-10-08 14:32:14
|
Hey, Nothing much has happened on my end. I have started porting my extension to use C# with P/Invoke instead of C++ with managed extensions so it will be easier to port between Microsoft, Mono and dotgnu. I am currently trying to figure out how safe it is to use P/Invoke with the ruby API. I am especially concerned about the ruby garbage collector, so I am trying to understand how it works. other than that it will be an interesting experiment because P/Invoke has more overhead than IJW/Managed C++. When I'm done we could do a performance comparison and see whether the P/Invoke approach is too expensive or whether it is worthwhile for the portability benefits. Other than that, I won't be doing much work on rubydotnet for the next three weeks at least, as I am changing jobs. If anyone wants to chip in, all help is welcome. Cheers, Thomas |
|
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: 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: 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: 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 |