tag:blogger.com,1999:blog-20975090.post6896643541998081632..comments2024-03-11T10:18:55.852-05:00Comments on Headius: What Would I (Will I?) Change About RubyCharles Oliver Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-20975090.post-66237602564713923092007-07-24T14:37:00.000-05:002007-07-24T14:37:00.000-05:00I really hope you are not suggesting implementing ...I really hope you are not suggesting implementing something like the JCP in the legal entity proposal? <BR/><BR/>It's current implementation for Java is totally flawed, only allowing major corporations with lots of moola invested in enterprise Java getting a say in anything significant. The JCP only listens to non-real-world-developers. They are either "computer scientist" types who do not work in the enterprise (nor do they deliver systems to production and support them either) or they sell enterprise Java products to large corporations (where only usage of buzz words in the appropriate space is the technical requirement). Neither of which represent the real world developers out there that need to use Java in production business systems and it has shown a lot in the last 5 years!<BR/><BR/>Therefore I hope your "legal entity" suggestion does not encompass the "committee" nightmare created by Sun's JCP, because if we enter into such an idea with the notion that JCP actually works then we will fail miserably like Java.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-73345498737417669022007-06-07T01:19:00.000-05:002007-06-07T01:19:00.000-05:00ObjectSpace.each_object(Module) { |module| ... }I ...ObjectSpace.each_object(Module) { |module| ... }<BR/><BR/>I find myself using the above to locate all subclasses of a particular class on a fairly regular basis. I would love to have a more efficient alternative, but I'm not willing to rely on mechanisms that force the programmer to write extra code to register a reference to the subclass with the parent class. That will inevitably lead to bugs when the programmer forgets to add the registration code. I can't even begin to say how much I want a Module#descendants method built into Ruby.Unknownhttps://www.blogger.com/profile/17558670616626618259noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-24025946455902177602007-05-08T11:28:00.000-05:002007-05-08T11:28:00.000-05:00I haven't used ObjectSpace much and maybe I am mis...I haven't used ObjectSpace much and maybe I am mistaken, but I really like it because it provides some of the same power that Smalltalk's browse instances of, etc.<BR/><BR/>Sure this stuff could be duplicated in an IDE or another library, but it would be a shame to move away from a rich introspective dynamic language, just for the sake of removing overhead and performance gains. Ruby doesn't have a spec, but ObjectSpace belongs in it.<BR/><BR/>I think the more you change Ruby, the more "outside" the Ruby community you will be.<BR/><BR/>Thanks for all the excellent work you are doing with jruby.Austinhttps://www.blogger.com/profile/17907770218961186024noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-43693479471261069732007-05-01T14:40:00.000-05:002007-05-01T14:40:00.000-05:00For ObjectSpace, I've wondered how much of the sam...For ObjectSpace, I've wondered how much of the same feature set is available in Java 6 with its cool heap information. Any way to tap into this (even with JNI?) to provide cheaper ObjectSpace on Java 6 plus? Even if just meant for debugging purposes?<BR/><BR/>For thread killing, I know less safe ways of killing threads like for instance power outages. To the extent I understand it, I don't see the huge trouble with kill/raise. (The whole "critical" thing, however, seems scary.)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-63005265809480240122007-04-29T06:00:00.000-05:002007-04-29T06:00:00.000-05:00Charles,Your statement "Sure, machines are 500 to ...Charles,<BR/><BR/>Your statement "Sure, machines are 500 to 2000 times faster...and we're doing at least that many times as much with them." is an awful big claim - please demonstrate this. I worked on minicomputers in the aerly days of my career in computing - 2 Mbytes of memory (true, there was no GUI involved), we ran (with multiple users) word processors, spreadsheets, databases, network services of various kinds, and various others kinds of apps. We still do the same today, some things are now much easier (such as processing and editing sound and images) to do. But for many people, the machines of today are "pretty" and not doing much more for them than was available 15 years ago. <BR/><BR/>Certainly, we can run systems on micros today that we once required supercomputers to do.<BR/><BR/>But as experience has shown (tracing the execution of code through system calls in MS software) much of what is done today ends up copying the same piece of information many many times before it is actually used, this is hideous in the case of strings.<BR/><BR/>Algorithms used are simple because they are easy to code and effiency is not looked at because the coding is more complicated (sorting is one area this happens). I have also seen coding that has ended up a complicated mess instead of thinking outside the box and finding the appropriate algorithm (example is using "don't cares" to simpify test cases where necessary).<BR/><BR/>There are all sorts of things that have happened that eat into this massive spead up we have that results in little actual gain.<BR/><BR/>Having introspection always on does not mean that it is always running, it only means that the needed information and links are available for inspection (which for garbage collected systems should already be there).<BR/><BR/>Your statement "And concurrency and live heap inspection do not mix" is also a biggie. Can you prove that this is always the case or is it only the case in the systems you work and play in. I am not saying that there might not be great difficulties in doing this but are you categorically sure that it can't be done or is being done now (say in some Erlang or its ilk).<BR/><BR/>Your statement "So would be full runtime profiling, tracking of all object creations and collections, logging every packet sent and the time it took, and tracing all user operations. But we don't do all those things all the time because we actually want our software to accomplish something" - I have used systems that provided runtime profiling and other than the slowdown due to I/O concerns with some implementations didn't add much time to the overall process (particularly those systems that provided large buffers and writing to disk). Tracking of object creations and deletions depend on the kind of language and garbage collector you use - again if this is a logging function that is implemented correctly (for the system at hand) may add little time to each creation deletion compared to the time taken up in other parts of the system which are not under your control. Tracing of user operations add very little to the operation of any system as compared to the reation time and thick time of a user is miniscule (I take you know what I mean here). Tracing and logging of communications packets is something that has been done for decades with little or no impact on the systems involved, processors have tended to keep ahead of the communications frequencies in use on networks. It has required smart design to do this to ensure that there is no impact but it is done.<BR/><BR/>All of the above takes thinking outside the box in many cases - cros fertilisation of different fields makes a big difference to solving these kinds of problems.<BR/><BR/><BR/><BR/>I hope you are not trying to say that all the machines you work on are running above 80% all the time. I personally have come across few machines (very few) that are doing something useful most of the time - this is why there is a default process that does nothing called the Idle Process (though some smart souls do use this to do long calculations like Pi).<BR/><BR/>Lastly, the fact that you seem to use interpreted or virtual machine languages in at least part of your work and play says (at least to me) that efficiency in the runtime is not one of your priorities all the time. If that is the case and I haven't misinterpreted you, then some of your complaints may well be based on inefficient implementations not on the actual facilities being supplied. <BR/><BR/>Your experience is different to mine and you have a right to your opinion as do I and others who fell different to either of us.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-6945473415377438212007-04-27T09:41:00.000-05:002007-04-27T09:41:00.000-05:00Great review of whats "wrong" with Ruby. I truly ...Great review of whats "wrong" with Ruby. <BR/>I truly love Ruby, but there are many aspects of the language which need to mature. <BR/><BR/>When I first learned Ruby, I quickly realized how limited its implementation of Threads is. For small scripts and other "one-off" work that we all do Threading doesn't matter, but Ruby's usage has quickly expanded beyond this. It's becoming a standard language for implementing large enterprise-level systems.<BR/><BR/>It is critical that the issues that you mention here are corrected in a thoughtful manner.Anonymoushttps://www.blogger.com/profile/08965081597001041836noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-39632140989747954072007-04-26T21:06:00.000-05:002007-04-26T21:06:00.000-05:00Bruce Rennie: You can certainly make that claim, b...Bruce Rennie: You can certainly make that claim, but making it too often about too many features eventually means your system spends more of its time supporting features you *might* use *someday* than actually getting work done. Sure, machines are 500 to 2000 times faster...and we're doing at least that many times as much with them. Moore's law has ended, and we're not able to do as much with the same individual cores as we'd like. That means scaling horizontally. That means concurrency. And concurrency and live heap inspection do not mix.<BR/><BR/>There's probably nothing I can say to convince you that these features are not worth the impact they have on performance and evolution of languages and systems. But if you want these features to survive, you need to do something to help make sure they're implemented "effectively". Try it yourself, see how easy it is to make many threads all create garbage, a few more clean it up, and allow heap inspection across the whole lot without crippling the system. Maybe I'm totally off base. Maybe I'm not.<BR/><BR/>Yes, live heap inspection is useful. So would be full runtime profiling, tracking of all object creations and collections, logging every packet sent and the time it took, and tracing all user operations. But we don't do all those things all the time because we actually want our software to accomplish something. Feel free to run on systems that leave those sorts of features on at runtime if they perform well enough for you. Feel free to run your systems in debug mode all the time, just in case you might want to query that runtime information on a whim. Me, I'd rather my machine's cycles are spent getting work done, and I'm willing to trade a little convenience to do it.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-14813675794498051832007-04-26T20:35:00.000-05:002007-04-26T20:35:00.000-05:00Charles,Allowing the introspection all the time wi...Charles,<BR/><BR/>Allowing the introspection all the time will only seriously affect the runtime performance if the implementation is not done correctly. <BR/><BR/>It is worth it (in my experience).<BR/><BR/>Let's take a reality check. Our machines today are 500 to 2000 times faster and bigger than they were 20 years ago. But what do we see today. Most of the performance effects are taken up by all the additional guff (gui, os etc) that doesn't really give us any more speed than 10 - 15 years ago (or more).<BR/><BR/>Having had of necessity to trace the execution path of various bits of code in the past in a Microsoft environment, it is obvious that much of the performance of many applications is caught up in system facilities and not our programs themselves.<BR/><BR/>When I first started out in the industry in the late 70's and early 80's, it was a common saying (an experience) that a mainframe would double in size but you are the user would get maybe 20% performance increase. That happened then and it happens now.<BR/><BR/>Leaving in the ability to do introspection should not kill your application if the implementation has been effectively done.<BR/><BR/>Bruce Rennie<BR/>(God's Own Country Downunder)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-74419378173028184612007-04-26T12:34:00.000-05:002007-04-26T12:34:00.000-05:00robert thau: Yes, they are already per-object, but...robert thau: Yes, they are already per-object, but you don't attach them to the object directly (which would be something like defining a finalize method on the type, for example), you tell the GC (via ObjectSpace): "Hey, run this code when this object gets collected". It's a subtle difference, but it's an important one.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-9250738169878701052007-04-26T11:16:00.000-05:002007-04-26T11:16:00.000-05:00Ummmm... as I read the docs on ObjectSpace#define_...Ummmm... as I read the docs on ObjectSpace#define_finalizer, Ruby finalizers already are per-object; it's just that the method that attaches them to an object happens to be part of the ObjectSpace module.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-40796265995721324742007-04-26T01:18:00.000-05:002007-04-26T01:18:00.000-05:00robert: Yes! Actually I've been trying to push the...robert: Yes! Actually I've been trying to push the RubyTests project on RubyForge as a home for wayward tests, and we've previously contributed all of JRuby's tests there as well. However I haven't managed to get buy-in from other testing projects or Ruby implementations yet, so it isn't worth us putting our tests permanently there. Perhaps if the community lobbied for more cooperation in this area?<BR/><BR/>robert thau: That's an interesting idea. Actually one obvious place ObjectSpace is used is to locate all TestCase implementations for running a unit test run. But that case and most of your example cases cold be done by using the "inherited" hook on module to record when a given class or module is extended. And you also mention finalizers; finalizers are useful at times, and I think they could remain useful...but I would rather see them registered at the object itself rather than at the heap, with the garbage collector executing finalizers on objects as needed. But this requires a more advanced garbage collection system than Ruby has at present, so it may not be suitable yet.<BR/><BR/>patrick mueller: agreed on all points except $SAFE. I doubt any serious security expert would recommend relying on safe, and I know I wouldn't trust it. The edges are not well-defined, there's absolutely no testing coverage to guarantee it works, and barely anyone knows how to use it right. As a result, most people who are in a position to need $SAFE shouldn't be using $SAFE anyway.<BR/><BR/>andrew law: you can join #jruby on freenode IRC, or you could contact the codehaus folks to see why you can't get on the lists. Otherwise, email me at charles.nutter@sun.com<BR/><BR/>anonymous: that's certainly true, but you've actually just made my point for me...having that information available at runtime all the time, i.e. being able to inspect the running heap, impacts execution *all the time*. Is that worth it? If you can make something run twice as fast by requiring that heap inspection and memory profiling be explicitly enabled, isn't that a better way to do things? Of course there's no perfect answer, and people seem to think that having runtime access to the heap is so powerfully useful that it should always be present. And then nobody uses it, except for debugging purposes. I say leave it off and only turn it on when you need to do debugging. It's not worth taking the performance and complexity hit all the time for functionality used 1% of the time.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-51371835587722887832007-04-25T18:40:00.000-05:002007-04-25T18:40:00.000-05:00Good Morning Charles,In regards to your comment po...Good Morning Charles,<BR/><BR/>In regards to your comment posted on Slava's Blog re his entry re your entry.<BR/><BR/>Both of you missed one truly painful problem with your idea of using external tools or setting of runtime switches to allow introspection of the heap -<BR/><BR/>It has the effect of altering the runtime characteristics of the erroneous program so that the particular error being investigated may be altered and hence may in fact disappear.<BR/><BR/>Reasoning: Historical attempts at doing this over many years in both mainframe and minicomputer environments has shown that (for myself and colleagues of mine) there are some errors that will be altered by changing the runtime characteristics of the program. This arises due to compiler and/or external runtime mmonitoring tools altering the program in question. <BR/><BR/>If the introspection tools are always incorporated into the runtime of the program, the base system will (in most situations) not change and the error should be repeatable and findable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-49316980080643975502007-04-25T18:33:00.000-05:002007-04-25T18:33:00.000-05:00PHP has some kind of a quasi-official governance g...<I>PHP has some kind of a quasi-official governance group (The PHP Group), but it's not as official as Apache or anything. On the other hand, governing bodies sound like committees, and I'm not sure you want to go there either. Benevolent dictators, when they work, work great.</I><BR/><BR/>Python's benevolent dictator is Guido van Rossum, but Python does have the non-profit governing body called Python Software Foundation, which holds all copyrights relating to CPython implementation, funds Python Conferences, and give grants. They are not mutually exclusive.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-24805835413512835252007-04-25T11:57:00.000-05:002007-04-25T11:57:00.000-05:00Hi Charles,This isn't the ideal way to ask a jruby...Hi Charles,<BR/><BR/>This isn't the ideal way to ask a jruby question but I'm having no joy posting to users@jruby.codehaus.org (I get the mailer daemon barfing even though I am a subscriber and I've had no response since I've forwarded it on to user-owner). Is there another way I can ask what is definately a newbie question and probably a simple mistake on my part?<BR/><BR/>Looking forward to hearing from you. Keep up the great work too!<BR/><BR/>Regs, AndrewAndrew Lawhttps://www.blogger.com/profile/18385277898094938510noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-39126923450116632312007-04-25T09:16:00.000-05:002007-04-25T09:16:00.000-05:00Threading; with ya.ObjectSpace; not needed at runt...Threading; with ya.<BR/><BR/>ObjectSpace; not needed at runtime, but extremely useful for debug/diagnostic purposes; making it 'off' by default seems like the correct approach. I've used some experimental J9 extensions that do this sort of thing, and they have literally saved my ass (finding leaks). A previous comment indicates one use is to search for Class and Module instances; yes, there should be a way to do that as well, orthogonal to iterating all the live objects in the system.<BR/><BR/>$SAFE and tainting; again, I think this has a place in debug/diagnostic mode, and less of a place in production code. Static and dynamic analysis for taint. And I'm not happy with Java's security model; I don't put myself in a position of running untrusted code, so I get to avoid all the SecurityManager business. But I'd be willing to play with more security if it was more straight-forward to use.<BR/><BR/>Direction: +1. We see some of the same issues with PHP: no spec, test cases not quite complete enough; and we're adding tests to the corpus now. PHP has some kind of a quasi-official governance group (The PHP Group), but it's not as official as Apache or anything. On the other hand, governing bodies sound like committees, and I'm not sure you want to go there either. Benevolent dictators, when they work, work great.Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-68044000945489811322007-04-25T08:57:00.000-05:002007-04-25T08:57:00.000-05:00Two notes on ObjectSpace:First off, your comments ...Two notes on ObjectSpace:<BR/><BR/>First off, your comments seem mainly aimed at #each_object; the Ruby interface to finalizers is also in the ObjectSpace module, and it's not clear whether you have any problems with it.<BR/><BR/>But #each_object is clearly a problem, so on to that.<BR/><BR/>Looking at the gems I have lying around to support an incipient production rails app, I see 16 uses of ObjectSpace.each_object, almost all to enumerate classes and modules, a la <BR/><BR/> ObjectSpace.each_object(Class) { |klass| ... }<BR/> ObjectSpace.each_object(Module) { |module| ... }<BR/><BR/>(The only other case is the test for the sqlserver db adapter, which uses it to enumerate instances of DBI::StatementHandle). <BR/><BR/>So, how much would it ease the pain if ObjectSpace.each_object(x) only worked if x was Class, Module, or a class that had been decorated in some specific way in advance, e.g.<BR/><BR/> class SomeClass; <BR/> include ObjectSpace::Walkable;<BR/> end<BR/><BR/>or the like?<BR/><BR/>(As a matter of implementation, it *might* work for ObjectSpace::Walkable.included to redefine 'new' in the including class to put the newly created object on the weak lists. That implementation has a somewhat subtle pitfall: you could use metaprogramming to include Walkable in a class after instances have already been created --- and those instances would remain untracked. This is the sort of situation where I wouldn't be *too* uncomfortable saying that the user got what they deserved --- but I imagine that reasonable people could disagree. <BR/><BR/>And unfortunately, supporting modules that include Walkable this way is more of a headache --- you have to worry about classes that include a module that includes a module that includes Walkable through multiple levels of indirection --- and one of *those* modules including Walkable after instances already exist. So, under this proposal, ObjectSpace.eachObject(Numeric) could no longer work --- but hey, even in MRI, it doesn't catch a lot of the numbers, because they're immediates).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-79565697591899502002007-04-25T08:06:00.000-05:002007-04-25T08:06:00.000-05:00Is there anything that can be done with the growin...Is there anything that can be done with the growing corpus of tests Ruby/JRuby are collecting to help define an initial "spec"? At least that would help people fumble into the intended design.<BR/><BR/>More importantly, I suspect the <I>intent</I> of the underlying design decisions in (J)Ruby are largely undocumented right now. That does scare me. It's not that you or Matz are hoarding secrets, of course. It's a lot of work to break out in verbage what is important. But it's critical for long-term viability of the language.R.J.https://www.blogger.com/profile/09103526606873658326noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-3645197259110395422007-04-25T07:13:00.000-05:002007-04-25T07:13:00.000-05:00"And the developing Ruby 1.9, the future successor..."And the developing Ruby 1.9, the future successor to the current version 1.8 C implementation, provides something in the middle: native threads with a giant lock, so threads won't run concurrently."<BR/><BR/>Wow. I did not know that. That is hilariously useless.UnintentionalObjectRetentionhttps://www.blogger.com/profile/04178094582352669104noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-57844012918819542492007-04-25T04:17:00.000-05:002007-04-25T04:17:00.000-05:00Haii. I'm just buzzing around, tracking down the v...Haii. I'm just buzzing around, tracking down the various people who were involved in the LiteStep community, to see where they're at now. If you're interested in catching up, lots of old-timers still hang out on #FPN, irc.freenode.net.Anonymoushttps://www.blogger.com/profile/06885599548832377523noreply@blogger.com