tag:blogger.com,1999:blog-4704664917418794835.post7688691886461759647..comments2023-07-01T05:41:30.469-07:00Comments on Headius: What Would I (Will I?) Change About Rubyheadiushttp://www.blogger.com/profile/15717357218364947795noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-4704664917418794835.post-50971623102758655632007-04-25T02:17:00.000-07:002007-04-25T02:17:00.000-07:00Haii. I'm just buzzing around, tracking down t...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.Dekaritaehttp://www.blogger.com/profile/06885599548832377523noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-85512438105446054632007-04-25T05:13:00.000-07:002007-04-25T05:13:00.000-07:00"And the developing Ruby 1.9, the future succ..."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.UnintentionalObjectRetentionhttp://www.blogger.com/profile/04178094582352669104noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-11948720748203668752007-04-25T06:06:00.000-07:002007-04-25T06:06:00.000-07: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.http://www.blogger.com/profile/09103526606873658326noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-15910487958720346202007-04-25T09:57:00.000-07:002007-04-25T09:57:00.000-07:00Hi Charles,This isn't the ideal way to ask a j...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 Lawnoreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-42594011095713083312007-04-25T16:33:00.000-07:002007-04-25T16:33:00.000-07: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.sanxiynnoreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-8781822661957629222007-04-26T09:16:00.000-07:002007-04-26T09:16:00.000-07: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.robert thaunoreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-88625786325421412842007-04-26T10:34:00.000-07:002007-04-26T10:34:00.000-07: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 Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-3034109484444142242007-04-26T19:06:00.000-07:002007-04-26T19:06:00.000-07: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 Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-56335173318288676812007-04-27T07:41:00.000-07:002007-04-27T07:41:00.000-07:00Great review of whats "wrong" with Ruby....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.Justin W Smithhttp://www.blogger.com/profile/08965081597001041836noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-80911523398176000362007-05-01T12:40:00.000-07:002007-05-01T12:40:00.000-07:00For ObjectSpace, I've wondered how much of the...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.)Tom Palmernoreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-8283874394229209062007-05-08T09:28:00.000-07:002007-05-08T09:28:00.000-07:00I haven't used ObjectSpace much and maybe I am...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.Austinhttp://www.blogger.com/profile/17907770218961186024noreply@blogger.comtag:blogger.com,1999:blog-4704664917418794835.post-60755999822345437582007-06-06T23:19:00.000-07:002007-06-06T23:19:00.000-07: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.Bob Amanhttp://www.blogger.com/profile/17558670616626618259noreply@blogger.com