pat_shaughnessy

FYI My download kit includes a mobi file, and it looks acceptable on the kindle. But yes, in black and white you'll lose a lot of the value of the diagrams I drew.

Exactly, Peter. It's not tremendously hard to read the C code and understand what it is doing (usually), if you're familiar with C syntax. But it was tremendously difficult at times understanding _why_ it was doing what it was doing.

Yea I've thought about that. Let me see what I can do... :) thanks.

Hey thanks for asking - and yes, in the preface to the book I do explain how I figure this stuff out. But basically I: - study the C code for a long time - step through it in GDB a lot - add printf statements and recompile it to print out debug/trace info - actually change it to see what would happen if things were written differently.

A lot of hard work! I do the hard work so you don't have to :)

I complete agree, Peter! I did have the chance to help proofread it for Jesse and it's awesome - full of great info. Two thumbs up!

Oops - I missed that in my research. Yes, I agree this sentence is misleading; I'll update the text later on today. I suppose it's only true that Lisp (specifically Scheme) was the first widely used implementation of closures.

I'll be sure to take a look at that, and thanks for the link. No, no thoughts on it right now.

Yup - I'm planning to cover that later in the same chapter in my eBook. Your description is perfect: it's a closure with the "self" redirected to a different object (the receiver of instance_eval).

No - not the "unholy" part. Like vidarh I'm someone who loves Ruby (why else would I write a book about it!) but I do agree with him about the internal implementation: it's very confusing and hard to understand. At times, this leaks out into the syntax of an otherwise beautiful language. JRuby and especially Rubinius are great alternatives to MRI if you're interested in studying internals - they're much cleaner and easier to understand.

Sorry I don't know anything about the internals of Smalltalk, Python or Perl and can't comment on them.

Yes you're right! I stand corrected; will update the post when I have a chance.

Thanks for the link to Yehuda's post - it was a great read. I love how he compared Javascript and Ruby, and it's intriguing what he said at the bottom about how JS might include "block lambdas" similar to Ruby in the future. Fascinating!

Thanks! Yea I like writing about complex topics in a simple way that anyone can understand... that's one of my goals, maybe the most important one.

Great idea - although PDF supports search, having a real text version seems like it would be useful for authors to provide also. Thanks for the tip...

Great questions! To be honest I don't have enough knowledge of the MRI internals yet to be able to answer these 100% correctly. Maybe I'll write a follow up post or an update to this one explaining these issues when I have time for more research.

But for today:

1. str2 = str doesn't actually create a new string. RString represents a string value, not a string object. So str2=str creates a new RString because that essentially defines what str2's value refers to… Think of RString as an internal pointer to the value that str or str2 is referring to. Sorry - not a good explanation :(

2. How are shared RStrings modified? Not sure yet, but I'm curious to find out. Will let you know on my site somehow.

3. Yes, simply calling str2 = str or in a variety of other ways will do it.

Thanks a lot for the nice comments, guys! Sorry about the "link bait" - I really was just so surprised that the limit was 23, such a strange number, that I just had to put it in the title of the post. I didn't expect it to end up on HN.

Thanks! Cool idea about recompiling with a new value for RSTRING_EMBED_LEN_MAX - never thought of that!

Yes, the inner unions/structs are used to tell the C compiler exactly where the different data values should go. They are in fact not anonymous: e.g. "heap" and "aux" - the names appear right after the closing brace.

I'd love to see it also

That's a great question. I suppose they split it up into separate requests since downloading all of the dependencies at the same time might end up being slow and returning a lot of data, especially for something like Rails with a lot of dependencies. Or maybe separate requests was fast enough and a good trade off between speed/data and number of requests.

Wow... fascinating idea about "rake scaffoldhub:snapshot"!

I really appreciate your feedback and encouragement. I definitely will continue working on scaffoldhub; probably my next step will be to open source the web site code (gem is already open) so others can help out on this. I really see this as a community resource - not a private project.

Yes - this is an important concern, I agree. I hope that ratings/comments/reputation for scaffolds can help here. It's actually no different than installing a gem: you rely on the reputation of the gem author or else recommendations from other users to trust the gem will not do any harm when you try to use it.

Yea - there’s a lot of overlap with different things. Ryan’s screencasts on one hand, which are amazing even when out of date, and things like http://ruby-toolbox.com/, which give you a list of gems to look at/choose from on the other. Plus github itself is the best place to find actual code, and is peer reviewed in the sense of watch counts, etc...

All I can hope for is that with some community involvement, ScaffoldHub might become something useful in the middle: not in depth tutorials, not a code repository, but a series of helpful working examples.

I certainly can’t do it alone!

I totally agree - however, I'm guessing even more experienced Rails developers might find scaffolding occasionally useful as a starting point... e.g. for learning how to use a certain JQuery plugin it's often hard to know even what JS files you need, where to find them, where to put them, etc.

Great insight; hadn't thought of that before - thank you.

Great suggestion - thanks! I agree if there ever were many scaffolds on the site, choosing the right one to use will become much more difficult.

Thanks everyone! Great suggestions and very encouraging... I'll have to sort out priorities/what to do next and find some more spare time to work on this :)