From vincent.isambart at gmail.com Fri Mar 17 17:00:37 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Fri, 17 Mar 2006 23:00:37 +0100 Subject: [rhg-discussion] [ANN] Ruby Hacking Guide Translation Message-ID: <7d9a1f530603171400j60cc5b8br82c251ddbca33775@mail.gmail.com> Hi everyone, I am pleased to announce that I have translated in English the second chapter ("Objects") of the "Ruby Hacking Guide" by Minero AOKI. The Japanese name of the book is "Ruby kanzen soosu coodo kaisetsu" (that means "Ruby complete source code explanation"), but "Ruby Hacking Guide" was its working title and has more or less become its "official" English name. This book explains the internals of the ruby interpreter. And even if you do not care about how the interpreter works, I think it can help have a better understanding of Ruby and how to make extension libraries. To fully understand the content, you'll need to have a good knowledge of Ruby and C. And do not forget that Ruby is the language and ruby its implementation. Why the second chapter? Well, because I think it was the first chapter that we needed to have a translation of. The first chapter of the book is just a summary of the Ruby language. In English we already have the Pickaxe with its first edition freely available on the Web. And as translating takes a lot of time, I think it's better to select the most interesting ones. The chapter 4 and 6 are on the tracks. Be aware of the fact that I am far from being a professional translator, this translation was just a way for me to improve my knowledge of Ruby and the Japanese language. And English is not my mother tongue, so it takes a little longer for me to translate. But I think more people are interested in an English version ;). The English could be better but I prefer spending more time on the Japanese and let someone better than me correct my sentences. I would like to also use this mail to ask if anyone else is interested in translating the RHG in English. Minero AOKI told me he thinks that some other people may have begun translating on their side, and I think he may be right. So if you have started translating it or want to, do not hesitate to manifest yourself. Japanese people are of course welcome to join us. You do not even need to know Japanese to help: you can maybe check wording, grammar and spelling, or help us with the diagrams. I doubt that alone I would able to translate the whole book (it's 500 pages long), but with some help, we should be able to at least translate a big part of it. Finally, I'd like to thank Minero AOKI for allowing me to post my translation of his book on the web. Thanks also to Laurent SANSONETTI for checking my translation, to Kouhei SUTOU for helping me understand some Japanese sentences, and to the Rubyforge guys for hosting us. Here's the address: http://rhg.rubyforge.org And for those who want the Japanese version, it's still available at http://i.loveruby.net/ja/rhg/ (http://i.loveruby.net/ja/rhg/book/ if you want to directly access the content). Cheers, Vincent "scritch" ISAMBART From meinrad.recheis at gmail.com Sun Mar 19 06:50:02 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Sun, 19 Mar 2006 12:50:02 +0100 Subject: [rhg-discussion] who am i Message-ID: <43d756720603190350h79432833x28213d8f9250765d@mail.gmail.com> hi, i have been responding to the RHG announcment at ruby-talk offering help with graphics/diagrams. so here i am. i got a rubyforge account ... nickname: henon (i am the maintainer of foxguib) let's see how it goes and if there is something to do for me too. it's not that i don't know what to do with my time, but i consider this project extremely important so i am going to take some time to help out a bit. ;) btw: while reading chapter 2 i noticed some typos and some ineffective markups like @things between ats@ -- henon From vincent.isambart at gmail.com Sun Mar 19 07:50:32 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Sun, 19 Mar 2006 13:50:32 +0100 Subject: [rhg-discussion] who am i In-Reply-To: <43d756720603190350h79432833x28213d8f9250765d@mail.gmail.com> References: <43d756720603190350h79432833x28213d8f9250765d@mail.gmail.com> Message-ID: <7d9a1f530603190450x1519adb7g8808464bb370441e@mail.gmail.com> Hi, Note: Sorry Meinrad if you get this mail twice, but I forgot to set the mailing list for the replies to go back to the list, but this should be corrected now. > let's see how it goes and if there is something to do for me too. > it's not that i don't know what to do with my time, but i consider > this project extremely important so i am going to take some time to > help out a bit. ;) The diagrams the most needed for the moment are those for chapter 4 and 6. I'll commit on SVN the current version of chapter 4 even if some parts are a bit too rough because it's easier to make diagrams if you understand what's going on. I'll post at the same time the translation of the text in those diagrams. What tool do you plan to use to make them? After that, the diagrams of chapter 2 may be improved but for the moment it's really not very important. I'll add you to the rubyforge project after you send me your first contribution :). > btw: while reading chapter 2 i noticed some typos and some ineffective > markups like @things between ats@ I've just corrected the @things between ats@ and some of the erratas of the book (I had completely forgotten about that). For the typos, just send them to me, I'll correct them. Cheers, Vincent ISAMBART From vincent.isambart at gmail.com Sun Mar 19 09:19:33 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Sun, 19 Mar 2006 15:19:33 +0100 Subject: [rhg-discussion] Chapter 4 pre-alpha translation Message-ID: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> Hi, I just committed a previous-alpha version of chapter 4. I know it's still pretty bad, it's far from being finished. I just did the first translation, and a few corrections of the beginning. Do not send me any remark on it. Some parts may be really hard to understand, and I now that. I just committed it so that people making the diagrams can understand the context. The translation of the diagrams of chapter 4 is just bellow. To find the diagrams, search for the "?" character followed by the diagram number in the text. This character means diagram. What I did here is just a quick translation of the meaning, do not hesitate to modify it. Even if some diagrams do not have anything to translate, I still think they should all be redone, at least to have some homogeneity. If you find a better way than the one of the original diagram to express the same thing, do not hesitate to use it. Diagram 1: rb_singleton_class (left part) ???? initial condition (middle part) ???????? singleton class creation (right part) obj?????????? change/replace obj's class Diagram 2: Infinite loop of classes Nothing to translate Diagram 3: Requirements dependencies line 1: - ?????????????? static methods are needed line 2: - ??????? class methods - ???????? reflection line 3: - ?????? singleton methods - ?????????? classes are also objects line 4: - ????? singleton classes Diagram 4: Introduction of a class's singleton class Nothing to translate Diagram 5: Hierarchy of multi-level inheritance ???????????? What class should it be? Diagram 6: Class hierarchy and metaclasses Nothing to translate Diagram 7: Class of a class's singleton class Nothing to translate Diagram 8: Singleton class and real class obj?????? obj's real class obj?????? obj's singleton class Diagram 9: Metaobjects creation ????? first half of the code ????? second half of the code Diagram 10: Ruby metaobjects Nothing to translate Diagram 11: Include class ????? Include class ???????? Normal module Diagram 12: Include ?????? include Diagram 13: Include (1) ??????? before include (2) rb_include_module()?????? first passing in the loop of rb_include_module() module = m1 (3) rb_include_module()?????? second passing in the loop of rb_include_module() module = im2 Cheers, Vincent ISAMBART From amrmalik at gmail.com Sun Mar 19 11:42:25 2006 From: amrmalik at gmail.com (AMR MALIK) Date: Sun, 19 Mar 2006 11:42:25 -0500 Subject: [rhg-discussion] Hello In-Reply-To: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> Message-ID: <72CA85CE-389E-455C-9B9C-90716283ADA8@gmail.com> Hello, My name is Amr Malik and I read about this on the ruby mailing list. I don't know Japanese, so I can't help with translation, but if you need help proof-reading and maybe rejigging some of the english sentence structure, I'd be happy to help. I'm not too sure how exactly the ruby-forge submissions work. I can always post my contributions to the list and someone else can commit them for me? Thanks for all your effort and work to bring this excellent resource to the english speaking rubyists. Regards, Amr From meinrad.recheis at gmail.com Sun Mar 19 15:36:05 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Sun, 19 Mar 2006 21:36:05 +0100 Subject: [rhg-discussion] Chapter 4 pre-alpha translation In-Reply-To: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> Message-ID: <43d756720603191236n263c5aa6r76e72a44c51c917c@mail.gmail.com> interesting ... so i am going to learn some chinese characters (at least a few). i know a little chinese because my wife is from china, but i cannot read/write. how did you learn japanese? i managed to find the first diagram but it seems the japanese originals are not in the repository. ok, i can get them from the web. inkscape looks very good. i am going to use it. good luck and good night, -- henon On 3/19/06, Vincent Isambart wrote: > Hi, > > I just committed a previous-alpha version of chapter 4. I know it's > still pretty bad, it's far from being finished. I just did the first > translation, and a few corrections of the beginning. Do not send me > any remark on it. Some parts may be really hard to understand, and I > now that. I just committed it so that people making the diagrams can > understand the context. > > The translation of the diagrams of chapter 4 is just bellow. To find > the diagrams, search for the "?" character followed by the diagram > number in the text. This character means diagram. What I did here is > just a quick translation of the meaning, do not hesitate to modify it. > > Even if some diagrams do not have anything to translate, I still think > they should all be redone, at least to have some homogeneity. If you > find a better way than the one of the original diagram to express the > same thing, do not hesitate to use it. > > Diagram 1: rb_singleton_class > (left part) ???? initial condition > (middle part) ???????? singleton class creation > (right part) obj?????????? change/replace obj's class > > Diagram 2: Infinite loop of classes > Nothing to translate > > Diagram 3: Requirements dependencies > line 1: > - ?????????????? static methods are needed > line 2: > - ??????? class methods > - ???????? reflection > line 3: > - ?????? singleton methods > - ?????????? classes are also objects > line 4: > - ????? singleton classes > > Diagram 4: Introduction of a class's singleton class > Nothing to translate > > Diagram 5: Hierarchy of multi-level inheritance > ???????????? What class should it be? > > Diagram 6: Class hierarchy and metaclasses > Nothing to translate > > Diagram 7: Class of a class's singleton class > Nothing to translate > > Diagram 8: Singleton class and real class > obj?????? obj's real class > obj?????? obj's singleton class > > Diagram 9: Metaobjects creation > ????? first half of the code > ????? second half of the code > > Diagram 10: Ruby metaobjects > Nothing to translate > > Diagram 11: Include class > ????? Include class > ???????? Normal module > > Diagram 12: Include > ?????? include > > Diagram 13: Include > (1) ??????? before include > (2) rb_include_module()?????? first passing in the loop of rb_include_module() > module = m1 > (3) rb_include_module()?????? second passing in the loop of rb_include_module() > module = im2 > > Cheers, > Vincent ISAMBART > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From techml at sgtpepper.net Sun Mar 19 21:24:06 2006 From: techml at sgtpepper.net (Daigo Moriwaki) Date: Mon, 20 Mar 2006 11:24:06 +0900 Subject: [rhg-discussion] Hello Message-ID: <441E1246.1060905@sgtpepper.net> Hi all, I'd like to help this project because RHG is one of the greatest (Ruby) book and is a kind of resource that makes Japanese Ruby users understand Ruby well. I am Japanese and have read the book. Writing English is not so good, that I can not translate a full text. I'd like to check translated English. If you can not understand Japanese sentences, I will answer. Aoki-san sometimes use Japanese-peculiar expressions, which would be hard to understand and translate. Thanks, daigo -- Daigo Moriwaki beatles at sgtpepper dot net daigo at debian dot org From vincent.isambart at gmail.com Mon Mar 20 03:37:35 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 20 Mar 2006 09:37:35 +0100 Subject: [rhg-discussion] Chapter 4 pre-alpha translation In-Reply-To: <43d756720603191236n263c5aa6r76e72a44c51c917c@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> <43d756720603191236n263c5aa6r76e72a44c51c917c@mail.gmail.com> Message-ID: <7d9a1f530603200037q3ee45548t7ed71e33e56b49db@mail.gmail.com> > interesting ... so i am going to learn some chinese characters (at least a few). And some Japanese characters too :). The Japanese use 3 types of characters: hiragana, katakana and Chinese characters. The shape of the Chinese characters also changes a little between Japanese, simplified Chinese and traditional Chinese, but generally native speakers can recognize the equivalents (it's generally easier for Chinese people to recognize Chinese characters used in Japanese than for Japanese people to recognize Chinese characters used in Chinese). Japanese use around 2000 Chinese characters, whereas Chinese use more something like 6000... > i know a little chinese because my wife is from china, but i cannot > read/write. how did you learn japanese? Mostly by myself, thanks to the high number of ressources available on the web, and I watch (maybe too many ;)) Japanese drama and animes. > i managed to find the first diagram but it seems the japanese > originals are not in the repository. ok, i can get them from the web. You can directly download a tar.gz with everything there: http://i.loveruby.net/ja/rhg/ar/RubyHackingGuide.tar.gz There is also the original TGIF files available if you want: http://i.loveruby.net/ja/rhg/ar/rhg-images.tar.gz From vincent.isambart at gmail.com Mon Mar 20 03:59:49 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 20 Mar 2006 09:59:49 +0100 Subject: [rhg-discussion] Hello In-Reply-To: <441E1246.1060905@sgtpepper.net> References: <441E1246.1060905@sgtpepper.net> Message-ID: <7d9a1f530603200059q2025f0efuebb50a1dfe1b3ffe@mail.gmail.com> Hi, > I'd like to help this project because RHG is one of the greatest (Ruby) > book and is a kind of resource that makes Japanese Ruby users understand > Ruby well. I totally understand :). Translating RHG really helps me having a better understanding of Ruby. > I am Japanese and have read the book. > Writing English is not so good, that I can not translate a full text. > I'd like to check translated English. If you want, you can check at least chapter 2. For chapter 4, it's better to wait for me to > If you can not understand Japanese sentences, I will answer. Aoki-san > sometimes use Japanese-peculiar expressions, which would be hard to > understand and translate. Great. I can stop bothering Kouhei SUTOU with my questions :). I've got a sentence in chapter 6 that I have some problems with: Ruby??????????????????????????????????????????????????????????????????????????????????????????????? If you have problems translating it, rewriting it more simply in Japanese will be great :). Cheers, Vincent ISAMBART From vincent.isambart at gmail.com Mon Mar 20 04:09:51 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 20 Mar 2006 10:09:51 +0100 Subject: [rhg-discussion] Hello In-Reply-To: <72CA85CE-389E-455C-9B9C-90716283ADA8@gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> <72CA85CE-389E-455C-9B9C-90716283ADA8@gmail.com> Message-ID: <7d9a1f530603200109h1c1aa7fwe6bbde2a47ab6aa9@mail.gmail.com> Hi, > Hello, My name is Amr Malik and I read about this on the ruby mailing > list. I don't know Japanese, so I can't help with translation, but if > you need help proof-reading and maybe rejigging some of the english > sentence structure, I'd be happy to help. I'm not too sure how > exactly the ruby-forge submissions work. I can always post my > contributions to the list and someone else can commit them for me? I don't think there's any formal way to ask to join the RubyForge project. For the moment, the only persons having write access on the repository are Laurent SANSONETTI and me. I prefer to only give access to people having already made a few contributions. So for the time being, yes, just send your contributions to the ML. If you want to check and rewrite a few things, you can start with chapter 2. If there are just a few things, you can just put them in a mail. Otherwise, the best is to modify the text file used to generate the HTML (chapter02.txt), and send either a modified version of it or just a diff. > Thanks for all your effort and work to bring this excellent resource > to the english speaking rubyists. You're welcome :) From meinrad.recheis at gmail.com Mon Mar 20 04:53:57 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Mon, 20 Mar 2006 10:53:57 +0100 Subject: [rhg-discussion] Chapter 4 pre-alpha translation In-Reply-To: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> Message-ID: <43d756720603200153k5c4b876ck221100215336fa77@mail.gmail.com> On 3/19/06, Vincent Isambart wrote: > Diagram 1: rb_singleton_class > (left part) ???????B initial condition > (middle part) ???????????????? singleton class creation > (right part) obj???????????????????? change/replace obj's class > this is my first try with inkscape. have not yet tested if it fits to the text. maybe the middle part could also be texted: "add singleton class" according the style: i thought it's better not too fancy but also not boring. so i decided for a flat round style with carefully chosen colors. (the colors are not yet final) and the style may be discussed of course! i also try to make the diagrams as clear as possible by representing different kinds of objects by different shapes. see my suggestion for chapter02-diagram02. i have annother idea for chapter02 Diagram 3: "struct RBasic" ... i think it would be interesting to point out the memory sizes of the different objects more apparently by adding a vertical axis with the label "size in memory". the test f??r chapter2 seems too large to me. should i make all diagrams the same width or will you embed them centered? in the second case small diagrams can be small and i only need to check that they don't exceed the text column size. what do you think? -- henon PS: demo diagrams are attached -------------- next part -------------- A non-text attachment was scrubbed... Name: chapter04-diagram01-en.png Type: image/png Size: 29917 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/53107ab2/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: chapter02-diagrams-test.png Type: image/png Size: 28441 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/53107ab2/attachment-0003.png From vincent.isambart at gmail.com Mon Mar 20 07:01:30 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 20 Mar 2006 13:01:30 +0100 Subject: [rhg-discussion] Chapter 4 pre-alpha translation In-Reply-To: <43d756720603200153k5c4b876ck221100215336fa77@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> <43d756720603200153k5c4b876ck221100215336fa77@mail.gmail.com> Message-ID: <7d9a1f530603200401x46eea69ahff758a136953646b@mail.gmail.com> > this is my first try with inkscape. have not yet tested if it fits to the text. > maybe the middle part could also be texted: "add singleton class" I could really not do that with a first try ;). > according the style: i thought it's better not too fancy but also not > boring. so i decided for a flat round style with carefully chosen > colors. (the colors are not yet final) and the style may be discussed > of course! I think it looks quite great :). > i also try to make the diagrams as clear as possible by representing > different kinds of objects by different shapes. see my suggestion for > chapter02-diagram02. I like it. But others are welcome to tell what they think :). > i have annother idea for chapter02 Diagram 3: "struct RBasic" > ... i think it would be interesting to point out the memory sizes of > the different objects more apparently by adding a vertical axis with > the label "size in memory". Yes, it could be interesting, But it may be difficult to keep height proportional to the size and special shapes. A structure with an int should have the same height as just an int... But if you find a great way to make everything easy to understand, I take it :). > the test for chapter2 seems too large to me. > should i make all diagrams the same width or will you embed them > centered? in the second case small diagrams can be small and i only > need to check that they don't exceed the text column size. I'll center them. From meinrad.recheis at gmail.com Mon Mar 20 07:24:58 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Mon, 20 Mar 2006 13:24:58 +0100 Subject: [rhg-discussion] please review ch04-diagram02 Message-ID: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> hi all, i made two variants of chapter04-diagram02. i have a suggestion that is quite different from the original but i think it's representing things more exactly, so i am asking for your opinions. (you may also critique the style, i am still experimenting) i am happy to see lots of people wanting to join the project. ;) take care, --henon -------------- next part -------------- A non-text attachment was scrubbed... Name: chapter04-diagram02-variants.png Type: image/png Size: 37185 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/247afda6/attachment-0001.png From vincent.isambart at gmail.com Mon Mar 20 07:44:05 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 20 Mar 2006 13:44:05 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> Message-ID: <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> Hi, > i made two variants of chapter04-diagram02. i have a suggestion that > is quite different from the original but i think it's representing > things more exactly, so i am asking for your opinions. Well, the second version looks better, but I think it does not have the intended meaning. You should mix both, replacing the names "Object" and "Class" by "obj", "obj.class", "Class", "Class". I think the intended meaning is that you take any object, you follow the class link you get its class, and if you follow the class link of this class you get Class, if you follow the class link of Class you get Class... Was I clear? Cheers, Vincent ISAMBART From wilsonb at gmail.com Mon Mar 20 12:41:04 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Mon, 20 Mar 2006 12:41:04 -0500 Subject: [rhg-discussion] Self-introduction Message-ID: I saw on the mailing list page that I should introduce myself, so here we go. Things I have: 1. A physical copy of the RHG. 2. Ruby skills that I'm not ashamed of. 3. Conversational Japanese reading and writing skills that maybe need a little rust knocked off. 4. Decent but rusty knowledge of C. I have plenty of books, though, and I'm comfortable reading it. I think this project is important, so I'd like to donate at least 5 hours a week to it. I'm ready to take an assignment if you've got one. Thanks, --Wilson. From piyokun at gmail.com Mon Mar 20 13:13:20 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 03:13:20 +0900 Subject: [rhg-discussion] Hello, self-introduction Message-ID: <1f748ec60603201013u5e2cf5cfi1af02c7ea98ed181@mail.gmail.com> I saw the Daigo Moriwaki's post on redhanded (http://redhanded.hobix.com/cult/rubyHackingGuideTranslationProjectStarted.html) about this translation effort and I would like to join the effort. I'm going to introduce myself like Wilson Bilkovich, so here we go. Things I have: 1. No physical copy of the RHG. 2. I just started working with ruby 1.8.2, some scripts, programs and rakefiles at work. Will start working with rails as a hobby. Not a total beginner, but not yet proficient with the API. 3. Conversational Japanese reading and writing skills. Well okay, I live in Japan and I work mainly in Japanese as a programmer. 4. I work mainly in C these days. 5. My native language is U.S. English. I'm ready to take an assignment if you've got one. Actually I'd like to hear which chapters have high priority, so I can read the book first! Ha ha. Best regards, Clifford Caoile --- http://piyokun.googlepages.com From meinrad.recheis at gmail.com Mon Mar 20 13:14:59 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Mon, 20 Mar 2006 19:14:59 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> Message-ID: <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> On 3/20/06, Vincent Isambart wrote: > Hi, > > > i made two variants of chapter04-diagram02. i have a suggestion that > > is quite different from the original but i think it's representing > > things more exactly, so i am asking for your opinions. > Well, the second version looks better, but I think it does not have > the intended meaning. You should mix both, replacing the names > "Object" and "Class" by "obj", "obj.class", "Class", "Class". > I think the intended meaning is that you take any object, you follow > the class link you get its class, and if you follow the class link of > this class you get Class, if you follow the class link of Class you > get Class... > > Was I clear? > let me shortly explain what i mean. look at the irb session irb(main):001:0> obj=Object.new => # irb(main):002:0> obj.class => Object irb(main):003:0> obj.class.class => Class irb(main):004:0> obj.class.class.class => Class irb(main):005:0> ... any object's class is not Class in general but some subclass of Object. Object#class is Class and Class#class is Class. My variant leaves out the unimportant variable name "obj". And it shows the same thing: the infinite loop of Class's Class using a notation where an object is represented by its classname (in white) and its methods of concern (#class in our case). my intent is to develop a reasonable representation for the presented things that i can use in all diagrams. the original uses boxes for everything: variables, expressions, structs, objects, classes. i tried to introduce different representation for different things (a clear visual language) but it complicates things. it's harder to be exact, and the exact intent of the author needs to be understood to choose the right representation. maybe i should just style the originals a bit and don't try to exactify them in their representation. would also be less work for me to do. it's up to you. i won't force it. if you think the other is better, i strictly copy the originals. cheers, -- henon From meinrad.recheis at gmail.com Mon Mar 20 14:26:56 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Mon, 20 Mar 2006 20:26:56 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> Message-ID: <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> annother try for chapter 4 diagram 2: i think this one's visual language is precise/unmisleading. it uses a ruby code fragment to provide a context and the well known convention Class#instance_method. @all: let me know what you think about it. hope we find a visual language we all agree about. alternately we may agree to strictly keep the original presentation and i style it up a bit. take care, -- henon -------------- next part -------------- A non-text attachment was scrubbed... Name: chapter04-diagram02-experimental.png Type: image/png Size: 33111 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/5a66e541/attachment-0001.png From meinrad.recheis at gmail.com Mon Mar 20 14:48:56 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Mon, 20 Mar 2006 20:48:56 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> Message-ID: <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> and annother one expressing the infinite loop even better On 3/20/06, Meinrad Recheis wrote: > annother try for chapter 4 diagram 2: > i think this one's visual language is precise/unmisleading. it uses > a ruby code fragment to provide a context and the well known > convention Class#instance_method. > > @all: let me know what you think about it. hope we find a visual > language we all agree about. alternately we may agree to strictly keep > the original presentation and i style it up a bit. > > take care, > -- henon > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: chapter04-diagram02-experimental.png Type: image/png Size: 27212 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/a3208a9f/attachment-0001.png From tom at infoether.com Mon Mar 20 15:32:02 2006 From: tom at infoether.com (Tom Copeland) Date: Mon, 20 Mar 2006 15:32:02 -0500 Subject: [rhg-discussion] [PATCH] Tiny typo in chapter two Message-ID: <03b201c64c5d$59d8ae80$1301a8c0@tomhplaptop> Here's the world's most trivial patch. Also, Vincent, thanks very much for doing this translation... this is great stuff. Yours, Tom Index: rhg/chapter02.txt =================================================================== --- rhg/chapter02.txt (revision 8) +++ rhg/chapter02.txt (working copy) @@ -42,7 +42,7 @@ In practice, a `VALUE` must be casted to different types of structure pointer. Therefore if an `unsigned long` and a pointer have a different size, `ruby` will not work well. Strictly speaking, it will not work for pointer types -bigger that `sizeof(unsigned long)`. Fortunately, no recent machine feature +bigger than `sizeof(unsigned long)`. Fortunately, no recent machine feature this capability, even if some time ago there were quite a few of them. Several structures are available according to object classes: From ebrandeis at gmail.com Mon Mar 20 16:02:08 2006 From: ebrandeis at gmail.com (Eden Brandeis) Date: Mon, 20 Mar 2006 13:02:08 -0800 Subject: [rhg-discussion] Translation Project Introduction Message-ID: <7c66d87e0603201302y4238cf51ud42af0ef43280df3@mail.gmail.com> My name is Eden Brandeis. I am a native English speaker and write and edit technical documents frequently at my day job. I also have advanced Japanese language skills (written and spoken) and have done a number of small and medium size translation jobs in the past. You can see my slightly out of date translator's profile at Proz.com (http://www.proz.com/pro/23513) to get a better idea of my background. I am relatively new to Ruby, but have a firm grasp of C and object based programming concepts. Unfortunately, I don't have much free time to commit to this project, but would like to stay informed as to the progress of this project and help out when I can. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rhg-discussion/attachments/20060320/336abeef/attachment.htm From j at rjimlad.org Mon Mar 20 16:39:06 2006 From: j at rjimlad.org (Jim Driscoll) Date: Mon, 20 Mar 2006 21:39:06 +0000 Subject: [rhg-discussion] Hello Message-ID: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> Hi all, Ruby knowledge: fair C knowledge: good Languages: English (British) I have to say this seems like a worthy project (and an excellent reference book) based on chapter two. So far, I'd say: - I think that "three conditions that must be respected" should perhaps be "three conditions that must be obeyed" or indeed "must be true". - "The name of these T_xxxx flags is directly linked to the type name" should read "The names of these T_xxxx flags are directly linked to the [corresponding] type name" or maybe just "The names of these T_xxxx flags correspond to type names" - "That?s the consequences for being able to handle all the structure types in a unified way." should read "That?s the consequence of being able to handle all the structure types in a unified way." - It's normally considered better style to write "okay" rather than "OK" - "so why is the structure type and class are stored separately?" should read "so why are the structure type and class stored separately?" - "The first one is, I?m sorry for contradicting what I said before, but in fact" should perhaps read "The first one is (I?m sorry for contradicting what I said before), in fact", or "The first one is: I?m sorry for contradicting what I said before, but in fact" - "so finding a structure from a class would require to keep the correspondence" should read "so finding a structure from a class would require keeping the correspondence" - "As limiting myself to say that basic.flags is used for different things" should read "As limiting myself to saying that basic.flags is used for different things" or perhaps "As just saying that basic.flags is used for different things" - "The 6 cases for which VALUE is not a pointer are the followings" should read: "The 6 cases for which VALUE is not a pointer are the following" - "expressing them as structures would risk to slow down the execution" should read "expressing them as structures would risk slowing down execution [speed]" - "?small? means signed integers that can be held in sizeof(VALUE) *8-1 bit" should read "?small? means signed integers that can be held in sizeof(VALUE)*8-1 bits" - "As this question if quite troublesome to answer" is a typo: should be "As this question is quite troublesome to answer" - "because of of memory management and memory management and memory management? " I don't know quite what this is trying to say, but it's definitely got one "of" too many. ...and that's all as far as I've read (the beginning of the "Methods" section. Jim From j at rjimlad.org Mon Mar 20 17:16:52 2006 From: j at rjimlad.org (Jim Driscoll) Date: Mon, 20 Mar 2006 22:16:52 +0000 Subject: [rhg-discussion] Hello In-Reply-To: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> Message-ID: <53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org> hi again, On 20 Mar 2006, at 21:39, Jim Driscoll wrote: > > ...and that's all as far as I've read (the beginning of the "Methods" > section. > I suddenly have more time to kill, so here's some more: - "that is having an identity, being able to call a method, keeping data for each instance" should read "that is having an identity, being able to call a method, and keeping data for each instance" - "In Ruby, class exist as objects during the execution" should be something like "In Ruby, classes exist as objects at runtime" - "but anyway they are objects that keep one to one relations correspondence" should be "but anyway, they are objects that maintain one to one relationships" or perhaps "but basically, it is a table mapping names to objects". I don't fully grok struct st_table, but I believe it's intended to be used for looking up objects from identifiers (whether string or otherwise). - "The fourth member super keeps, like its name says, the superclass" should be "The fourth member super keeps, like its name suggests, the superclass" - "Classes being structured like this, you can easily imagine the method call process" should be "With classes structured like this, you can easily imagine the method call process" - "Error checks are necessary, but it?s not the main part of the treatment, so you have to ignore them at first read" should be "Error checks are necessary, but it?s not the main part of the treatment, so you should ignore them for now"... but I'll also point out that "treatment" is a very rarely used word in this sense; another may be easier to read. - " It seems only the treatment of T_OBJECT, T_CLASS and T_MODULE is different" should be " It seems only the treatments of T_OBJECT, T_CLASS and T_MODULE are different" - "It?s possible that obj points to a struct RClass, but as we only access the second member no problem will occur" should be "It?s possible that obj points to a struct RClass, but as we're only going to access the second member, it won't cause a problem" - "if iv_tbl does not exists, it creates it" should be "if iv_tbl does not exist, it creates it" - " In other words, in the case of st_add_direct(), is a key already registered" should be "In other words, in the case of st_add_direct (), if a key already registered" - "st_add_direct() can be used when the check for existence has already been done, like it is the case here" should be "st_add_direct () can be used when the check for existence has already been done, as is the case here" - "If you take all this into consideration, you can conclude that increasing the size of object structures does not bring any good." should be "If you take all this into consideration, you can conclude that increasing the size of object structures does not do any good." - rb_ivar_get(): (A), (B) and (C) seem to be out-of-order (the letters themselves, that is) That's all up to "Structures for objects", although I think I've missed a few things. Jim From meinrad.recheis at gmail.com Mon Mar 20 18:22:06 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Tue, 21 Mar 2006 00:22:06 +0100 Subject: [rhg-discussion] need to understand this figure Message-ID: <43d756720603201522l7078f5ebu1e152465d939e4c8@mail.gmail.com> please have a look at figures 4 and 5 in chapter 4. http://i.loveruby.net/ja/rhg/book/images/ch_class_metaclass.jpg http://i.loveruby.net/ja/rhg/book/images/ch_class_multi.jpg in this figure as far as i found out on my own (trying to find out which symbols mean class, singleton class, etc is real fun ^^) an object's singleton class is presented in brackets. (obj) is obj's singleton class. what i don't understand is the little "c". what does it stand for? regards, -- henon From meinrad.recheis at gmail.com Mon Mar 20 18:25:09 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Tue, 21 Mar 2006 00:25:09 +0100 Subject: [rhg-discussion] need to understand this figure In-Reply-To: <43d756720603201522l7078f5ebu1e152465d939e4c8@mail.gmail.com> References: <43d756720603201522l7078f5ebu1e152465d939e4c8@mail.gmail.com> Message-ID: <43d756720603201525ra40dcd3kcd7b21881840d20e@mail.gmail.com> i see, one sentence refers to the "c" in figure 4. all i need is the translation of this sentence: ?????????????????????????????????4?c??????????????????????????????????????5?? On 3/21/06, Meinrad Recheis wrote: > please have a look at figures 4 and 5 in chapter 4. > > http://i.loveruby.net/ja/rhg/book/images/ch_class_metaclass.jpg > http://i.loveruby.net/ja/rhg/book/images/ch_class_multi.jpg > > in this figure as far as i found out on my own (trying to find out > which symbols mean class, singleton class, etc is real fun ^^) an > object's singleton class is presented in brackets. (obj) is obj's > singleton class. what i don't understand is the little "c". what does > it stand for? > regards, > -- henon > From amrmalik at gmail.com Mon Mar 20 19:16:30 2006 From: amrmalik at gmail.com (AMR MALIK) Date: Mon, 20 Mar 2006 19:16:30 -0500 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> Message-ID: I think (b) is more understandable for me. thx, Amr On 20-Mar-06, at 7:24 AM, Meinrad Recheis wrote: > hi all, > i made two variants of chapter04-diagram02. i have a suggestion that > is quite different from the original but i think it's representing > things more exactly, so i am asking for your opinions. > (you may also critique the style, i am still experimenting) > > i am happy to see lots of people wanting to join the project. ;) > take care, > --henon > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion From piyokun at gmail.com Mon Mar 20 19:32:58 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 09:32:58 +0900 Subject: [rhg-discussion] Hello In-Reply-To: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> Message-ID: <1f748ec60603201632v5e6a2d00s96f71ed491d70014@mail.gmail.com> Here's most of Jim Driscoll's suggestion in diff format. I say most because he has multiple suggestions for some points. Index: chapter02.txt =================================================================== --- chapter02.txt (revision 8) +++ chapter02.txt (working copy) @@ -11,7 +11,7 @@ What are the required conditions to make sure objects can exist? Many explanations can be given but in reality there are three conditions that must -be respected: +be obeyed: # Being able to differentiate itself from the rest (having an identity) # Being able to reply to requests (methods) @@ -147,8 +147,8 @@ TYPE(str); /* the return value is T_STRING */ -The name of these `T_xxxx` flags is directly linked to the type name, like -`T_STRING` for `struct RString` and `T_ARRAY` for `struct RArray`. +The names of these `T_xxxx` flags are directly linked to the corresponding type +name, like `T_STRING` for `struct RString` and `T_ARRAY` for `struct RArray`. The other member of `struct RBasic`, `klass`, contains the class this object belongs to. As the `klass` member is of type `VALUE`, what is stored is (a @@ -170,14 +170,14 @@ handle all different types of structure via `VALUE`. If you cast a pointer to a structure to `VALUE`, as the type information does not remain, the compiler won't be able to help. Therefore we have to manage the type ourselves. That's -the consequences for being able to handle all the structure types in a unified +the consequence of being able to handle all the structure types in a unified way. -OK, but the used structure is defined by the class so why is the structure +OK, but the used structure is defined by the class so why are the structure type and class are stored separately? Being able to find the structure type from the class should be enough. There are two reasons for not doing this. -The first one is, I'm sorry for contradicting what I said before, but in fact +The first one is (I'm sorry for contradicting what I said before), in fact there are structures that do not have a `struct RBasic` (i.e. they have no `klass` member). For example `struct RNode` that will appear in the second part of the book. However, `flags` is guaranteed to be in the beginning @@ -193,7 +193,7 @@ h4. The use of `basic.flags` -As limiting myself to say that `basic.flags` is used for different things +As limiting myself to saying that `basic.flags` is used for different things including the type of structure makes me feel bad, here's a general illustration for it (diagram 5). There is no need to understand everything right away, I just wanted to show its uses while it was bothering me. @@ -210,7 +210,7 @@ As I said, `VALUE` is an `unsigned long`. As `VALUE` is a pointer, it may look like `void*` would also be all right, but there is a reason for not doing this. In fact, `VALUE` can also not be a pointer. The 6 cases for which -`VALUE` is not a pointer are the followings: +`VALUE` is not a pointer are the following: # small integers # symbols @@ -225,12 +225,12 @@ As in Ruby all data are objects, integers are also objects. However, as there are lots of different instances of integers, expressing them as structures -would risk to slow down the execution. For example, when incrementing from 0 +would risk slowing down execution. For example, when incrementing from 0 to 50000, just for this creating 50000 objects would make us hesitate. That's why in `ruby`, to some extent, small integers are treated specially and embedded directly into `VALUE`. "small" means signed integers that can be held -in `sizeof(VALUE)*8-1` bit. In other words, on 32 bits machines, the integers +in `sizeof(VALUE)*8-1` bits. In other words, on 32 bits machines, the integers have 1 bit for the sign, and 30 bits for the integer part. Integers in this range will belong to the `Fixnum` class and the other integers will belong to the `Bignum` class. @@ -268,7 +268,7 @@ What are symbols? -As this question if quite troublesome to answer, let's start with the reasons +As this question is quite troublesome to answer, let's start with the reasons why symbols were necessary. First, let's start with the `ID` type used inside `ruby`. It's like this: @@ -287,7 +287,7 @@ In language implementations, there are a lot of names to handle. Method names or variable names, constant names, file names in class names... It's -troublesome to handle all of them as strings (`char*`), because of of memory +troublesome to handle all of them as strings (`char*`), because of memory management and memory management and memory management... Also, lots of comparisons would certainly be necessary, but comparing strings character by character will slow down the execution. That's why strings are not handled On 3/21/06, Jim Driscoll wrote: > Hi all, > > Ruby knowledge: fair > C knowledge: good > Languages: English (British) > > I have to say this seems like a worthy project (and an excellent > reference book) based on chapter two. So far, I'd say: > > - I think that "three conditions that must be respected" should > perhaps be "three conditions that must be obeyed" or indeed "must be > true". > - "The name of these T_xxxx flags is directly linked to the type > name" should read "The names of these T_xxxx flags are directly > linked to the [corresponding] type name" or maybe just "The names of > these T_xxxx flags correspond to type names" > - "That's the consequences for being able to handle all the structure > types in a unified way." should read "That's the consequence of being > able to handle all the structure types in a unified way." > - It's normally considered better style to write "okay" rather than "OK" > - "so why is the structure type and class are stored separately?" > should read "so why are the structure type and class stored separately?" > - "The first one is, I'm sorry for contradicting what I said before, > but in fact" should perhaps read "The first one is (I'm sorry for > contradicting what I said before), in fact", or "The first one is: > I'm sorry for contradicting what I said before, but in fact" > - "so finding a structure from a class would require to keep the > correspondence" should read "so finding a structure from a class > would require keeping the correspondence" > - "As limiting myself to say that basic.flags is used for different > things" should read "As limiting myself to saying that basic.flags is > used for different things" or perhaps "As just saying that > basic.flags is used for different things" > - "The 6 cases for which VALUE is not a pointer are the followings" > should read: "The 6 cases for which VALUE is not a pointer are the > following" > - "expressing them as structures would risk to slow down the > execution" should read "expressing them as structures would risk > slowing down execution [speed]" > - ""small" means signed integers that can be held in sizeof(VALUE) > *8-1 bit" should read ""small" means signed integers that can be held > in sizeof(VALUE)*8-1 bits" > - "As this question if quite troublesome to answer" is a typo: should > be "As this question is quite troublesome to answer" > - "because of of memory management and memory management and memory > management? " I don't know quite what this is trying to say, but it's > definitely got one "of" too many. > > ...and that's all as far as I've read (the beginning of the "Methods" > section. > > Jim > > > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From piyokun at gmail.com Mon Mar 20 19:52:34 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 09:52:34 +0900 Subject: [rhg-discussion] Hello In-Reply-To: <53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org> References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> <53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org> Message-ID: <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com> Here's the most of the second grouping of Jim Driscoll's corrections in diff format. Again I say most because he has multiple suggestions for some points. Index: chapter02.txt =================================================================== --- chapter02.txt (revision 8) +++ chapter02.txt (working copy) @@ -406,14 +406,14 @@ h2. Methods I already brought up the three important points of a Ruby object, that is -having an identity, being able to call a method, keeping data for each +having an identity, being able to call a method, and keeping data for each instance. In this section, I'll explain in a simple way the structure linking objects and methods. h3. `struct RClass` -In Ruby, class exist as objects during the execution. Of course. So there must -be a structure for class objects. That structure is `struct RClass`. Its +In Ruby, classes exist as objects during the execution. Of course. So there +must be a structure for class objects. That structure is `struct RClass`. Its structure type flag is `T_CLASS`. As class and modules are very similar, there is no need to differentiate their @@ -434,12 +434,12 @@ First, let's focus on the `m_tbl` (Method TaBLe) member. `struct st_table` is an hashtable used everywhere in `ruby`. Its details will be explained in the -next chapter "Names and name tables", but anyway they are objects that keep -one to one relations correspondence. In the case of `m_tbl`, it keeps the +next chapter "Names and name tables", but basically, it is a table mapping +names to objects. In the case of `m_tbl`, it keeps the correspondence between the name (`ID`) of the methods possessed by this class and the methods entity itself. -The fourth member `super` keeps, like its name says, the superclass. As it's a +The fourth member `super` keeps, like its name suggests, the superclass. As it's a `VALUE`, it's (a pointer to) the class object of the superclass. In Ruby there is only one class that has no superclass (the root class): `Object`. @@ -459,7 +459,7 @@ h3. Methods search -Classes being structured like this, you can easily imagine the method call +With classes structured like this, you can easily imagine the method call process. The `m_tbl` of the object's class is searched, and if the method was not found, the `m_tbl` of `super` is searched, and so on. If there is no more `super`, that is to say the method was not found even in `Object`, then it @@ -550,7 +550,7 @@ `rb_raise()` and `rb_error_frozen()` are both error checks. Error checks are -necessary, but it's not the main part of the treatment, so you have to ignore +necessary, but it's not the main part of the treatment, so you should ignore them at first read. After removing error treatment, only the `switch` remains, but this @@ -570,8 +570,8 @@ special treatment is done to properly return `T_FIXNUM` and `T_SYMBOL`, so there's no need to worry. -Well, let's go back to `rb_ivar_set()`. It seems only the treatment of -`T_OBJECT`, `T_CLASS` and `T_MODULE` is different. These 3 have been chosen on +Well, let's go back to `rb_ivar_set()`. It seems only the treatments of +`T_OBJECT`, `T_CLASS` and `T_MODULE` are different. These 3 have been chosen on the basis that their second member is `iv_tbl`. Let's confirm it in practice. ?? Structures whose second member is `iv_tbl` @@ -607,13 +607,13 @@ `ROBJECT()` is a macro that casts a `VALUE` into a `struct RObject*`. It's -possible that `obj` points to a struct RClass, but as we only access the -second member no problem will occur. +possible that `obj` points to a struct RClass, but as we're only going to access the +second member, it won't cause a problem. `st_init_numtable()` is a function creating a new `st_table`. `st_insert()` is a function doing associations in a `st_table`. -In conclusion, this code does the following: if `iv_tbl` does not exists, it +In conclusion, this code does the following: if `iv_tbl` does not exist, it creates it, then stores the [variable name ??object] association. Warning: as `struct RClass` is a class object, this instance variable table is @@ -707,10 +707,10 @@ `st_add_direct()` is similar to `st_insert()`, but the part before adding the association that checks if the key was already stored or not is different. In -other words, in the case of `st_add_direct()`, is a key already registered is +other words, in the case of `st_add_direct()`, if a key already registered is being used, two associations linked to this same key will be stored. `st_add_direct()` can be used when the check for existence has already been -done, like it is the case here, or when a new table has just been created. +done, as is the case here, or when a new table has just been created. `FL_SET(obj, FL_EXIVAR)` is the macro that sets the `FL_EXIVAR` flag in the `basic.flags` of `obj`. The `basic.flags` flags are all named `FL_xxxx` and @@ -761,7 +761,7 @@ such a functionality looks stupid. If you take all this into consideration, you can conclude that increasing the -size of object structures does not bring any good. +size of object structures does not do any good. h3. `rb_ivar_get()` On 3/21/06, Jim Driscoll wrote: > hi again, > > On 20 Mar 2006, at 21:39, Jim Driscoll wrote: > > > > > ...and that's all as far as I've read (the beginning of the "Methods" > > section. > > > > I suddenly have more time to kill, so here's some more: > > - "that is having an identity, being able to call a method, keeping > data for each instance" should read "that is having an identity, > being able to call a method, and keeping data for each instance" > - "In Ruby, class exist as objects during the execution" should be > something like "In Ruby, classes exist as objects at runtime" > - "but anyway they are objects that keep one to one relations > correspondence" should be "but anyway, they are objects that maintain > one to one relationships" or perhaps "but basically, it is a table > mapping names to objects". I don't fully grok struct st_table, but I > believe it's intended to be used for looking up objects from > identifiers (whether string or otherwise). > - "The fourth member super keeps, like its name says, the superclass" > should be "The fourth member super keeps, like its name suggests, the > superclass" > - "Classes being structured like this, you can easily imagine the > method call process" should be "With classes structured like this, > you can easily imagine the method call process" > - "Error checks are necessary, but it's not the main part of the > treatment, so you have to ignore them at first read" should be "Error > checks are necessary, but it's not the main part of the treatment, so > you should ignore them for now"... but I'll also point out that > "treatment" is a very rarely used word in this sense; another may be > easier to read. > - " It seems only the treatment of T_OBJECT, T_CLASS and T_MODULE is > different" should be " It seems only the treatments of T_OBJECT, > T_CLASS and T_MODULE are different" > - "It's possible that obj points to a struct RClass, but as we only > access the second member no problem will occur" should be "It's > possible that obj points to a struct RClass, but as we're only going > to access the second member, it won't cause a problem" > - "if iv_tbl does not exists, it creates it" should be "if iv_tbl > does not exist, it creates it" > - " In other words, in the case of st_add_direct(), is a key already > registered" should be "In other words, in the case of st_add_direct > (), if a key already registered" > - "st_add_direct() can be used when the check for existence has > already been done, like it is the case here" should be "st_add_direct > () can be used when the check for existence has already been done, as > is the case here" > - "If you take all this into consideration, you can conclude that > increasing the size of object structures does not bring any good." > should be "If you take all this into consideration, you can conclude > that increasing the size of object structures does not do any good." > - rb_ivar_get(): (A), (B) and (C) seem to be out-of-order (the > letters themselves, that is) > > That's all up to "Structures for objects", although I think I've > missed a few things. > > Jim > > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From amrmalik at gmail.com Mon Mar 20 19:53:38 2006 From: amrmalik at gmail.com (AMR MALIK) Date: Mon, 20 Mar 2006 19:53:38 -0500 Subject: [rhg-discussion] Hello In-Reply-To: <7d9a1f530603200109h1c1aa7fwe6bbde2a47ab6aa9@mail.gmail.com> References: <7d9a1f530603190619y8c03563uce54c86b2b7e1b18@mail.gmail.com> <72CA85CE-389E-455C-9B9C-90716283ADA8@gmail.com> <7d9a1f530603200109h1c1aa7fwe6bbde2a47ab6aa9@mail.gmail.com> Message-ID: <7D5103C5-BDC5-4D25-9CF6-DFD050DD2506@gmail.com> Thanks, It looks like you have quite a few English speaking folks with Japanese experience to boot. I will try to do what some other members have done and submit diffs of items I think need work. Some have already been taken care of (you guys are fast! :) ) I will try to look for sections which are marked as "un-assigned" and go from there. -Amr On 20-Mar-06, at 4:09 AM, Vincent Isambart wrote: > Hi, > >> Hello, My name is Amr Malik and I read about this on the ruby mailing >> list. I don't know Japanese, so I can't help with translation, but if >> you need help proof-reading and maybe rejigging some of the english >> sentence structure, I'd be happy to help. I'm not too sure how >> exactly the ruby-forge submissions work. I can always post my >> contributions to the list and someone else can commit them for me? > > I don't think there's any formal way to ask to join the RubyForge > project. For the moment, the only persons having write access on the > repository are Laurent SANSONETTI and me. I prefer to only give access > to people having already made a few contributions. > > So for the time being, yes, just send your contributions to the ML. > > If you want to check and rewrite a few things, you can start with > chapter 2. > > If there are just a few things, you can just put them in a mail. > Otherwise, the best is to modify the text file used to generate the > HTML (chapter02.txt), and send either a modified version of it or just > a diff. > >> Thanks for all your effort and work to bring this excellent resource >> to the english speaking rubyists. > > You're welcome :) > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion From techml at sgtpepper.net Mon Mar 20 20:03:14 2006 From: techml at sgtpepper.net (Daigo Moriwaki) Date: Tue, 21 Mar 2006 10:03:14 +0900 Subject: [rhg-discussion] Hello In-Reply-To: <7d9a1f530603200059q2025f0efuebb50a1dfe1b3ffe@mail.gmail.com> References: <441E1246.1060905@sgtpepper.net> <7d9a1f530603200059q2025f0efuebb50a1dfe1b3ffe@mail.gmail.com> Message-ID: <441F50D2.1050208@sgtpepper.net> Vincent Isambart wrote: >I've got a sentence in chapter 6 that I have some problems with: >Ruby??????????????????????????????????????????????????????????????????????????????????????????????? >If you have problems translating it, rewriting it more simply in >Japanese will be great :). > > It says like this: The scopes of Ruby variables and constants are quit complicated because they (variables and constants) are sometimes inheritated or they (scopes) are sometimes looked for (outside / out of ) beyond the local scope. ( I recomend that / The easiest/better way to understand is) You should guess "Since it works (behaves) like this, the implementation should (would) be something.", comparing with (according to) the Ruby language specification. Thanks, Daigo -- Daigo Moriwaki beatles at sgtpepper dot net From rcoder at gmail.com Mon Mar 20 20:05:23 2006 From: rcoder at gmail.com (Lennon Day-Reynolds) Date: Mon, 20 Mar 2006 17:05:23 -0800 Subject: [rhg-discussion] Introduction Message-ID: <5d4c61240603201705q285487bcn86a3f7daa3c7d5eb@mail.gmail.com> I've just found out about this project, and I'd love to contribute. I've been coding in Ruby for about four years, and have a fair level of experience with C, including writing Ruby extension modules and embedding Ruby in C applications. Also, while I haven't used the skills in years, I was once fairly proficient in at least conversational Japanese; it may not matter much, but it's there. I'll read through the existing list archives and chapter that's already up; is there anything else I should do to get up to speed, aside from trying to refresh whatever Japanese may be left in my brain by this point? -Lennon From piyokun at gmail.com Mon Mar 20 20:16:22 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 10:16:22 +0900 Subject: [rhg-discussion] need to understand this figure In-Reply-To: <43d756720603201525ra40dcd3kcd7b21881840d20e@mail.gmail.com> References: <43d756720603201522l7078f5ebu1e152465d939e4c8@mail.gmail.com> <43d756720603201525ra40dcd3kcd7b21881840d20e@mail.gmail.com> Message-ID: <1f748ec60603201716s1ff34e82g24dcae77ae457e12@mail.gmail.com> > ?????????????????????????????????4?c??????????????????????????????????????5?? It was (already tentatively) translated http://rubyforge.org/plugins/scmsvn/viewcvs.php/chapter04.txt?root=rhg&view=markup "From this result, and moreover when thinking more deeply, we can think that the superclass's class must again be the superclass's singleton class. You'll understand with one more inheritance level (diagram 5)." Best regards, Clifford Caoile On 3/21/06, Meinrad Recheis wrote: > i see, one sentence refers to the "c" in figure 4. all i need is the > translation of this sentence: > > ?????????????????????????????????4?c??????????????????????????????????????5?? > > On 3/21/06, Meinrad Recheis wrote: > > please have a look at figures 4 and 5 in chapter 4. > > > > http://i.loveruby.net/ja/rhg/book/images/ch_class_metaclass.jpg > > http://i.loveruby.net/ja/rhg/book/images/ch_class_multi.jpg > > > > in this figure as far as i found out on my own (trying to find out > > which symbols mean class, singleton class, etc is real fun ^^) an > > object's singleton class is presented in brackets. (obj) is obj's > > singleton class. what i don't understand is the little "c". what does > > it stand for? > > regards, > > -- henon > > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From techml at sgtpepper.net Mon Mar 20 20:29:19 2006 From: techml at sgtpepper.net (Daigo Moriwaki) Date: Tue, 21 Mar 2006 10:29:19 +0900 Subject: [rhg-discussion] need to understand this figure In-Reply-To: <43d756720603201525ra40dcd3kcd7b21881840d20e@mail.gmail.com> References: <43d756720603201522l7078f5ebu1e152465d939e4c8@mail.gmail.com> <43d756720603201525ra40dcd3kcd7b21881840d20e@mail.gmail.com> Message-ID: <441F56EF.4030804@sgtpepper.net> Meinrad Recheis wrote: >i see, one sentence refers to the "c" in figure 4. all i need is the >translation of this sentence: > >?????????????????????????????????4?c??????????????????????????????????????5?? > > > It says: Imaging more from this result, the class (c in figure 4) of the super class should be (is likely to be) also a singleton class. Let's make an extra (another) inheritance. The class diagrams in this books always mean that a left one is an instance of a right class, an upper one is a super class of a down one. Thanks, Daigo -- Daigo Moriwaki beatles at sgtpepper dot net From techml at sgtpepper.net Mon Mar 20 20:41:36 2006 From: techml at sgtpepper.net (Daigo Moriwaki) Date: Tue, 21 Mar 2006 10:41:36 +0900 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> Message-ID: <441F59D0.3060408@sgtpepper.net> Meinrad Recheis wrote: I think we should use original text-style diagrams for ones in this chapter, not graphical ones, because the diagrams are sensitive, the key to understand, and items of them have multple meanings. I feel text-style one is very good enough. >and annother one expressing the infinite loop even better > > > We need to ckeck the Ruby implementation whether it uses an infinite loop. The diagrams depend on it. Thanks, Daigo -- Daigo Moriwaki beatles at sgtpepper dot net From piyokun at gmail.com Mon Mar 20 21:15:56 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 11:15:56 +0900 Subject: [rhg-discussion] Some project suggestions Message-ID: <1f748ec60603201815i37d255f7h531f16aebc4148f0@mail.gmail.com> Hi Vincent Isambart, RHG-disucssion: If I may be permitted to make some suggestions outside the scope of the actual translation effort: (Actually, when I reviewed this email, some comments may put off some people as it might suggest a higher bar to contribute. But I believe it is would help out discussion further.) 1. When suggesting corrections, encourage and recommend posting "diff" patches based on subversion instead of "A should be B" posts. It's easier on the contributor: How? All the contributor has to do is checkout the project via Subversion (svn checkout svn://rubyforge.org/var/svn/rhg) and edit the text file (i.e. chapter02.txt) in-place. Then run svn diff command line tool (i.e. svn diff chapter02.txt) or if using TortoiseSVN, create a patch file (right click on the editing folder, select TortoiseSVN -> Create Patch, and select the changed files) and paste the results in the mail (and optionally attach). This has four added benefits: (1) We can see which version is being commented on. This is very important. (2) The patch can be easily be applied mechanically. (3) The contributor need not have to type "A" all the time and the editor can see exactly which part has changed. (4) The discussion or commenting of a particular correction can be done but stripped automatically. This is because all lines that don't start with "+" "-", or "@" are ignored because of the diff format. Of course, the use of the subversion or other diff tools is not a requirement at all. But perhaps by writing down this recommendation, people willing to contribute will also contribute in the same fashion. (I'm not going so far as to suggest people start sending in unit-tests of their patches too... ;-) But if it's possible to unit-test english, I'd recommend it too!) 2. I was going to suggest the canonical subversion directory structure of "trunk, tags, vendor" but perhaps because parts of the project can be fully completed while other parts may not be, perhaps it's unnecessary. (i.e. what would be tagged? what would it be named? when I look at svn:.../tags/ what should be in there? etc.) Keep up the great work! I am sure that this mailing list is going to be very busy very soon. Best regards, Clifford Caoile --- http://piyokun.googlepages.com From piyokun at gmail.com Mon Mar 20 22:39:33 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 12:39:33 +0900 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <441F59D0.3060408@sgtpepper.net> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> <441F59D0.3060408@sgtpepper.net> Message-ID: <1f748ec60603201939sd856bc7j406e25a1cbecb357@mail.gmail.com> I think the intent of what Meinrad Recheis is doing with the diagrams is good and I encourage the added semantic information, if it is exactly correct. I also like the gradient fill eye candy and it helps break up all that text, yowza. I suppose it may be confusing because the chapter that introduces all of the diagrams is Chapter 1, which is not yet translated. I took a look at the diagrams and the regular arrow (solid arrow filled) itself has multiple meanings. It seems this same arrow means, in addition to the implied "is a" or "has a" or "changes (in time) to": "references" http://i.loveruby.net/ja/rhg/book/images/ch_minimum_reference.jpg "is in enclosing scope" http://i.loveruby.net/ja/rhg/book/images/ch_minimum_constref.jpg "is a (Ruby) mixin between a and c" http://i.loveruby.net/ja/rhg/book/images/ch_minimum_modclass.jpg "is a instance of" http://i.loveruby.net/ja/rhg/book/images/ch_minimum_metaobjects.jpg "requires, necessitates" http://i.loveruby.net/ja/rhg/book/images/ch_class_reqlink.jpg of course, in different contexts. Is this assessment correct? Is this a problem? Is the suggestion to make multiple distinct arrows that mean only one thing? I'm not sure, myself, but obviously there has to be some sort of compromise. But if you're reading the diagrams only, you need to be aware of the context. I think the original diagrams are confusing themselves and in general any effort to make them more succinct and exact is welcome. > and annother one expressing the infinite loop even better Take a look at http://i.loveruby.net/ja/rhg/book/images/ch_minimum_ccc which corresponds to your first sample and http://i.loveruby.net/ja/rhg/book/images/ch_minimum_metaobjects.jpg which corresponds to your second sample. For this ch04-diagram02, you should stick with the ellipsis expression, because the idea is not that it points to itself, but the "next thing following (do the same operation again)" is exactly itself. > We need to ckeck the Ruby implementation whether it uses an infinite > loop. The diagrams depend on it. In this particular example, Minero AOKI is explaining the concept (appearance), not the actual implementation, in fact he used the words infinite loop here. The rest of that section deals with the implementation. So I don't believe this area needs correction. Best regards, Clifford Caoile --- http://piyokun.googlepages.com On 3/21/06, Daigo Moriwaki wrote: > Meinrad Recheis wrote: > > I think we should use original text-style diagrams for ones in this > chapter, not graphical ones, because the diagrams are sensitive, the key > to understand, and items of them have multple meanings. I feel > text-style one is very good enough. > > >and annother one expressing the infinite loop even better > > > > > > > We need to ckeck the Ruby implementation whether it uses an infinite > loop. The diagrams depend on it. > > Thanks, > Daigo > > -- > Daigo Moriwaki > beatles at sgtpepper dot net > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From vincent.isambart at gmail.com Tue Mar 21 04:21:05 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Tue, 21 Mar 2006 10:21:05 +0100 Subject: [rhg-discussion] Welcome, and many other things Message-ID: <7d9a1f530603210121q4e7c8917h6d0ad68d8f79d229@mail.gmail.com> Hi everyone, First welcome to all who joined :-). I will not answer to all mails individually but I've read everything :-). For the corrections of the files already in SubVersion, of course you're welcome to send those as patches. I did not say it because it seemed natural for me :P. I already integrated Tim Copeland's typo patch (even if did it manually because it was just one word). I also made some small improvements to chapter 4 (but nothing big, there's still some bad sentences in it), and the images are now centered in the HTML files generated by generate_html.rb. You can already see the results on the web page. For the people who want to translate from Japanese (GREAT! :)), you can choose any chapter you want except 2, 4 and 6 as those are already (partly) translated. I think the best is just to say on which chapter you want to work on the ML to be sure there's not 2 people on the same chapter. You can also choose something smaller than a chapter as some are quite big. For translating from Japanese, just start from the text file in the japanese/ directory of the SVN repository. First copy it in the same directory as the other translated chapters. You can then run generate_html.rb to generate the HTML. One thing: do not forget the erratas (http://i.loveruby.net/ja/rhg/errata.html) or if you're working on chapter 14 the big rewrite of one part (http://i.loveruby.net/ja/rhg/ev_const_get.html). I DID forget the errata in the versions released friday but I corrected that sunday. Someone asked if it was possible to work on a French translation (http://linuxfr.org/~floupi/21196.html), so I'll answer here about any translation. There's no problem at all with that, and it was one of the reasons for choosing a ShareAlike Creative Common. Personnaly I think I will continue to translate to English, but if someone prefers to make Japanese->French translation, it should not be too hard to find someone translating French to English. If other people wants to translate to other languages, it may be a good idea to change a little the directory structure in SVN. What do you think? PS: Please do not use my full name, "Vincent ISAMBART" is too long ;). Just call me "Vincent" or "scritch", like you want :). Cheers, Vincent From vincent.isambart at gmail.com Tue Mar 21 04:30:32 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Tue, 21 Mar 2006 10:30:32 +0100 Subject: [rhg-discussion] Hello In-Reply-To: <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com> References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> <53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org> <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com> Message-ID: <7d9a1f530603210130x7c0355bbo3a1d6609dae3f27b@mail.gmail.com> Thanks for all the corrections and the conversion in diff :-). I do not think I will have to commit this today, but I'll do it tomorrow. From vincent.isambart at gmail.com Tue Mar 21 05:20:01 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Tue, 21 Mar 2006 11:20:01 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <1f748ec60603201939sd856bc7j406e25a1cbecb357@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> <441F59D0.3060408@sgtpepper.net> <1f748ec60603201939sd856bc7j406e25a1cbecb357@mail.gmail.com> Message-ID: <7d9a1f530603210220p105ead96n6d1314502c8c703e@mail.gmail.com> Hi, My remarks about the last version of the diagram are the following: - In the original diagram obj may be any object, not necessarily an instance of Object, and I thionk it's the purpose here. - It looks like obj is Object itself, not an instance of it. And I agree with what Clifford said: even if in C there are singleton classes between rb_cClass->class and rb_cClass (like showed in diagram 9), I think the goal of the 2nd diagram is to show the infinite loop. I forgot one thing: the Japanese diagram 9 of chapter 4 has one mistake: the inheritance arrows between the singleton classes are missing ((Class) inherits from (Module) and (Module) from (Object)). (it's in the errata) Cheers, Vincent From stevenbristol at gmail.com Tue Mar 21 06:35:51 2006 From: stevenbristol at gmail.com (Steven A Bristol) Date: Tue, 21 Mar 2006 06:35:51 -0500 Subject: [rhg-discussion] hello Message-ID: <396d7d2d0603210335x23f11d4bg8e01984c16e92faf@mail.gmail.com> I just found the the http://rhg.rubyforge.org/ page and thought I might be able to help. I can read/write C and Ruby and I am a native English speaker. I can give three to four hours per week to help in any way. -- Thank you, Steven A Bristol stevenbristol at gmail.com From piyokun at gmail.com Tue Mar 21 07:25:01 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Tue, 21 Mar 2006 21:25:01 +0900 Subject: [rhg-discussion] Welcome, and many other things In-Reply-To: <7d9a1f530603210121q4e7c8917h6d0ad68d8f79d229@mail.gmail.com> References: <7d9a1f530603210121q4e7c8917h6d0ad68d8f79d229@mail.gmail.com> Message-ID: <1f748ec60603210425n66e05eb1m84782d414dd68e78@mail.gmail.com> Vincent ISAMBART (I mean Vincent): Thanks for the welcome and thank you for securing this Ruby resource. Do you mind if I start translating the first part of chapter 3 ("st_table": ?? and ??????????) from Japanese to English? It seems relatively small and managable (famous last words). It would also be good to know your opinion on which chapters or sections are higher priority than others. Thanks for remind to read the erratas, I totally forgot this part. (http://i.loveruby.net/ja/rhg/errata.html) Best regards, Clifford Caoile -- http://piyokun.GooglePages.com On 3/21/06, Vincent Isambart wrote: > Hi everyone, > > First welcome to all who joined :-). I will not answer to all mails > individually but I've read everything :-). > > For the corrections of the files already in SubVersion, of course > you're welcome to send those as patches. I did not say it because it > seemed natural for me :P. I already integrated Tim Copeland's typo > patch (even if did it manually because it was just one word). > > I also made some small improvements to chapter 4 (but nothing big, > there's still some bad sentences in it), and the images are now > centered in the HTML files generated by generate_html.rb. You can > already see the results on the web page. > > For the people who want to translate from Japanese (GREAT! :)), you > can choose any chapter you want except 2, 4 and 6 as those are already > (partly) translated. I think the best is just to say on which chapter > you want to work on the ML to be sure there's not 2 people on the same > chapter. You can also choose something smaller than a chapter as some > are quite big. > For translating from Japanese, just start from the text file in the > japanese/ directory of the SVN repository. First copy it in the same > directory as the other translated chapters. You can then run > generate_html.rb to generate the HTML. One thing: do not forget the > erratas (http://i.loveruby.net/ja/rhg/errata.html) or if you're > working on chapter 14 the big rewrite of one part > (http://i.loveruby.net/ja/rhg/ev_const_get.html). I DID forget the > errata in the versions released friday but I corrected that sunday. > > Someone asked if it was possible to work on a French translation > (http://linuxfr.org/~floupi/21196.html), so I'll answer here about any > translation. There's no problem at all with that, and it was one of > the reasons for choosing a ShareAlike Creative Common. Personnaly I > think I will continue to translate to English, but if someone prefers > to make Japanese->French translation, it should not be too hard to > find someone translating French to English. > If other people wants to translate to other languages, it may be a > good idea to change a little the directory structure in SVN. > > What do you think? > > PS: Please do not use my full name, "Vincent ISAMBART" is too long ;). > Just call me "Vincent" or "scritch", like you want :). > > Cheers, > Vincent > > _______________________________________________ > rhg-discussion mailing list > rhg-discussion at rubyforge.org > http://rubyforge.org/mailman/listinfo/rhg-discussion > From vincent.isambart at gmail.com Tue Mar 21 07:44:33 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Tue, 21 Mar 2006 13:44:33 +0100 Subject: [rhg-discussion] Translation from Japanese Message-ID: <7d9a1f530603210444s1ac9b2c0n5ca0cb01ef003c9@mail.gmail.com> Hi, I forgot to mention a few points about translating form Japanese in my previous mail, so I'll develop it a little more here. There's some repetition with my previous mail but this one is much more complete. Anyone who wants to translate a chapter or a part of a chapter just says which one he wants to translate on this mailing list. If he changes his mind, or does not have time to translate, he just says so, still on this mailing list. He can of course send what he has already translated. Nothing complicated :-). An order of priority for the translations will be in my next mail, as this mail is already long enough ;). Some were wondering how to refresh their Japanese, and I only have one answer: translate :). At least try to read first what you want to translate, and if you feel you can do it, just say it. And if finally you can't, just send another mail telling you give up. If you have any sentence you have problems understanding, or want some advice, do not hesitate to ask on the ML. A little warning: ALL FILES ARE IN UTF-8 (even the files in the japanese/ directory, the convert_html.rb script does the ISO-2022-JP to UTF-8 conversion automatically) and I think it should stay like this. I used emacs bu you can use any editor you like that supports UTF-8 (but I would recommend not to use TextMate because the way it displays wide characters is illegible). I would recommend one with an autofilling function (make the text less than X columns wide, automatically add/remove spaces), but be careful not to break the code. To start translating a chapter, you copy the file of the chapter from the japanese/ directory to the main directory. Note that the erratas are not applied so do not forget them (http://i.loveruby.net/ja/rhg/errata.html and for chapter 14 http://i.loveruby.net/ja/rhg/ev_const_get.html). Then add a line "Translation by XXXXXX" with XXXXXX replaced with your name (it may also be a list of names) at the top. Here is a summary of the format used: - all the Textile commands work (http://hobix.com/textile/) - all http/ftp addresses are automatically transformed to links - you can use $include(filename)$ to include the content of a file. This was done to split the files in sections but has not been done yet. - The images are automatically put in a new paragraph, centered and their title is automatically written below with the number of the diagram. - you can (and should) put code between ` (backquotes), because I think the standard @ of textile has a few problems: * There can't be any end of line between the two @ (that's one of the reasons why there was some @ left in the first version of chapter 2). That's quite bothersome when you use some autofilling in your text editor which can break for example @struct RStruct@ in two... * You can't put any character (except spaces/punctuation) after an ending @. There can be end of lines between backquotes and any character after the ending one. The only downside is that you can't use the backquote character in the text itself but I do not see why this would be a problem. They can still be used in and 
. If you really
want to use them in small examples of code, use  instead
of @ or `. If you want to use them to end a simple quote notation,
just use the normal quote character, Textile converts them
automatically to curly quotes.

Do not hesitate to check chapter02.txt and chapter04.txt.

If you see anything missing of have any bug, do not hesitate to tell me.

I'm really happy to have many people helping :-)


From vincent.isambart at gmail.com  Tue Mar 21 08:14:10 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Tue, 21 Mar 2006 14:14:10 +0100
Subject: [rhg-discussion] Order of priority
Message-ID: <7d9a1f530603210514h6e14813ep1610063bf1c52768@mail.gmail.com>

Many people have asked for an order of priority, so here comes what I
think about it.

There is no real priority on the order of translation of the chapters.
This is done during your free time so choose the chapters you are
interested in :-). The only reason I may have for refusing someone to
translate a chapter is that someone already started it. The goal is to
translate the full book after all. The only recommendation I would
have is even if a part at the end of a chapter is more interesting
that the beginning, it's generally better to start with the beginning.

But if you still want some help choosing, here are some elements to help you.

It may be a good idea to finish the first part (objects) before
starting the second one (syntax analysis). However I do not think
translating chapter 1 is really important, as it's an introduction to
the Ruby language. Clifford pointed out that it at least introduces
the representations in the diagrams, but if necessary that can be done
on a different page.

In this first part, if think many people would be interested by the
5th chapter on garbage collection, but it's quite long. In chapter 3,
I think the most important section is the last one (ID and symbols).

For the preface and introduction, I'm not sure they are really
important to translate. The preface is not very long, but the Japanese
names are difficult to get right ;). I have not checked the
introduction much, but some parts are not really interesting (what is
CVS, how to build ruby, autoconf, make).

For the other parts of the book, I do not have much to say. The
introduction to yacc may not be very important. However, if I think
requiring people to know Ruby and C is not a problem, requiring people
to know yacc may be a little too much.

A little problem is that many chapters seem to rely on knowledge on
knowledge learned on previous chapter. There is nothing astonishing in
that but it will be harder to translate if you do not understand some
parts because you did not read the previous chapter(s).


Personnaly, after chapter 2, I chose the number 4 because I was not
really interested in translating the introduction to how hash tables
work that consist most of chapter 3. After removing the last Japanese
sentence I was more interested in keeping on translating and started
chapter 6 before even correcting my crappy sentences in my translation
of chapter 4. I chose the 6th one because chapter 5 is really long,
and full of diagrams.

The next points I will do are:
- continue improving chapter 4, then ask for corrections by native speakers.
- finish translating chapter 6 (I just have to copy and modify a
little what sent me Daigo), then improve it and ask for corrections.
- choose an other chapter :-)


From vincent.isambart at gmail.com  Tue Mar 21 09:50:50 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Tue, 21 Mar 2006 15:50:50 +0100
Subject: [rhg-discussion] Welcome, and many other things
In-Reply-To: <1f748ec60603210425n66e05eb1m84782d414dd68e78@mail.gmail.com>
References: <7d9a1f530603210121q4e7c8917h6d0ad68d8f79d229@mail.gmail.com>
	<1f748ec60603210425n66e05eb1m84782d414dd68e78@mail.gmail.com>
Message-ID: <7d9a1f530603210650n7e01c7a6l6f226c57f3306cf5@mail.gmail.com>

> Do you mind if I start translating the first part of chapter 3
> ("st_table": ?? and ??????????) from Japanese to English? It seems
> relatively small and managable (famous last words).
No problem, go on :)

From j at rjimlad.org  Tue Mar 21 13:43:50 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Tue, 21 Mar 2006 18:43:50 +0000
Subject: [rhg-discussion] Typo in chapter 2
Message-ID: 

I don't think RStrict is meaningful - it's probably a typo.

Index: chapter02.txt
===================================================================
--- chapter02.txt       (revision 9)
+++ chapter02.txt       (working copy)
@@ -930,7 +930,7 @@
of `len` or `capa` will no more agree with the content, and also  
because when
modifying strings created as litterals, `aux.shared` has to be  
separated.
-To finish this section about `RStrict`, let's write some examples  
how to use
+To finish this section about `RString`, let's write some examples  
how to use
it. `str` is a `VALUE` that points to `RString`.



From j at rjimlad.org  Tue Mar 21 13:55:27 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Tue, 21 Mar 2006 18:55:27 +0000
Subject: [rhg-discussion] The rest of chapter 2
Message-ID: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>

Okay, I've gone through the rest of the chapter. I have actually  
written Ruby extension code before, and this all basically made sense  
to me.

However, the section:

`ifnone` is the value when a key does not have an attached value, its  
default
is `nil`. `iter_lev` is to make the hashtable reentrant (multithread  
safe).

...seems wrong to me. It should be talking about if the key does not  
exist, surely? Because if it exists and has a nominally undefined  
value, it should return that, not the default.

Anyway, patch follows for the (translation) problems I could easily  
find in the rest of the chapter.

Index: chapter02.txt
===================================================================
--- chapter02.txt       (revision 9)
+++ chapter02.txt       (working copy)
@@ -856,8 +856,8 @@
Rather than a string, Ruby's string is more a byte array, and can  
contain any
byte including `NUL`. So when thinking at the Ruby level, ending the  
string
-with `NUL` does not mean anything. But as C functions require `NUL`,  
for
-convenience the ending `NUL` is there. However, it is not included  
in `len`.
+with `NUL` does not mean anything. As C functions require `NUL`, for
+convenience the ending `NUL` is there, however, it is not included  
in `len`.
When dealing with a string coming from the interpreter or an extension
library, you can write `RSTRING(str)->ptr` or `RSTRING(str)->len`,  
and access
@@ -870,10 +870,10 @@
Why is that? First, there is an important software engineering  
principle:
Don't arbitrarily tamper with someone's data. Interface functions are  
there
-for a reason. However, there are concretely reasons in `ruby`'s  
construction
+for a reason. However, there are concrete reasons in `ruby`'s design
why you should not do such things as consulting or storing a pointer,  
and
that's related to the fourth member `aux`. However, to explain  
properly how to
-use `aux`, we have to explain first a little more of Ruby's strings
+use `aux`, we have to explain first a little more of Ruby's strings'
characteristics.
Ruby's strings can be modified (are mutable). By mutable I mean after  
the
@@ -886,10 +886,10 @@


the content of the object pointed by `s` will become "`string`". It's
-different from Java or Python string objects. Java's  
`StringBuffer`'s closer.
+different from Java or Python string objects. Java's `StringBuffer`  
is closer.
And what's the relation? First, mutable means the length (`len`) of  
the string
-can change. We have to increase or reduce the allocated memory size  
each time
+can change. We have to increase or decrease the allocated memory  
size each time
the length changes. We can of course use `realloc()` for that, but  
generally
`malloc()` and `realloc()` are heavy operations. Having to `realloc() 
` each
time the string changes is a huge burden.
@@ -900,7 +900,7 @@
faster. The structure member `aux.capa` contains the length including  
this
additional memory.
-Well what is this other `aux.shared`? It's to speed up the creation  
of literal
+So what is this other value `aux.shared`? It's used to speed up the  
creation of literal
strings. Have a look at the following Ruby program.

@@ -912,14 +912,14 @@


Whatever the number of times you repeat the loop, the fourth line's  
`p` has to
-show `"string"`. That's why the code `"str"` should create each time  
a string
+show `"string"`. That's why the code `"str"` should create, each  
time, a string
object holding a different `char[]`. However, if no change occurs for  
a lot of
-strings, useless copies of `char[]` can be done many times. It would  
be better
+strings, useless copies of `char[]` can be created many times. It  
would be better
to share one common `char[]`.
The trick that allows this to happen is `aux.shared`. String objects  
created
with a literal use one shared `char[]`. When a change occurs, the  
string is
-copied in dedicated memory and the change is done on this new copy.  
This
+copied to unshared memory, and the change is done on this new copy.  
This
technique is called "copy-on-write". When using a shared `char[]`,  
the flag
`ELTS_SHARED` is set in the object structure's `basic.flags`, and  
`aux.shared`
contains the original object. `ELTS` seems to be the abbreviation of
@@ -927,7 +927,7 @@
But, well, let's return to our talk about `RSTRING(str)->ptr`. Even if
consulting the pointer is OK, you must not modify it, first because  
the value
-of `len` or `capa` will no more agree with the content, and also  
because when
+of `len` or `capa` will no longer agree with the content, and also  
because when
modifying strings created as litterals, `aux.shared` has to be  
separated.
To finish this section about `RStrict`, let's write some examples how  
to use
@@ -972,7 +972,7 @@
 From this structure, it's clear that Ruby's `Array` is an array and  
not a
list. So when the number of elements changes in a big way, a `realloc 
()` must
be done, and if an element must be inserted at an other place than  
the end, a
-`memmove()` will occur. But even if we do it, it's moving so fact  
it's really
+`memmove()` will occur. But even if we do it, it's moving so fast  
it's really
impressive on current machines.
That's why the way to access it is similar to `RString`. You can consult
@@ -1042,7 +1042,7 @@
h3. `struct RFile`
-`struct RFile` is a structure for the instances of the built-in IO  
class and
+`struct RFile` is a structure for instances of the built-in IO class  
and
its subclasses.
? `struct RFile`
@@ -1070,8 +1070,8 @@
(rubyio.h)
-All members have been transfered in `struct OpenFile`. As there aren't many -instances of `IO` objects, it's OK to do it like this. The use of each member +All members have been transferred in `struct OpenFile`. As there aren't many +instances of `IO` objects, it's OK to do it like this. The purpose of each member is written in the comments. Basically, it's a wrapper around C's `stdio`. h3. `struct RData` @@ -1101,7 +1101,7 @@ `dfree` is the function used to free this structure, and `dmark` is the function for when the "mark" of the mark and sweep occurs. -As whatever we do, explaining `struct RData` is still too complicated, so for +Because explaining `struct RData` is still too complicated, for the time being let's just look at its representation (diagram 8). You'll read a detailed explanation of its members in chapter 5 "Garbage collection" where there'll be presented once again. From j at rjimlad.org Tue Mar 21 13:59:10 2006 From: j at rjimlad.org (Jim Driscoll) Date: Tue, 21 Mar 2006 18:59:10 +0000 Subject: [rhg-discussion] Hello In-Reply-To: <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com> References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org> <53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org> <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com> Message-ID: Hi Clifford, On 21 Mar 2006, at 00:52, Clifford Caoile wrote: > Here's the most of the second grouping of Jim Driscoll's corrections > in diff format. Again I say most > because he has multiple suggestions for some points. > Actually, I thought it better to put my recommendations out there before making a diff (because diff can be rather hard to read for subtle changes), but I suppose it is useful to be able to look at the changes in context too! And my surname's cumbersome, so call me Jim or JD. Still, thanks for going to the effort of making a diff from my various suggestions. Jim From meinrad.recheis at gmail.com Tue Mar 21 15:18:08 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Tue, 21 Mar 2006 21:18:08 +0100 Subject: [rhg-discussion] please review ch04-diagram02 In-Reply-To: <1f748ec60603201939sd856bc7j406e25a1cbecb357@mail.gmail.com> References: <43d756720603200424i196da87eu123dec92e4ca707d@mail.gmail.com> <7d9a1f530603200444u5b4aa7e5o87f8688ceed56aab@mail.gmail.com> <43d756720603201014t5e0400d6v756856b2499a1e38@mail.gmail.com> <43d756720603201126i7857427ew7a3eb6bd23b9ef9a@mail.gmail.com> <43d756720603201148h738b8a1ft13959f838b090ef0@mail.gmail.com> <441F59D0.3060408@sgtpepper.net> <1f748ec60603201939sd856bc7j406e25a1cbecb357@mail.gmail.com> Message-ID: <43d756720603211218g415f3240n6521a78affed213@mail.gmail.com> On 3/21/06, Clifford Caoile wrote: > I think the intent of what Meinrad Recheis is doing with the diagrams > is good and I encourage the added semantic information, if it is > exactly correct. I also like the gradient fill eye candy and it helps > break up all that text, yowza. thanks ;) > > I suppose it may be confusing because the chapter that introduces all > of the diagrams is Chapter 1, which is not yet translated. I took a > look at the diagrams and the regular arrow (solid arrow filled) itself > has multiple meanings. It seems this same arrow means, in addition to > the implied "is a" or "has a" or "changes (in time) to": > > "references" > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_reference.jpg > > "is in enclosing scope" > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_constref.jpg > > "is a (Ruby) mixin between a and c" > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_modclass.jpg > > "is a instance of" > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_metaobjects.jpg > > "requires, necessitates" > http://i.loveruby.net/ja/rhg/book/images/ch_class_reqlink.jpg > > of course, in different contexts. Is this assessment correct? Is this > a problem? Is the suggestion to make multiple distinct arrows that > mean only one thing? i am trying to. discussions will show whether it is good or not. > I'm not sure, myself, but obviously there has to > be some sort of compromise. But if you're reading the diagrams only, > you need to be aware of the context. > > I think the original diagrams are confusing themselves and in general > any effort to make them more succinct and exact is welcome. > > > and annother one expressing the infinite loop even better > Take a look at > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_ccc > which corresponds to your first sample > and > http://i.loveruby.net/ja/rhg/book/images/ch_minimum_metaobjects.jpg > which corresponds to your second sample. > For this ch04-diagram02, you should stick with the ellipsis > expression, because the idea is not that it points to itself, but the > "next thing following (do the same operation again)" is exactly > itself. ok i will use the version with the ellipsis. > > Best regards, > Clifford Caoile On 3/21/06, Vincent Isambart wrote: > Hi, > > My remarks about the last version of the diagram are the following: > - In the original diagram obj may be any object, not necessarily an > instance of Object, and I thionk it's the purpose here. > - It looks like obj is Object itself, not an instance of it. > > And I agree with what Clifford said: even if in C there are singleton > classes between rb_cClass->class and rb_cClass (like showed in diagram > 9), I think the goal of the 2nd diagram is to show the infinite loop. so do i think and therefore it's not so very important what "obj" is supposed to be in the original diagram. the variant with the code fragment and the ellipsis should represent the concept of the infinite loop exactly. From j at rjimlad.org Tue Mar 21 15:28:23 2006 From: j at rjimlad.org (Jim Driscoll) Date: Tue, 21 Mar 2006 20:28:23 +0000 Subject: [rhg-discussion] Some chapter 4 corrections/tweaks Message-ID: <27F7029B-6171-476E-B135-D468357953D5@rjimlad.org> There are actually some sections of this where I really fail to understand what's intended to be said (although the actual meaning is clear enough), so I've generally avoided making any changes to such sections. Index: chapter04.txt =================================================================== --- chapter04.txt (revision 9) +++ chapter04.txt (working copy) @@ -8,8 +8,8 @@ h2. Classes and methods definition First, I'd like to have a look at how Ruby classes are defined at the -C level. This chapter in some way investigates almost only particular -cases, so I'd like you to know first the way used most of the time. +C level. This chapter investigates almost only particular +cases, so I'd like you to know first the way used most often. The main API to define classes and modules consists of the following 6 functions: @@ -44,12 +44,12 @@ `rb_cObject` and `rb_cArray` correspond respectively to `Object` and `Array` at the Ruby level. The added prefix `rb` shows that it belongs -to `ruby` and the `c` that it is a a class objects. These naming rules +to `ruby` and the `c` that it is a class object. These naming rules are used everywhere in `ruby`. -Then, this call to `rb_define_class()` allows to define `Array` that -inherits from `Object`. At the same time `rb_define_class()` creates -the class object, it also defines the constant. That means after this +This call to `rb_define_class()` allows us to define `Array` that +inherits from `Object`. At the same time as `rb_define_class()` creates +the class object, it also defines the constant. That means that after this you can already access `Array` from a Ruby program. It corresponds to the following Ruby program: @@ -57,7 +57,7 @@ class Array < Object -I'd like you to be careful of the fact that there is no `end`. It was +I'd like you to note the fact that there is no `end`. It was written like this on purpose. It is because with `rb_define_class()` the body of the class has not been executed. @@ -85,7 +85,7 @@ class Stat < Object -This time again I omited the `end` on purpose. +This time again I omitted the `end` on purpose. h3. Module definition @@ -112,7 +112,7 @@ h3. Method definition -This time the function is the one defining methods, +This time the function is the one for defining methods, `rb_define_method()`. It's used very often. We'll take once again an example from `Array`. @@ -126,7 +126,7 @@ With this the `to_s` method is defined in `Array`. The method body is given by a function pointer (`rb_ary_to_s`). The fourth parameter is the number of parameters taken by the method. As `to_s` does not take -any parameter, it's 0. If we write the corresponding Ruby program, +any parameters, it's 0. If we write the corresponding Ruby program, we'll have this: 
@@ -184,9 +184,9 @@
h3. Entry point
-Then, being able to make definitions like before is great, but where
-are these functions called from, and by what means is it executed?
-These definitions are regrouped in functions named `Init_xxxx()`. For
+Being able to make definitions like before is great, but where
+are these functions called from, and by what means are they executed?
+These definitions are grouped in functions named `Init_xxxx()`. For
instance, for `Array` a function `Init_Array()` like this has been
made:
@@ -212,7 +212,7 @@
The `Init` for the built-in functions are explicitely called during -the startup of `ruby`. Concretely, they are in `inits.c`. +the startup of `ruby`. They are always in `inits.c`. ??? `rb_call_inits()` 
@@ -248,8 +248,8 @@
With this, if the loaded extension library is `myextention.so`, at
load time, the (`extern`) function named `Init_myextention()` is
-called. How they are called exceeds the range of this chapter. For
-this, you should read the chapter 18 "Load". Here we'll just end this
+called. How they are called is beyond the scope of this chapter. For
+that, you should read the chapter 18 "Load". Here we'll just end this
with an example of `Init`.
The following example is from `stringio`, an extension library
@@ -276,8 +276,8 @@
h3. `rb_define_singleton_method()`
-You should be able to more or less understand how normal methods are
-defined. Somehow, making the body of the method, then registering it
+You should now be able to more or less understand how normal methods  
are
+defined. Somehow making the body of the method, then registering it
in `m_tbl` will do. But what about singleton methods? We'll now look
into the way singleton methods are defined.
@@ -297,21 +297,21 @@
As I explained, `rb_define_method()` is a function used to define -normal methods, so the difference with normal methods is only -`rb_singleton_class()`. But what on earth are singleton class? +normal methods, so the difference from normal methods is only +`rb_singleton_class()`. But what on earth are singleton classes? -In one word, singleton classes are virtual classes that are only used +In brief, singleton classes are virtual classes that are only used to execute singleton methods. Singleton methods are functions defined in singleton classes. Classes themselves are in the first place (in a way) the "implementation" to link objects and methods, but singleton -classes are even more in the implementation side. In the Ruby language +classes are even more on the implementation side. In the Ruby language way, they are not formally included, and don't appear much at the Ruby level. h3. `rb_singleton_class()` Well, let's confirm what the singleton classes are made of. There is -no accomplishment in each time suddenly showing you the function so +no use in each time suddenly showing you the function so this time I'll use a new weapon, a call graph. 
@@ -339,13 +339,13 @@
Let's go back to the code. When looking at the call graph, you can see
that the calls made by `rb_singleton_class()` go very deep. Until now
all call levels were shallow, so we could simply look at the functions
-without getting too much lost. But with this depth, I easily forget
-what was going on in the code. That's why in those situations I check
+without getting too lost. But at this depth, I easily forget
+what is going on in the code. That's why in those situations I check
the call graph to have a better understanding. This time, we'll decode
in parallel what the procedures below `rb_singleton_class()` do.  The
two points to look out for are the following ones:
-* What concretely are singleton classes?
+* What exactly are singleton classes?
* What is the purpose of singleton classes?
h3. Normal classes and singleton classes
@@ -397,7 +397,7 @@
(class.c)
-`Check_Type()` is the check for the type of object structure type, so +`Check_Type()` is the check for the type of object structure, so we can ignore it. `rb_raise()` is error handling so we can ignore it. By doing this, only `rb_class_boot()` is left. So let's look at it too. @@ -451,7 +451,7 @@ Here also `rb_class_boot()` appears. So up to that point, it's the -same as in normal classes. What's going on after is is the difference +same as in normal classes. What's going on after is the difference between normal classes and singleton classes, that is the characteristics of singleton classes. If you understood up to there, we'll just read `rb_singleton_class()` and `rb_make_metaclass()`. @@ -514,12 +514,12 @@ case. In other words, that makes the second half the trunk. That's why we'll keep it for later and talk about the other part. -Everything that is handled in the first half are non-pointer `VALUE`, +Everything that is handled in the first half are non-pointer `VALUE`s, in other words objects without an existing C structure. First, `Fixnum` and `Symbol` are explicitely picked. Then, `rb_special_const_p()` is a function that returns true for non-pointer -`VALUE`, so there only `Qtrue`, `Qfalse` and `Qnil` should get -caught. Except that, there is no not pointer value so a bug is +`VALUE`s, so there only `Qtrue`, `Qfalse` and `Qnil` should get +caught. Other than that, there are no valid non-pointer values so a bug is reported with `rb_bug()`. `DEFER_INTS()` and `ALLOW_INTS()` both end with the same `INTS` so you @@ -608,11 +608,11 @@ Also, the `BUILTIN_TYPE()` of `rb_make_metaclass()` is similar to `TYPE()` as it is a macro to get the structure type flag (`T_xxxx`). So the condition means "if `obj` is a class" but for the -moment I do not want to limit ourselfs to `obj` being a class. That's +moment I do not want to limit ourselves to `obj` being a class. That's why we'll remove it. After thinking about the above conditions and synthesizing the -function, we get that: +function, we get this: ??? `rb_singleton_class() rb_make_metaclass()` (after recompression) 
@@ -641,7 +641,7 @@
Now it should very easy to understand. Furthermore, to make it -simpler, I reorganized what is done in a diagram (diagram 1). In the +simpler, I've reorganized what is done in a diagram (diagram 1). In the horizontal direction is the "instance - class" relation, and in the vertical direction is inheritance (the superclasses are above). @@ -658,7 +658,7 @@ By the way, you must have seen that during the compression process, the call to `rb_singleton_class_attached()` was stealthily -erased. Here: +removed. Here: 
rb_make_metaclass(obj, super)
@@ -669,7 +669,7 @@
      rb_singleton_class_attached(klass, obj);   /* this */
-Let's see in in this functions what it does. +Let's see in this function what it does. ??? `rb_singleton_class_attached()` 
@@ -698,10 +698,10 @@
`__attached__` does not have the `@` prefix, but as it's stored in the
instance variables table so it's still an instance variable. Such an
instance variable can never be read at the Ruby level so it can be
-used to keep values we do not want the user to see for the system
+used to keep values we do not want the user to see for the system's
exclusive use.
-Let's now also think about the relation between `klass` and
+Let's now also think about the relationship between `klass` and
`obj`. `klass` is the singleton class of `obj`.  In other words, this
is to remember the instance in the singleton class. This value is used
when the singleton class is changed, to do such things as calling hook
@@ -712,7 +712,7 @@
But is it really all right? Storing the instance in `__attached__`
will force a singleton class to have one attached instance. For
-example, by getting in some way or an other the singleton class and
+example, by getting (in one way or an other) the singleton class and
calling `new`, won't a singleton class end up having multiple
instances?
@@ -748,19 +748,19 @@
!images/ch_class_infloop.jpg(Infinite loop of classes)!
Up to here it's something we've already gone through. What's going
-after that is the theme of this chapter. Why class has to make a loop?
+after that is the theme of this chapter. Why does class have to make  
a loop?
-First, in Ruby all data is objects. And again in Ruby classes are data
+First, in Ruby all data are objects. And again in Ruby classes are data
so they have to be objects.
As they are objects, they must answer to methods. And setting the rule
"to answer to methods you must belong to a class" made processing
easier. That's where comes the need for a class to also have a class.
-Let's base ourself on this and think about the way to implement it.
+Let's base ourselves on this and think about the way to implement it.
First, we can think in the most na??ve way, `Class`'s class is
`ClassClass`, `ClassClass`'s class is `ClassClassClass`..., chaining
-class of classes one by one. But whatever the way you look at it, this
+classes of classes one by one. But whichever the way you look at it,  
this
can't be implemented effectively. That's why it's common in object
oriented languages where classes are objects that `Class`'s class is
to `Class` itself, creating an endless virtual instance-class
@@ -773,35 +773,35 @@
h4. "Class is also an object"
"Everything is an object" is often used as advertising statement when
-speaking about Ruby. And as a part of that, "Class are also object!"
+speaking about Ruby. And as a part of that, "Classes are also objects!"
also appears. But these expressions often go too far. To think about
this, we have to split them in two like this:
-* all data is objects
+* all data are objects
* classes are data
-When starting talking about data and code, a talk becomes much more
-hard to understand. It's better to, from now on, call data "things put
-in variables in programs", even if it's very restrictive.
+Discussion of data and code is very hard to understand. It's better
+to, from now on, call data "things put in variables in programs",
+even if it's a very restrictive definition.
-Being able to manipulate class from programs gives programs the
+Being able to manipulate classes from programs gives programs the
ability to manipulate themselves. This is called reflection. In object
-languages, and even more in Ruby that has classes it's only proper
-behavior to be able to manipulate directly classes.
+languages, and even more so in Ruby, it's appropriate to be able to
+directly manipulate classes.
-Nevertheless, there are way to have classes not made as object. For
-example, there is no problem at all in offering function style methods
+Nevertheless, there are way to have classes not made as objects. For
+example, there is no problem at all in offering function-style methods
to manipulate classes. However, as there are inside the interpreter
data structures that represent the classes, it's more natural to make
-them available direclty in object oriented languages. And Ruby did
+them available directly in object oriented languages. And Ruby did
that.
Furthermore, in Ruby the objective is all data to be objects. That's
why it's appropriate to make classes also objects.
-By the way, there is a an other reason than reflection why in Ruby
+By the way, there is a reason other than reflection why in Ruby
classes had to be made objects. That is to be able to define methods
-independent from instances, what is called static methods in Java in
+independent from instances: what is called static methods in Java in
C++.
And to implement static methods, one other thing was necessary:
@@ -812,7 +812,7 @@
h4. Class methods inheritance
-In Ruby singleton methods defined in class are called class methods,
+In Ruby singleton methods defined in a class are called class methods,
but their specification is a little strange. Why are class methods
inherited?
@@ -831,8 +831,8 @@
This can't occur with singleton methods from objects that are not
classes. In other words, classes are the only ones handled
-particularly. In this section we'll search how are inherited class
-methods.
+specially. In the following section we'll see how class methods
+are inherited.
h3. Singleton class of a class
@@ -856,8 +856,8 @@
If you're wondering where you've seen it before, we looked at it in -the previous section. At this time you did not see it but if you look -closely, why `rb_make_metaclass()` appears? As we saw +the previous section. At that time you did not see it but if you look +closely, why does `rb_make_metaclass()` appear? As we saw before, this function introduces a singleton class. This is very suspicious. Why is this called even if we do not define a singleton function? Furthermore, it's not `rb_singleton_class()`, why @@ -892,7 +892,7 @@ its superclass. `rb_name_class()`'s name means it names a class, but for the moment we do note care about names so we'll skip it. After that there's the `rb_make_metaclass()` in question. What's bothering -is that when called from `rb_singleton_class()`, the parameters were +us is that when called from `rb_singleton_class()`, the parameters were different. Last time was like this: 
@@ -905,8 +905,8 @@
rb_make_metaclass(klass, RBASIC(super)->klass);
-So as you can see it's slightly different. How does the result changes -depending on that, let's have once again a look at a +So as you can see it's slightly different. How do the results change +depending on that? Let's have once again a look at a simplified `rb_make_metaclass()`. h4. `rb_make_metaclass` (once more) @@ -956,7 +956,7 @@ Doing this as a diagram gives something like diagram 4. In it, the -names between parenthesis are singleton classes. This notation is +names between parentheses are singleton classes. This notation is often used in this book so I'd like you to remember it. This means that `obj`'s singleton class is written as `(obj)`. And the `(klass)` is the singleton class for `klass`. It looks like the singleton class @@ -970,10 +970,10 @@ !images/ch_class_multi.jpg(Hierarchy of multi-level inheritance)! -As the relation between `super` and `klass` is the same as the one +As the relationship between `super` and `klass` is the same as the one between `klass` and `klass2`, `c` must be the singleton class -`(super)`. If you continue like this, finally you'll arrive to the -fact that `Object`'s class must be `(Object)`. And that's the case in +`(super)`. If you continue like this, finally you'll arrive at the +conclusion that `Object`'s class must be `(Object)`. And that's the case in practice. For example, by inheriting like in the following program : 
@@ -987,7 +987,7 @@
!images/ch_class_metatree.jpg(Class hierarchy and metaclasses)!
-As classes and their metaclass are linked and inherit like this, class
+As classes and their metaclasses are linked and inherit like this,  
class
methods are inherited.
h3. Class of a class of a class
@@ -1055,7 +1055,7 @@
one type of class, it's a class's class. So it can be called
metaclass.
-However, you should be careful on the fact that singleton class are
+However, you should be wary of the fact that singleton classes are
not metaclasses. It's the singleton classes introduced in classes that
are metaclasses. The important fact is not that they are singleton
classes, but that they are the classes of classes. I was stuck on this
@@ -1103,7 +1103,7 @@
And in the three lines of the second half, `(Object)`, `(Module)` and
`(Class)` are created and set (right diagram 9). `(Object)` and
-`(Module)`'s class... that is themselves... is already set in
+`(Module)`'s classes... that is themselves... are already set in
`rb_make_metaclass()` so there is no problem. With this, the
metaobjects' bootstrap is finished.
@@ -1166,7 +1166,7 @@
Many things can be understood before and after
`rb_define_class_id()`... Before is the acquisition or creation of the
class. After is the setting of the constant. We will look at it in
-more details below.
+more detail below.
(A) In Ruby, there is an autoload function that automatically loads
libraries when some constants are accessed. This is checked in the
@@ -1174,7 +1174,7 @@
(B) Determines where the `name` constant has been defined in `Object`.
-(C) Get the `name` constant's value. This will be explained in details
+(C) Get the `name` constant's value. This will be explained in detail
in chapter 6.
(D) We've see `rb_class_real()` some time ago. If the class `c` is a
@@ -1195,7 +1195,7 @@
st_add_direct(rb_class_tbl, id, klass);
-This part assigns the class to the constant. However, whatever the way +This part assigns the class to the constant. However, whichever way you look at it you do not see that. In fact, only top-level classes are separated from the other constants and regrouped in `rb_class_tbl()`. The split is slightly related to the GC. It's not @@ -1236,12 +1236,12 @@ Ruby. As only `VALUE` values can be put in the instance variable table, the `ID` is converted to `Symbol` using `ID2SYM()`. -That's why we are able to find the constant name from the class. +That's how we are able to find the constant name from the class. h3. 2 nesting levels and more -Then, in the case of a nesting level 1, we know the reciprocal link -between name and class. What's left if the case of nesting level 2 and +So, in the case of a nesting level 1, we know the reciprocal link +between name and class. What's left is the case of nesting level 2 and more, and for that it's a little more complicated. The function to define classes at level 2 or more is `rb_define_class_under()`. @@ -1341,7 +1341,7 @@ h3. Nameless classes Contrary to what I have just said, there are in fact cases in which -neither `__classpath__` not `__classid__` are set. That is because in +neither `__classpath__` nor `__classid__` are set. That is because in Ruby you can use a method like the following to create a class. 
@@ -1350,9 +1350,9 @@
If you create a class like this, we won't go through
`rb_define_class_id()` and the classpath won't be set. In this case,
-`c` does not have any name, that is to say we get an unnamed class.
+`c` does not have any name, which is to say that we get an unnamed  
class.
-However, if later it's set into a constant, the name will be attached
+However, if later it's assigned to a constant, the name will be  
attached
to it.

@@ -1385,8 +1385,8 @@
h3. `rb_include_module` (1)
-Includes are done by the ordinary method `Module#include`. Its entity
-in C is `rb_include_module()`. In fact, to be exact, its body is
+Includes are done by the ordinary method `Module#include`. Its  
corresponding function
+in C is `rb_include_module()`. In fact, to be precise, its body is
`rb_mod_include()`, and there `Module#append_feature` is called, and
this function's default implementation finally calls
`rb_include_module()`. Mixing what's happening in Ruby and C gives us
@@ -1431,8 +1431,8 @@
(class.c)


-For the moment it's only security and type check, therethore we can
-ignore it. The process itself is bellow:
+For the moment it's only security and type checking, therethore we can
+ignore it. The process itself is below:
??? `rb_include_module` (second half)

@@ -1471,9 +1471,9 @@
(class.c)


-First, what does the (A) block is writtent in the comment. It seems a
-special condition so let's first skip reading it. By extracting the
-important parts from the rest we get the following.
+First, what the (A) block does is written in the comment. It seems  
to be a
+special condition so let's skip reading it for now. By extracting the
+important parts from the rest we get the following:

c = klass;
@@ -1540,7 +1540,7 @@
(A) First create a new class.
-(B) Transplant `module`'s instance variable and method tables in this
+(B) Transplant `module`'s instance variable and method tables into this
class.
(C) Make the including class's superclass (`super`) the super class of
@@ -1554,13 +1554,13 @@
!images/ch_class_symbolic.jpg(Include class)!
-If you look well at (A), the structure type flag is set to
+If you look closely at (A), the structure type flag is set to
T_ICLASS. This seems to be the mark of an include class. This
function's name is `include_class_new()` so `ICLASS`'s `I` must mean
`include`.
-And if you think about joining what does this function and
-`rb_include_module()`, we know that our previous expectations were not
+And if you think about joining what this function and
+`rb_include_module()` do, we know that our previous expectations  
were not
wrong. In brief, including is inserting the include class of a
module between a class and its superclass (diagram 12).
@@ -1578,12 +1578,12 @@
`basic.klass` is only used to point to the module's body, so for
example calling a method on the include class would be very bad. So
include classes must not be seen from Ruby programs. And in
-practice all methods skip include classes, no exception.
+practice all methods skip include classes, with no exceptions.
h3. Simulation
It was complicated so let's look at a concrete example. I'd like you
-to watch diagram 13 (1). There are `m1` that included `m2` and the
+to look at diagram 13 (1). There is `m1` that included `m2` and the
`c1` class. From there, the changes made to include `m1` in `c1` are
(2) and (3). `im` are of course include classes.
@@ -1591,7 +1591,7 @@
h3. `rb_include_module` (2)
-Well now we can explain the part of `rb_include_module()` we skipped.
+Well, now we can explain the part of `rb_include_module()` we skipped.
??? `rb_include_module` (avoiding double inclusion)




From piyokun at gmail.com  Tue Mar 21 16:49:11 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 06:49:11 +0900
Subject: [rhg-discussion] The rest of chapter 2
In-Reply-To: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>
References: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>
Message-ID: <1f748ec60603211349s57c29ee6x56412eb598cb175@mail.gmail.com>

On 3/22/06, Jim Driscoll  wrote:
> However, the section:
>
> `ifnone` is the value when a key does not have an attached value, its
> default
> is `nil`. `iter_lev` is to make the hashtable reentrant (multithread
> safe).
>
> ...seems wrong to me. It should be talking about if the key does not
> exist, surely? Because if it exists and has a nominally undefined
> value, it should return that, not the default.

>From the original: `ifnone`????????????????????????????????
`nil`?`iter_lev`???????????????????(?????????
?)?????????????

I believe this sentence is explaining this API:

Hash#{default,default=,default_proc}


> Anyway, patch follows for the (translation) problems I could easily
> find in the rest of the chapter.

I think all of the corrections you are making are spot on and make the
english flow better. +1

Best regards,
Clifford Caoile
--
http://piyokun.GooglePages.com

From meinrad.recheis at gmail.com  Tue Mar 21 17:17:58 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Tue, 21 Mar 2006 23:17:58 +0100
Subject: [rhg-discussion] stylistic suggestion for chapter04
Message-ID: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>

i don't know if it's appropriate to critique the translation of
chapter 4 as vincent seems to be still working on it, but i have a few
suggestions:

this sentence is a bit clumsy (i think):
"Methods only defined on a specific instance of an object, singleton
methods, can also be defined."
how about this:
"Methods that are defined on a specific instance of an object are
called singleton methods."
i did not make a diff, because it is not an error but rather a
stylistic suggestion.


also these two sentences are extremely heavily segmented by commas
which is not quite right (i think):
"In NEWOBJ(), struct RClass is created, and the pointer is put in its
first parameter klass. In OBJSETUP(), inside this RClass, the RBasic
part, that means basic.klass and basic.flags, are initialized."


this sentence seems to be gramatically corrupt. correct me if i am wrong:
"That's why singleton class, more than just having one instance, are
forced to be like that."

-- henon

PS: huh, jim has made a big patch for chapter 4 ;) maybe it covers the
things i am pointing at anyways.


From johndouthat at gmail.com  Tue Mar 21 18:01:58 2006
From: johndouthat at gmail.com (John Douthat)
Date: Tue, 21 Mar 2006 17:01:58 -0600
Subject: [rhg-discussion] Hi all
Message-ID: <652b4cf70603211501u6a063be5v832a2abc4355fc35@mail.gmail.com>

My previous submission didn't make it through, so here it is again:


Hi Everyone,

    I'm _REALLY_ EXCITED that RHG is being translated into English, and I'd
love to be part of the translation project. I have strong skills in C, Ruby,
and U.S. English, which is my native language. I've also developed some of
CRuby extensions (v. 1.8+) with the help of the PickAxe book, but I've been
frustrated with the amount of English-language documentation available,
forcing me to read the Ruby source code on a few occasions. I have no
experience with Japanese though, so I feel I could best help the community
by helping to correct mistakes after the initial English translations. I
could also help make simple diagrams if no volunteers are available for
that. I've read through chapter 2 and made some edits that should make it
easier for English-speakers to read. Here's looking forward to the rest of
the chapters!

(password is RHSCH2. login and click "compare" to see the changes.)
http://123.writeboard.com/978c55d5b95a783ce

    Thanks,
    John Douthat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rhg-discussion/attachments/20060321/fd01e702/attachment.htm 

From j at rjimlad.org  Tue Mar 21 18:04:43 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Tue, 21 Mar 2006 23:04:43 +0000
Subject: [rhg-discussion] stylistic suggestion for chapter04
In-Reply-To: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
References: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
Message-ID: 

Hi Henon,

On 21 Mar 2006, at 22:17, Meinrad Recheis wrote:

> i don't know if it's appropriate to critique the translation of
> chapter 4 as vincent seems to be still working on it, but i have a few
> suggestions:

Well, it didn't stop me (as you surmised)!

>
> this sentence is a bit clumsy (i think):
> "Methods only defined on a specific instance of an object, singleton
> methods, can also be defined."
> how about this:
> "Methods that are defined on a specific instance of an object are
> called singleton methods."
> i did not make a diff, because it is not an error but rather a
> stylistic suggestion.

I think that actually has a slightly different meaning. As it is,  
it's conveying that it is also possible to define a method on a  
single object instance (singleton methods). The proposed rewrite  
lacks the implication that you can define them yourself (although  
that should be clear anyway). I have to agree that saying "defined"  
twice in one sentence is a bit uncomfortable to read.

> also these two sentences are extremely heavily segmented by commas
> which is not quite right (i think):
> "In NEWOBJ(), struct RClass is created, and the pointer is put in its
> first parameter klass. In OBJSETUP(), inside this RClass, the RBasic
> part, that means basic.klass and basic.flags, are initialized."

The first sentence seems reasonable to me, but removing the second  
comma would perhaps make it flow better.

The second sentence I can't parse. Should it be something like this?

	In OBJSETUP(), the struct RBasic member of the RClass (and thus  
basic.klass and basic.flags) is initialised.

(leaving aside for a moment the question of whether to use the  
British or American spelling of initiali[sz]ed)

> this sentence seems to be gramatically corrupt. correct me if i am  
> wrong:
> "That's why singleton class, more than just having one instance, are
> forced to be like that."

Yeah, there are a few instances of singular/plural confusion: I  
suppose it must be more ambiguous in Japanese. I had trouble reading  
the rest of the sentence too, to the extent that I don't quite know  
what it means.

Jim

From amalawi at gmail.com  Wed Mar 22 02:39:38 2006
From: amalawi at gmail.com (Abu Abdullah Al Jumaee)
Date: Wed, 22 Mar 2006 11:39:38 +0400
Subject: [rhg-discussion] small suggestion!
Message-ID: 

Hi,

thanks for the 2nd chapter.

i have a small suggestion regarding the exchange of corrections and
comments on certain chapters. it will be hard for someone to follow
the changes related to chapter say n or m.

Can we make the links to each chapter a redirects to whiteboard pages ?

http://www.writeboard.com/

This will help people who'd like to focus on a certain chapter to
group together and collect the relevant comment with the revision they
were talking about.

regards

Ala'a
--
"You do not really understand something unless you can explain it to
your grandmother." - Albert Einstein


From vincent.isambart at gmail.com  Wed Mar 22 03:34:58 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 09:34:58 +0100
Subject: [rhg-discussion] Hello
In-Reply-To: <1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com>
References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org>
	<53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org>
	<1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com>
Message-ID: <7d9a1f530603220034s110063e3t23df184d87f9284e@mail.gmail.com>

Hi,

> Here's the most of the second grouping of Jim Driscoll's corrections
> in diff format. Again I say most
> because he has multiple suggestions for some points.
Really thanks for the diff but it seems you did (or your mailer did) a
little mistake with the encoding. For example, I got "??" instead of
"?" in the mail. So one chunk of the diff did not work. Not to have
any problem, I think it would be better to put the patch in an
attached file.

Cheers,
Vincent

From vincent.isambart at gmail.com  Wed Mar 22 04:00:17 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 10:00:17 +0100
Subject: [rhg-discussion] Hi all
In-Reply-To: <652b4cf70603211501u6a063be5v832a2abc4355fc35@mail.gmail.com>
References: <652b4cf70603211501u6a063be5v832a2abc4355fc35@mail.gmail.com>
Message-ID: <7d9a1f530603220100m2e7a4899g4b179f14cf17c44@mail.gmail.com>

Hi,

On 3/22/06, John Douthat  wrote:
> My previous submission didn't make it through, so here it is again:
Yes, it was bigger than the maximum mail size (that was 100 KB). I
increased the limit to 400 KB.

> that. I've read through chapter 2 and made some edits that should make it
> easier for English-speakers to read.
I'll check this. Could you next time modify directly the text file
available on SVN, it's be easier for me to merge.

And for patch files: please ATTACH them to your mails, do not paste
them in you mail, it's easier for me.

Cheers,
Vincent


From vincent.isambart at gmail.com  Wed Mar 22 04:12:03 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 10:12:03 +0100
Subject: [rhg-discussion] stylistic suggestion for chapter04
In-Reply-To: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
References: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
Message-ID: <7d9a1f530603220112s2b2af202ga3597aa55f9f3a44@mail.gmail.com>

> i don't know if it's appropriate to critique the translation of
> chapter 4 as vincent seems to be still working on it, but i have a few
> suggestions:
I indeed said that there bad sentences left in chapter 4, but well,
I'll check the corrections. But I'll wait before committing chapter 6
:P.

And for the singular/plural problem, yes, in Japanese there are no (or
only for some pronouns) differences between singular/plural. That's
the type of things needing a complete reread after the first pass.


From vincent.isambart at gmail.com  Wed Mar 22 04:25:01 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 10:25:01 +0100
Subject: [rhg-discussion] The rest of chapter 2
In-Reply-To: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>
References: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>
Message-ID: <7d9a1f530603220125g7316137fx8cf02cd92217a198@mail.gmail.com>

> `ifnone` is the value when a key does not have an attached value, its default
> is `nil`. `iter_lev` is to make the hashtable reentrant (multithread safe).
>
> ...seems wrong to me. It should be talking about if the key does not
> exist, surely? Because if it exists and has a nominally undefined
> value, it should return that, not the default.
Is the following a little better?
`ifnone` is the value when there is no value corresponding to a key,
its default is `nil`.

nil is a value. So yes, that's what you call "the key does not exist",
but I think the concept of a key existing or not not is a little
strange. But there must be a way to make it more clear.

PS: Really thanks for the corrections, but next time please attach the
patch to your mail as your mailer (like most) splits some lines in
two.


From piyokun at gmail.com  Wed Mar 22 06:34:36 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 20:34:36 +0900
Subject: [rhg-discussion] Hello
In-Reply-To: <7d9a1f530603220034s110063e3t23df184d87f9284e@mail.gmail.com>
References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org>
	<53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org>
	<1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com>
	<7d9a1f530603220034s110063e3t23df184d87f9284e@mail.gmail.com>
Message-ID: <1f748ec60603220334x1a56c6bfkf5d9697a45e708c6@mail.gmail.com>

> Really thanks for the diff but it seems you did (or your mailer did) a
> little mistake with the encoding. For example, I got "??" instead of
> "?" in the mail. So one chunk of the diff did not work. Not to have
> any problem, I think it would be better to put the patch in an
> attached file.

Ok.

Just a FYI, I was using Gmail with "Use default text encoding for
outgoing messages" instead of UTF-8. I don't know what the encoding
became. I'll try using the UTF-8 option for emails.

Best regards,
Clifford Caoile
---
http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html

From vincent.isambart at gmail.com  Wed Mar 22 06:40:36 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 12:40:36 +0100
Subject: [rhg-discussion] Hello
In-Reply-To: <1f748ec60603220334x1a56c6bfkf5d9697a45e708c6@mail.gmail.com>
References: <4ABC2388-28B5-4BA1-A018-D157A609C527@rjimlad.org>
	<53923D25-6137-45DE-9378-BE2301EDFEE8@rjimlad.org>
	<1f748ec60603201652r49819ca2occ9e73f35ae85a0a@mail.gmail.com>
	<7d9a1f530603220034s110063e3t23df184d87f9284e@mail.gmail.com>
	<1f748ec60603220334x1a56c6bfkf5d9697a45e708c6@mail.gmail.com>
Message-ID: <7d9a1f530603220340p32a48f09lbb4f06108c4b66ea@mail.gmail.com>

> Just a FYI, I was using Gmail with "Use default text encoding for
> outgoing messages" instead of UTF-8. I don't know what the encoding
> became. I'll try using the UTF-8 option for emails.

I'm not sure the problem if the problem is on the Gmail side or on
your text editor's side.
But if you send the patch as an attachment as I recommend, there
should not be any problem, whatever the encoding Gmail uses...

Cheers


From vincent.isambart at gmail.com  Wed Mar 22 07:25:41 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 13:25:41 +0100
Subject: [rhg-discussion] stylistic suggestion for chapter04
In-Reply-To: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
References: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
Message-ID: <7d9a1f530603220425y4600a720n9055751244c49ea0@mail.gmail.com>

> this sentence is a bit clumsy (i think):
> "Methods only defined on a specific instance of an object, singleton
> methods, can also be defined."
> how about this:
> "Methods that are defined on a specific instance of an object are
> called singleton methods."
> i did not make a diff, because it is not an error but rather a
> stylistic suggestion.
What do you think of something like "We can define methods that are
specific to an instance of an object. They are called singleton
methods."

> PS: huh, jim has made a big patch for chapter 4 ;)
I just merged it. If he continues to send me big patches like this, I
think I'll end up giving him commit rights, it will be less work for
me ;)


From stevenbristol at gmail.com  Wed Mar 22 07:39:47 2006
From: stevenbristol at gmail.com (Steven A Bristol)
Date: Wed, 22 Mar 2006 07:39:47 -0500
Subject: [rhg-discussion] help getting started
Message-ID: <396d7d2d0603220439r1b783dffv5750177a5f925bf0@mail.gmail.com>

I would like to get started proofing/editing something. Can someone
please tell me where to go, or what to do? Is someone handing out
assignments, or do I just pick something out of svn? Where is the
repository? Do I need a log on? Do I post my changes/recommendations
here? Are there some instructions or something to help begin?

--


Thank you,
Steven A Bristol
stevenbristol at gmail.com


From piyokun at gmail.com  Wed Mar 22 07:49:24 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 21:49:24 +0900
Subject: [rhg-discussion] [translation,patch] Chapter 03 - Part 1,2 of 10
Message-ID: <1f748ec60603220449p5a0bdc52n75bf40fe8adc3b74@mail.gmail.com>

Here's a translation from Japanese to English of part of Chapter 03
"Names and name tables", parts 1, 2 of 10. I include it as an
attachment and also inline for viewing convenience.

part 1: "st_table" : Summary
part 2: "st_table" : What is a Hash Table?

Summary: Not much exciting parts of Ruby explained here, just CS101
"Basic Data Structures" and motivation.

Action Items:
1. I have no idea what to do with the figure references such as
"!images/ch_name_array.jpg(??)!" What should be done?
2. Please correct the nuances I missed from original Japanese, if any.

Patch is based on svn://rubyforge.org/var/svn/rhg -r9
(Revision numbers mentioned in the patch are from my private svn repos)
---- BEGIN PATCH
Index: chapter03.txt
===================================================================
--- chapter03.txt	(.../japanese/chapter03.txt)	(????? 4)
+++ chapter03.txt	(.../chapter03.txt)	(????? 8)
@@ -1,39 +1,42 @@
-h1. ?3? ??????
+Translation by Clifford Escobar CAOILE

+h1. Chapter 3: Names and Name Table
+
 h2. `st_table`

-????????????????????????`st_table`???????
-??????????????`st_table`?????????????????
-????
+`st_table` has already been mentioned as a method table and instance table.
+In this chapter let us look at the detailed mechanism of the `st_table`.

-h3. ??
+h3. Summary

-`st_table`????????????????????????????
-???????????????????????????????????
-???????????????????????????
+I previously mentioned that the `st_table` is a hash table. What is a hash
+table? It is a data structure that records one-to-one relations, for
+example, variable name and its value, function name and its body, etc.

-?????????????????????????????
-???????????????????????
+However, data structures other than hash tables can, of course, record
+one-to-one relations. For example, a list of following data structure will
+suffice for this purpose.

 
 struct entry {
     ID key;
     VALUE val;
-    struct entry *next;  /* ????????? */
+    struct entry *next;  /* point to the next entry */
 };
 


-???????????????????1000???????1000?????
-???????????????????????????????????
-???????????????????????????????????
-????????????????????????????????????
-???????????????????????????????????
-???????
+However, this method is slow. If the list contains a thousand items, in the
+worst case, it is necessary to traverse links a thousand times. In other
+words, in proportion to the number of elements, the search time increases.
+This is bad. Since ancient times, various speed improvement methods have
+been conceived. The hash table is one of those improved methods. In other
+words, the point is not that the hash table is necessary but that it can be
+made faster.

-??????`st_table`??????????????????
-?????????????????
+Now then, let us examine the `st_table`. But first, this library is not
+created by Matsumoto, rather:

-? `st.c`??????
+? `st.c` credits
 
    1  /* This is a public domain general purpose hash table package
          written by Peter Moore @ UCB. */
@@ -41,59 +44,60 @@
 (st.c)
 


-??????????
+as shown above.

-????Google??????????????????????
-`st_table`?STring TABLE?????????general purpose??????
-string?????????????????????
+By the way, when I searched Google and found another version, it mentioned
+that st_table is a contraction of "STring TABLE". However, I find it
+contradictory that it has "general purpose" and "string" aspects.

-h4. ??????????
+h4. What is a hash table

-???????????????????? n ?????????
-??????????? n=64 ????(?1)?
+A hash table can be thought as the following. Let us think of an array with
+n items. For example, let us make n=64 (figure 1).

 !images/ch_name_array.jpg(??)!

-???????0? n-1 (0?63)?????? i ????? f ????
-???? f ??????????? f ??????????????
- i ???????????????
-?????????????????????64?????????0?63?
-????????????????? f ??????
+Then let us specify a function f that takes a key and produces an integer i
+from 0 to n-1 (0-63). We call this f a hash function. f when given the same
+key always produces the i. For example, if we make the assumption that the
+key is limited to positive integers, then if the key is divided by 64 then
+the remainder will always fall between 0 and 63. This method of calculation
+can become function f.

-??????????????????? f ???? i ???????????
-?????? i ?????????(?2)?
-???????????????????????????????????
-??????????????????????????????
+When recording relationships, given a key, function f generates i, and
+place the value into index i of the array we have prepared. In other words,
+the index access into an array is very fast. Therefore the fundamental idea
+is to change the key into a integer.

 !images/ch_name_aset.jpg(??????)!

-????????????????????????????????
-??????? n ??64???????64???????????????
-?????? i ?????????64??????????????????
-????????????????????????????????????
-?`key % 64`??????????65??129????????1???????
-?????????(collision)???????????????????
-?????
+However, in the real world it isn't that easy. There is a critical problem
+with this idea. Because n is only 64, if there are more than 64
+relationships to be recorded, it is for certain that i will be duplicated.
+It is also possible with less that 64, the same index will be allocated.
+For example, given the previous hash function "key % 64", keys 65 and 129
+will have a hash value of 1. This is called a hash value collision. There
+are many ways to resolve a collision.

-???????????????????????????
-??????????(?3)?
+For example, if a collision occurs, then insert into the next element.
+This is called open addressing. (Figure 3).

 !images/ch_name_nexti.jpg(????)!

-?????????????????????????????????
-????????????????????????????????
-?????????????????????(?4)?
-`st_table`??????????????
+Other than using the array like this, there are other methods like using a
+pointer in each element of the array to a linked list. Then when a
+collision occurs, grow the linked list. This is called chaining. (Figure
+4) `st_table` uses this chaining method.

 !images/ch_name_chain.jpg(???)!

-??????????????????????????????????
-????????????????????????????????????
-???????????????????????????????????
-?????????????????????????????
-GNU gperf?????`ruby`?????????????????????
-???????????????????????????????????
-???????
+However, if it can be determined apriori what possible keys will be used,
+it is possible to imagine a hash function that will never create
+collisions. This type of function is called a "perfect hash function".
+Actually, there are tools that creates a perfect hash function given a set
+of arbitrary strings. GNU gperf is one of those. `ruby`'s parser
+implementation uses GNU gperf but... this is not the time to discuss it.
+Let us discuss this in the second part of the book.

 h3. ?????

---- END PATCH

Best regards,
Clifford Caoile
--
irb(main):001:0> p my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
-------------- next part --------------
Index: chapter03.txt
===================================================================
--- chapter03.txt	(.../japanese/chapter03.txt)	(??????????????? 4)
+++ chapter03.txt	(.../chapter03.txt)	(??????????????? 8)
@@ -1,39 +1,42 @@
-h1. ???3??? ??????????????????
+Translation by Clifford Escobar CAOILE
 
+h1. Chapter 3: Names and Name Table
+
 h2. `st_table`
 
-????????????????????????????????????????????????????????????????????????`st_table`?????????????????????
-??????????????????????????????????????????`st_table`???????????????????????????????????????????????????
-????????????
+`st_table` has already been mentioned as a method table and instance table.
+In this chapter let us look at the detailed mechanism of the `st_table`.
 
-h3. ??????
+h3. Summary
 
-`st_table`????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????
+I previously mentioned that the `st_table` is a hash table. What is a hash
+table? It is a data structure that records one-to-one relations, for
+example, variable name and its value, function name and its body, etc.
 
-???????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????
+However, data structures other than hash tables can, of course, record
+one-to-one relations. For example, a list of following data structure will
+suffice for this purpose.
 
 
 struct entry {
     ID key;
     VALUE val;
-    struct entry *next;  /* ??????????????????????????? */
+    struct entry *next;  /* point to the next entry */
 };
 

 
-?????????????????????????????
???????????????????????????1000?????????????????????1000???????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-????????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????
+However, this method is slow. If the list contains a thousand items, in the
+worst case, it is necessary to traverse links a thousand times. In other
+words, in proportion to the number of elements, the search time increases.
+This is bad. Since ancient times, various speed improvement methods have
+been conceived. The hash table is one of those improved methods. In other
+words, the point is not that the hash table is necessary but that it can be
+made faster.
 
-??????????????????`st_table`??????????????????????????????????????????????????????
-???????????????????????????????????????????????????
+Now then, let us examine the `st_table`. But first, this library is not
+created by Matsumoto, rather:
 
-??? `st.c`??????????????????
+??? `st.c` credits
 
    1  /* This is a public domain general purpose hash table package
          written by Peter Moore @ UCB. */
@@ -41,59 +44,60 @@
 (st.c)
 

 
-??????????????????????????????
+as shown above.
 
-????????????Google??????????????????????????????????????????????????????????????????
-`st_table`???STring TABLE???????????????????????????general purpose??????????????????
-string???????????????????????????????????????????????????????????????
+By the way, when I searched Google and found another version, it mentioned
+that st_table is a contraction of "STring TABLE". However, I find it
+contradictory that it has "general purpose" and "string" aspects.
 
-h4. ??????????????????????????????
+h4. What is a hash table
 
-???????????????????????????????????????????????????????????? n ??????????????????????
????
-????????????????????????????????? n=64 ????????????(???1)???
+A hash table can be thought as the following. Let us think of an array with
+n items. For example, let us make n=64 (figure 1).
 
 !images/ch_name_array.jpg(?
????)!
 
-?????????????????????0??? n-1 (0???63)?????????????????? i ??????????????? f ????????????
-???????????? f ????????????????????????????????? f ??????????????????????????????????????????
- i ?????????????????????????????????????????????
-???????????????????????????????????????????????????????????????64???????????????????????
???0???63???
-??????????????????????????????????????????????????? f ??????????????????
+Then let us specify a function f that takes a key and produces an integer i
+from 0 to n-1 (0-63). We call this f a hash function. f when given the same
+key always produces the i. For example, if we make the assumption that the
+key is limited to positive integers, then if the key is divided by 64 then
+the remainder will always fall between 0 and 63. This method of calculation
+can become function f.
 
-????????????????????????????????????????????????????????? f ???????????? i ?????????????????????????
???????
-?????????????????? i ??????????
????????????????(???2)???
-???????????????????
????????????????????????????????????????????????
????????????????????????????????????
-??????????????????????????????????????????????????????????????????????????????????????????
+When recording relationships, given a key, function f generates i, and
+place the value into index i of the array we have prepared. In other words,
+the index access into an array is very fast. Therefore the fundamental idea
+is to change the key into a integer.
 
 !images/ch_name_aset.jpg(?
????????????????)!
 
-????????????????????????????????????????????????????????????????????????????????????????????????
-????????????????????? n ??????64?????????????????????64?????????????????????????????????????????????
-?????????????????? i ???????????????????????????64?????????????????????????????
????????????????????????
-??????????????????????????????????????????????????????????????????????????????????
?????????????????????????
-???`key % 64`??????????????????????????????65??????129????????????????????????1?????????????????????
-???????????????????????????(collision)?????????????????????????????????????????????????????????
-???????????????
+However, in the real world it isn't that easy. There is a critical problem
+with this idea. Because n is only 64, if there are more than 64
+relationships to be recorded, it is for certain that i will be duplicated.
+It is also possible with less that 64, the same index will be allocated.
+For example, given the previous hash function "key % 64", keys 65 and 129
+will have a hash value of 1. This is called a hash value collision. There
+are many ways to resolve a collision.
 
-???????????????????????????????????????????????????????
?????????????????????????
-??????????????????????????????(???3)???
+For example, if a collision occurs, then insert into the next element. 
+This is called open addressing. (Figure 3).
 
 !images/ch_name_nexti.jpg(????????????)!
 
-??????????
???????????????????????????????????????????????
????????????????????????????????????????
-????????????????????????????????????????????????????????????????????????????????????????????????
-???????????????????????????????????????????????????????????????(???4)???
-`st_table`??????????????????????????????????????????
+Other than using the array like this, there are other methods like using a
+pointer in each element of the array to a linked list. Then when a
+collision occurs, grow the linked list. This is called chaining. (Figure
+4) `st_table` uses this chaining method.
 
 !images/ch_name_chain.jpg(?????????)!
 
-??????????????????????????????????????????????????????????????????????????????????????????????????????
-????????????????????????????????????????????????????????????????????????????????????????????????????????????
-???????????????????????????????
?????????????????????????????????????????????????????????????????????????
-?????????????????????????
?????????????????????????????????????????????????????????????
-GNU gperf???????????????`ruby`????????????????????
??????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????
+However, if it can be determined apriori what possible keys will be used,
+it is possible to imagine a hash function that will never create
+collisions. This type of function is called a "perfect hash function".
+Actually, there are tools that creates a perfect hash function given a set
+of arbitrary strings. GNU gperf is one of those. `ruby`'s parser
+implementation uses GNU gperf but... this is not the time to discuss it.
+Let us discuss this in the second part of the book. 
 
 h3. ???????????????
 


From meinrad.recheis at gmail.com  Wed Mar 22 07:58:02 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Wed, 22 Mar 2006 13:58:02 +0100
Subject: [rhg-discussion] stylistic suggestion for chapter04
In-Reply-To: <7d9a1f530603220425y4600a720n9055751244c49ea0@mail.gmail.com>
References: <43d756720603211417u30c04bdbha72e1f36d1944679@mail.gmail.com>
	<7d9a1f530603220425y4600a720n9055751244c49ea0@mail.gmail.com>
Message-ID: <43d756720603220458r6bef182an5bada9cf1d4d5c30@mail.gmail.com>

On 3/22/06, Vincent Isambart  wrote:
> > this sentence is a bit clumsy (i think):
> > "Methods only defined on a specific instance of an object, singleton
> > methods, can also be defined."
> > how about this:
> > "Methods that are defined on a specific instance of an object are
> > called singleton methods."
> > i did not make a diff, because it is not an error but rather a
> > stylistic suggestion.
> What do you think of something like "We can define methods that are
> specific to an instance of an object. They are called singleton
> methods."

sounds good!

>
> > PS: huh, jim has made a big patch for chapter 4 ;)
> I just merged it. If he continues to send me big patches like this, I
> think I'll end up giving him commit rights, it will be less work for
> me ;)

you definitely should do that. ^^


From piyokun at gmail.com  Wed Mar 22 07:59:25 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 21:59:25 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 - part
	3, 4 of 10
Message-ID: <1f748ec60603220459h65041060q8e192243d67cdb61@mail.gmail.com>

Vincent:
If nobody else minds, I'll start translating parts 3 and 4 (of 10) ofChapter 03.
part 3: "st_table" : Data structurepart 4: "st_table" : st_hash_type example
Best regards,Clifford Caoile--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From meinrad.recheis at gmail.com  Wed Mar 22 08:00:22 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Wed, 22 Mar 2006 14:00:22 +0100
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 1,
	2 of 10
In-Reply-To: <1f748ec60603220449p5a0bdc52n75bf40fe8adc3b74@mail.gmail.com>
References: <1f748ec60603220449p5a0bdc52n75bf40fe8adc3b74@mail.gmail.com>
Message-ID: <43d756720603220500o2fddedbep83c6af744e88c1cb@mail.gmail.com>

n 3/22/06, Clifford Caoile  wrote:
> Here's a translation from Japanese to English of part of Chapter 03
> "Names and name tables", parts 1, 2 of 10. I include it as an
> attachment and also inline for viewing convenience.
>
> part 1: "st_table" : Summary
> part 2: "st_table" : What is a Hash Table?
>
> Summary: Not much exciting parts of Ruby explained here, just CS101
> "Basic Data Structures" and motivation.
>
> Action Items:
> 1. I have no idea what to do with the figure references such as
> "!images/ch_name_array.jpg(??)!" What should be done?

just post the translation of japanese words in the images so that i
can work on them.

From piyokun at gmail.com  Wed Mar 22 08:14:15 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 22:14:15 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 1,
	2 of 10
In-Reply-To: <43d756720603220500o2fddedbep83c6af744e88c1cb@mail.gmail.com>
References: <1f748ec60603220449p5a0bdc52n75bf40fe8adc3b74@mail.gmail.com>
	<43d756720603220500o2fddedbep83c6af744e88c1cb@mail.gmail.com>
Message-ID: <1f748ec60603220514g780b55d9j2912097e4d95489d@mail.gmail.com>

On 3/22/06, Meinrad Recheis  wrote:> On 3/22/06, Clifford Caoile  wrote:> > Action Items:> > 1. I have no idea what to do with the figure references such as> > "!images/ch_name_array.jpg(??)!" What should be done?>> just post the translation of japanese words in the images so that i> can work on them.
Oops I figured out that the () part means automatically label(caption) the referenced figure with the following words. I'll createanother patch for that.
Regarding the Japanese in the figures themselves, I'll write it uphere with the Japanese in the "" (quotations).
Figure 1:no Japanese
Figure 2:"Key" goes into function f represented by a circle f generating "i =3". The word inside the array index 3 is "value".
Figure 3:"Key" goes into function f represented by a circle f generating "i =3". The word inside the array index 3 and 4 is "value". Thedescription is "3 is non-empty so put it in the next element, 4"
Figure 4:"Key" goes into function f represented by a circle f generating "i =3". The first arrow from array index 3 points to "value" and thedescription is "Index 3 already has an entry, so...". The downwardarrow from that points to "value" and the description is ",,,link it."
Action Items:3. Did we decide what to name ? as either "figure" or "diagram"?
Best regards,Clifford Caoile--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From meinrad.recheis at gmail.com  Wed Mar 22 08:16:29 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Wed, 22 Mar 2006 14:16:29 +0100
Subject: [rhg-discussion] help getting started
In-Reply-To: <396d7d2d0603220439r1b783dffv5750177a5f925bf0@mail.gmail.com>
References: <396d7d2d0603220439r1b783dffv5750177a5f925bf0@mail.gmail.com>
Message-ID: <43d756720603220516k4cd8acbei417215d628ae283@mail.gmail.com>

On 3/22/06, Steven A Bristol  wrote:
> I would like to get started proofing/editing something. Can someone
> please tell me where to go, or what to do?
currently there is not much translated yet. chapter02 has been
proofreaded by several people. chapter 04 is beeing revised. chapter03
is partially translated but not proved. you may read any translations
in the repository. the more people prove read the texts the better
they get.

edit them if you find something and make a patch. post that patch on
the list here. telling us which revision you edited would also be
wise. vincent will apply your patch to the repository.

> Is someone handing out
> assignments, or do I just pick something out of svn? Where is the
> repository? Do I need a log on?
>
you can check out from SVN by:
svn checkout svn://rubyforge.org//var/svn/rhg

> Do I post my changes/recommendations
> here? Are there some instructions or something to help begin?
>
the mailing list is the organisation. if somebody wants to do
something he/she announces it on the list, so that others know what is
going on. that's it.

hth,
-- henon


> --
>
>
> Thank you,
> Steven A Bristol
> stevenbristol at gmail.com
>
> _______________________________________________
> rhg-discussion mailing list
> rhg-discussion at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rhg-discussion
>


From piyokun at gmail.com  Wed Mar 22 08:25:21 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Wed, 22 Mar 2006 22:25:21 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 1,
	2 of 10
In-Reply-To: <1f748ec60603220514g780b55d9j2912097e4d95489d@mail.gmail.com>
References: <1f748ec60603220449p5a0bdc52n75bf40fe8adc3b74@mail.gmail.com>
	<43d756720603220500o2fddedbep83c6af744e88c1cb@mail.gmail.com>
	<1f748ec60603220514g780b55d9j2912097e4d95489d@mail.gmail.com>
Message-ID: <1f748ec60603220525x52654623l856c57e0b900d26d@mail.gmail.com>

On 3/22/06, Clifford Caoile  wrote:
> Oops I figured out that the () part means automatically label
> (caption) the referenced figure with the following words. I'll create
> another patch for that.

As promised here is the patch. It requires the previous patch
"chapter03-1,2-r9.diff"

---- BEGIN PATCH
Index: chapter03.txt
===================================================================
--- chapter03.txt	(????? 8)
+++ chapter03.txt	(????? 10)
@@ -55,7 +55,7 @@
 A hash table can be thought as the following. Let us think of an array with
 n items. For example, let us make n=64 (figure 1).

-!images/ch_name_array.jpg(??)!
+!images/ch_name_array.jpg(Array)!

 Then let us specify a function f that takes a key and produces an integer i
 from 0 to n-1 (0-63). We call this f a hash function. f when given the same
@@ -69,7 +69,7 @@
 the index access into an array is very fast. Therefore the fundamental idea
 is to change the key into a integer.

-!images/ch_name_aset.jpg(??????)!
+!images/ch_name_aset.jpg(Array assignment)!

 However, in the real world it isn't that easy. There is a critical problem
 with this idea. Because n is only 64, if there are more than 64
@@ -82,14 +82,14 @@
 For example, if a collision occurs, then insert into the next element.
 This is called open addressing. (Figure 3).

-!images/ch_name_nexti.jpg(????)!
+!images/ch_name_nexti.jpg(Open addressing)!

 Other than using the array like this, there are other methods like using a
 pointer in each element of the array to a linked list. Then when a
 collision occurs, grow the linked list. This is called chaining. (Figure
 4) `st_table` uses this chaining method.

-!images/ch_name_chain.jpg(???)!
+!images/ch_name_chain.jpg(Chaining)!

 However, if it can be determined apriori what possible keys will be used,
 it is possible to imagine a hash function that will never create
---- END PATCH

Best regards,
Clifford Caoile
--
irb(main):001:0> p my.greeting( :"rhg-discussion" )
"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
=> nil
-------------- next part --------------
Index: chapter03.txt
===================================================================
--- chapter03.txt	(??????????????? 8)
+++ chapter03.txt	(??????????????? 10)
@@ -55,7 +55,7 @@
 A hash table can be thought as the following. Let us think of an array with
 n items. For example, let us make n=64 (figure 1).
 
-!images/ch_name_array.jpg(?
????)!
+!images/ch_name_array.jpg(Array)!
 
 Then let us specify a function f that takes a key and produces an integer i
 from 0 to n-1 (0-63). We call this f a hash function. f when given the same
@@ -69,7 +69,7 @@
 the index access into an array is very fast. Therefore the fundamental idea
 is to change the key into a integer.
 
-!images/ch_name_aset.jpg(?
????????????????)!
+!images/ch_name_aset.jpg(Array assignment)!
 
 However, in the real world it isn't that easy. There is a critical problem
 with this idea. Because n is only 64, if there are more than 64
@@ -82,14 +82,14 @@
 For example, if a collision occurs, then insert into the next element. 
 This is called open addressing. (Figure 3).
 
-!images/ch_name_nexti.jpg(????????????)!
+!images/ch_name_nexti.jpg(Open addressing)!
 
 Other than using the array like this, there are other methods like using a
 pointer in each element of the array to a linked list. Then when a
 collision occurs, grow the linked list. This is called chaining. (Figure
 4) `st_table` uses this chaining method.
 
-!images/ch_name_chain.jpg(?????????)!
+!images/ch_name_chain.jpg(Chaining)!
 
 However, if it can be determined apriori what possible keys will be used,
 it is possible to imagine a hash function that will never create


From piyokun at gmail.com  Wed Mar 22 10:17:33 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 00:17:33 +0900
Subject: [rhg-discussion] [translation,patch] Chapter 03 - Part 3,4 of 10
Message-ID: <1f748ec60603220717x4de601dv8325855b058bf5@mail.gmail.com>

Here's a translation from Japanese to English of part of Chapter 03
"Names and name tables", parts 3, 4 of 10. I include it as an
attachment and also inline for viewing convenience.

Chapter 03 : "Names and name tables"
part 3: "st_table" : Data Structure
part 4: "st_table" : st_hash_type example

Summary: Here is some Ruby C code! Alas it is pretty simplistic. Also
the motivation for abstracting away code that handles different types
is explained. No figures to translate here.

Action items:
4. I don't know how to translate ????????. Gosh darn compound verbs,
can't look them up in a dictionary.
5. I notice I'm a little inexact when it comes to the motivation
explanations, but where there is actual code I try my hardest to
translate exactly. Take this as a guide to find my translation
mistakes... Then again they say that programmers are the worst bug
reporters. We mean well don't we?
6. This section doesn't explain why this code is valid:

irb(main):012:0> a = { :one => "one", 2 => 2, "three" => :three }
=> {"three"=>:three, 2=>2, :one=>"one"}
irb(main):013:0> a.each { |i| p i}
["three", :three]
[2, 2]
[:one, "one"]
=> {"three"=>:three, 2=>2, :one=>"one"}
irb(main):014:0> a["three"]
=> :three
irb(main):015:0> a[ :one]
=> "one"
irb(main):016:0> a[ 2 ]
=> 2

In the text, the explanation is one data type per hash table. Did this
change in Ruby 1.8.x?

Patch is based on svn://rubyforge.org/var/svn/rhg -r9,
previously mailed "chapter03-1,2-r9.diff", and
previously mailed "chapter03-1,2-r9-(privr8-10).diff",
in that order.
(Revision numbers mentioned in the patch are from my private svn repos)
---- BEGIN PATCH chapter03-1,2-r9-(privr10-12).diff
Index: chapter03.txt
===================================================================
--- chapter03.txt	(????? 10)
+++ chapter03.txt	(????? 12)
@@ -99,11 +99,11 @@
 implementation uses GNU gperf but... this is not the time to discuss it.
 Let us discuss this in the second part of the book.

-h3. ?????
+h3. Data Structure

-????????????????????????????
-????????????????????????????
-???`st_table`???????????
+Let us start looking at the source code. As written in the introductory
+chapter, if there is data and code, it is better to read the data first.
+The following is the data type of `st_table`.

 ? `st_table`
 
@@ -111,9 +111,9 @@

   16  struct st_table {
   17      struct st_hash_type *type;
-  18      int num_bins;                   /* ?????? */
-  19      int num_entries;                /* ???????????*/
-  20      struct st_table_entry **bins;   /* ???? */
+  18      int num_bins;                   /* slot count */
+  19      int num_entries;                /* total number of entries */
+  20      struct st_table_entry **bins;   /* slot */
   21  };

 (st.h)
@@ -131,40 +131,41 @@
 (st.c)
 


-`st_table`??????????????`st_table_entry`?????????
-???????`st_table_entry`??`next`?????????????????
-???????????????????????`st_hash_type`??????
-?????????????????????????????????
-?5????????????????????
+`st_table` is the main table structure. `st_table_entry` is a holder that
+stores one value. `st_table_entry` contains a member called `next` which of
+course is a linked list. This is the chain part of the chaining method.
+`st_hash_type` data type is used, but I will explaine this later. First let
+me explain the other parts so you can compare and understand the roles.

-!images/ch_name_sttable.jpg(`st_table`??????)!
+!images/ch_name_sttable.jpg(`st_table` data structure)!

-??`st_hash_type`?????????
+So, let us comment on `st_hash_type`.

 ? `struct st_hash_type`
 
   11  struct st_hash_type {
-  12      int (*compare)();   /* ???? */
-  13      int (*hash)();      /* ?????? */
+  12      int (*compare)();   /* comparison function */
+  13      int (*hash)();      /* hash function */
   14  };

 (st.h)
 


-???????3???????????????
+This is still Chapter 3 so let us examine it attentively.

 
 int (*compare)()
 


-?????????`int`?????????????????`compare`?
-???????`hash`??????????????????????
+This part shows, of course, the member `compare` which has a data type of
+"a pointer to a function that returns an `int`". `hash` is also the same.
+This variable is substituted in the following way:

 
 int
 great_function(int n)
 {
-    /* ToDo: ??????????? */
+    /* ToDo: Do something great! */
     return n;
 }

@@ -173,42 +174,48 @@
     f = great_function;
 


-??????????
+And it is called like this:

 
     (*f)(7);
 }
 


-???`st_hash_type`????????`hash compare`?????????
-???`hash`?????????? f ???????
+Here let us return to the `st_hash_type` commentary. Of the two members
+`hash` and `compare`, `hash` is the hash function f explained previously.

-???`compare`???????????????????????????
-????????? n ????????????????????????
-???????????????????????????????????
-???????????????????`compare`??
+On the other hand, `compare` is a function that evaluates if the key is the
+same or not. With the chaining method, in the spot with the same hash value
+n, multiple elements can be inserted. To know exactly which element is
+being searched for, this time it is necessary to use a comparison function
+that we can absolutely trust. `compare` will be that function.

-??`st_hash_type`??????????????????????????
-??????????????????????????`ruby`??
-`st_table`??????`ID`?`char*`?`VALUE`?????????????
-???????????????????????????????????
-???????????????????????????????????
-???????????????????????????????????
-???????????????????????????????????
-????????????????????????????????????
-??????????????????????
+This `st_hash_type` is a good generalized technique. The hash table itself
+cannot determine what the stored keys' data type will be. For example, in
+`ruby`, `st_table`'s keys are `ID` or `char*` or `VALUE`, but to write the
+same mechanism of hash for each (data type) is foolish. Usually, the things
+that change with the different key data types are things like the hash
+function. For things like memory allocation and collision detection,
+usually most of the code is the same. Only the parts where the
+implementation changes with a differing data type will bundled up into a
+function, and a pointer to that function will be used. In this fashion, the
+majority of the code that makes up the hash table implementation can
+((?????? ?= utilize it)).

-???????????????????????????????????
-???????????????????????????????????
-???????????????????????????
+In object-oriented languages, in the first place, you can attach a procedure
+to an object and pass it (around), so this mechanism is not necessary.
+Perhaps it more correct to say that this mechanism is built-in as a
+language's feature.

-h3. `st_hash_type`??
+h3. `st_hash_type` example

-`st_hash_type`????????????????????????????
-?????????????????????????????????
-`hash`?`compare`??????????????????????????
-????????????????????`st_init_numtable()`?????
-??????????????????????????????
+The usage of a data structure like `st_hash_type` is good as a
+generalization. On the other hand, what kind of code it actually passes
+through may be difficult to understand. If we do not examine what sort of
+function is used for `hash` or `compare`, we will not grasp the reality.
+For this reason, it is probably sufficient to look at `st_init_numtable()`
+introduced in the previous chapter. This function creates a table for
+integer data type keys.

 ? `st_init_numtable()`
 
@@ -221,9 +228,9 @@
 (st.c)
 


-`st_init_table()`???????????????????????
-`type_numhash`?`st_hash_type`(????????`type`)????
-??`type_numhash`???????
+`st_init_table()` is the function that allocates the table memory and so
+on. `type_numhash` becomes `st_hash_type` (it is the member name "type").
+Regarding this `type_numhash`:

 ? `type_numhash`
 
@@ -249,8 +256,8 @@
 (st.c)
 


-???????`ruby`???????????????
-??????`type_numhash`???????
+Very simple. The table that the `ruby` interpreter uses is by and large
+this `type_numhash`.

 h3. `st_lookup()`

---- END PATCH

Best regards,
Clifford Caoile
--
irb(main):001:0> p my.greeting( :"rhg-discussion" )
"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
=> nil
-------------- next part --------------
Index: chapter03.txt
===================================================================
--- chapter03.txt	(??????????????? 10)
+++ chapter03.txt	(??????????????? 12)
@@ -99,11 +99,11 @@
 implementation uses GNU gperf but... this is not the time to discuss it.
 Let us discuss this in the second part of the book. 
 
-h3. ???????????????
+h3. Data Structure
 
-??????????????????????????????????????????????
?????????????????????????????????????
-????????????????????????????????????????????????????????????????????????????????????
-?????????`st_table`?????????????????????????????????
+Let us start looking at the source code. As written in the introductory
+chapter, if there is data and code, it is better to read the data first.
+The following is the data type of `st_table`.
 
 ??? `st_table`
 
@@ -111,9 +111,9 @@
 
   16  struct st_table {
   17      struct st_hash_type *type;
-  18      int num_bins;                   /* ?????????????????? */
-  19      int num_entries;                /* ?????????????????????????????????*/
-  20      struct st_table_entry **bins;   /* ???????????? */
+  18      int num_bins;                   /* slot count */
+  19      int num_entries;                /* total number of entries */
+  20      struct st_table_entry **bins;   /* slot */
   21  };
 
 (st.h)
@@ -131,40 +131,41 @@
 (st.c)
 

 
-`st_table`??????????????????????????????????????????`st_table_entry`???????????????????????????
-?????????????????????`st_table_entry`??????`next`???????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????`st_hash_type`??????????????????
-???????????????????????????????????????????????????????????????????????????????????????????????????
-???5????????????????????????????????????????????????????????????
+`st_table` is the main table structure. `st_table_entry` is a holder that
+stores one value. `st_table_entry` contains a member called `next` which of
+course is a linked list. This is the chain part of the chaining method.
+`st_hash_type` data type is used, but I will explaine this later. First let
+me explain the other parts so you can compare and understand the roles.
 
-!images/ch_name_sttable.jpg(`st_table`??????????????????)!
+!images/ch_name_sttable.jpg(`st_table` data structure)!
 
-??????`st_hash_type`???????????????????????????
+So, let us comment on `st_hash_type`.
 
 ??? `struct st_hash_type`
 
   11  struct st_hash_type {
-  12      int (*compare)();   /* ???????????? */
-  13      int (*hash)();      /* ?????????????????? */
+  12      int (*compare)();   /* comparison function */
+  13      int (*hash)();      /* hash function */
   14  };
 
 (st.h)
 

 
-?????????????????????3?????????????????????????????????????????????
+This is still Chapter 3 so let us examine it attentively.
 
 
 int (*compare)()
 

 
-???????????????????????????`int`???????????????????????????????????????????????????`compare`???
-?????????????????????`hash`??????????????????????????????????????????????????????????
???????
+This part shows, of course, the member `compare` which has a data type of
+"a pointer to a function that returns an `int`". `hash` is also the same.
+This variable is substituted in the following way:
 
 
 int
 great_function(int n)
 {
-    /* ToDo: ????????????????????????????????? */
+    /* ToDo: Do something great! */
     return n;
 }
 
@@ -173,42 +174,48 @@
     f = great_function;
 

 
-??????????????????????????????
+And it is called like this:
 
 
     (*f)(7);
 }
 

 
-?????????`st_hash_type`????????????????????????`hash compare`???????????????????????????
-?????????`hash`?????????????????????????????? f ?????????????????????
+Here let us return to the `st_hash_type` commentary. Of the two members
+`hash` and `compare`, `hash` is the hash function f explained previously.
 
-?????????`compare`?????????????????????????????????????????????????????????????????????????????????
-??????????????????????????? n ??????????????????????????????????
?????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????
???????????????????
-?????????????????
???????????????????????????????????????`compare`??????
+On the other hand, `compare` is a function that evaluates if the key is the
+same or not. With the chaining method, in the spot with the same hash value
+n, multiple elements can be inserted. To know exactly which element is
+being searched for, this time it is necessary to use a comparison function
+that we can absolutely trust. `compare` will be that function.
 
-??????`st_hash_type`??????????????????????????????????????????????????????????????????????????????
-??????????????????????????????????????????????????????????????????????????????`ruby`??????
-`st_table`??????????????????`ID`???`char*`???`VALUE`???????????????????????????????????????
-???????
?????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-????????
????????????????????????????????????????????????????????????????????????????????????????????????
-????????????????????????????????????????????????????????????????????????????????????????????????????????????
-??????????????????????????
???????????????????????????????????????
+This `st_hash_type` is a good generalized technique. The hash table itself
+cannot determine what the stored keys' data type will be. For example, in
+`ruby`, `st_table`'s keys are `ID` or `char*` or `VALUE`, but to write the
+same mechanism of hash for each (data type) is foolish. Usually, the things
+that change with the different key data types are things like the hash
+function. For things like memory allocation and collision detection,
+usually most of the code is the same. Only the parts where the
+implementation changes with a differing data type will bundled up into a
+function, and a pointer to that function will be used. In this fashion, the
+majority of the code that makes up the hash table implementation can
+((?????????????????? ?= utilize it)).
 
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????
???????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????
+In object-oriented languages, in the first place, you can attach a procedure
+to an object and pass it (around), so this mechanism is not necessary.
+Perhaps it more correct to say that this mechanism is built-in as a
+language's feature.
 
-h3. `st_hash_type`??????
+h3. `st_hash_type` example
 
-`st_hash_type`????????????????????????????????????????????????????????????????????????????????????
-???????????????????????????????????????????????????????????????????????????????????????????????????
-`hash`???`compare`??????????????????????????????????????????????????????????????????????????????
-????????????????????????????????????????????????????????????`st_init_numtable()`???????????????
-??????????????????????????????????????????????????????????????????????????????????????????
+The usage of a data structure like `st_hash_type` is good as a
+generalization. On the other hand, what kind of code it actually passes
+through may be difficult to understand. If we do not examine what sort of
+function is used for `hash` or `compare`, we will not grasp the reality.
+For this reason, it is probably sufficient to look at `st_init_numtable()`
+introduced in the previous chapter. This function creates a table for
+integer data type keys.
 
 ??? `st_init_numtable()`
 
@@ -221,9 +228,9 @@
 (st.c)
 

 
-`st_init_table()`?????????????????????????????????????????????????????????????????????
-`type_numhash`???`st_hash_type`(????????????????????????`type`)????????????
-??????`type_numhash`?????????????????????
+`st_init_table()` is the function that allocates the table memory and so
+on. `type_numhash` becomes `st_hash_type` (it is the member name "type").
+Regarding this `type_numhash`:
 
 ??? `type_numhash`
 
@@ -249,8 +256,8 @@
 (st.c)
 

 
-?????????????????????`ruby`?????????????????????????????????????????????
-??????????????????`type_numhash`?????????????????????
+Very simple. The table that the `ruby` interpreter uses is by and large
+this `type_numhash`.
 
 h3. `st_lookup()`
 





From piyokun at gmail.com  Wed Mar 22 10:37:46 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 00:37:46 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 - part
	5, 6, 7 of 10
Message-ID: <1f748ec60603220737t5f20425ap31e8cee7ce34e345@mail.gmail.com>

Vincent:
If nobody else minds, I'll start translating parts 5, 6, 7 (of 10) ofChapter 03.
part 5: "st_table" : st_lookup()part 6: "st_table" : st_add_direct()part 7: "st_table" : st_insert()
Best regards,Clifford Caoile
--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From vincent.isambart at gmail.com  Wed Mar 22 11:10:15 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 17:10:15 +0100
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 3,
	4 of 10
In-Reply-To: <1f748ec60603220717x4de601dv8325855b058bf5@mail.gmail.com>
References: <1f748ec60603220717x4de601dv8325855b058bf5@mail.gmail.com>
Message-ID: <7d9a1f530603220810h41ffc13fjac53f5bb74b80c62@mail.gmail.com>

> Here's a translation from Japanese to English of part of Chapter 03
> "Names and name tables", parts 3, 4 of 10. I include it as an
> attachment and also inline for viewing convenience.
GREAT :)
I'll try to check everything and compare it to the Japanese but I
checked the beginning and it looks great :).
You also seem to be much faster than me, but that's nothing
astonishing in that seeing how I learn Japanese ;).

> Action items:
> 4. I don't know how to translate ????????. Gosh darn compound verbs,
> can't look them up in a dictionary.
I only found two examples searching for ???? in eijiro (www.alc.co.jp):

????????
work someone hard

???????????????
share a dirty needle with

> In the text, the explanation is one data type per hash table. Did this
> change in Ruby 1.8.x?
Yes, only one type: VALUE... I don't see any problem here...
The comparison function can use inheritance/singleton methods/whatever...

From vincent.isambart at gmail.com  Wed Mar 22 11:12:05 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Wed, 22 Mar 2006 17:12:05 +0100
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 -
	part 5, 6, 7 of 10
In-Reply-To: <1f748ec60603220737t5f20425ap31e8cee7ce34e345@mail.gmail.com>
References: <1f748ec60603220737t5f20425ap31e8cee7ce34e345@mail.gmail.com>
Message-ID: <7d9a1f530603220812y3faa1395y163e341014ca56cb@mail.gmail.com>

> If nobody else minds, I'll start translating parts 5, 6, 7 (of 10) of Chapter 03.
Well, to make everything more simple I'll say chapter 3 is yours :).
Put no problem to send them 3 by 3 :).


From j at rjimlad.org  Wed Mar 22 13:27:12 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Wed, 22 Mar 2006 18:27:12 +0000
Subject: [rhg-discussion] The rest of chapter 2
In-Reply-To: <7d9a1f530603220125g7316137fx8cf02cd92217a198@mail.gmail.com>
References: <066BFD3F-77C3-4624-B4D7-CDAC8CB206E5@rjimlad.org>
	<7d9a1f530603220125g7316137fx8cf02cd92217a198@mail.gmail.com>
Message-ID: <730AFB33-27B7-4C74-A49A-43D285BE956F@rjimlad.org>

Hi scritch,

On 22 Mar 2006, at 09:25, Vincent Isambart wrote:

>> `ifnone` is the value when a key does not have an attached value,  
>> its default
>> is `nil`. `iter_lev` is to make the hashtable reentrant  
>> (multithread safe).
>>
>> ...seems wrong to me. It should be talking about if the key does not
>> exist, surely? Because if it exists and has a nominally undefined
>> value, it should return that, not the default.
> Is the following a little better?
> `ifnone` is the value when there is no value corresponding to a key,
> its default is `nil`.
>
> nil is a value. So yes, that's what you call "the key does not exist",
> but I think the concept of a key existing or not not is a little
> strange. But there must be a way to make it more clear.

Well, I have to admit I know only the Ruby-code side to this, in which:

irb(main):001:0> a=Hash.new("foo")
=> {}
irb(main):002:0> a["bar"]
=> "foo"
irb(main):003:0> a["bar"]=nil
=> nil
irb(main):004:0> a["bar"]
=> nil
irb(main):005:0>

The current "ri" docs say:

"If this hash is subsequently accessed by a key that doesn't  
correspond to a hash entry, the value returned... if _obj_ is  
specified, [will be _obj_]."

...which I'm obviously paraphrasing a little. "A key which has not  
yet been created in the hash" might be a better way of putting it.

This is equivalent to (in perl) the difference between defined($hash 
{$invalid_key}) and exists($hash{$invalid_key}).

> PS: Really thanks for the corrections, but next time please attach the
> patch to your mail as your mailer (like most) splits some lines in
> two.

Oh! I knew that Mail.app line-wrapped, but I didn't think there were  
any long lines there. That, and I've been reading the "git" mailing  
list too long, so I'm used to seeing people demand in-line patches.  
I'll do attachments in future.

Jim


From piyokun at gmail.com  Wed Mar 22 17:19:27 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 07:19:27 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 3,
	4 of 10
In-Reply-To: <7d9a1f530603220810h41ffc13fjac53f5bb74b80c62@mail.gmail.com>
References: <1f748ec60603220717x4de601dv8325855b058bf5@mail.gmail.com>
	<7d9a1f530603220810h41ffc13fjac53f5bb74b80c62@mail.gmail.com>
Message-ID: <1f748ec60603221419x7841b2afj6f215b4bcc11d69b@mail.gmail.com>

On 3/23/06, Vincent Isambart  wrote:> > Action items:> > 4. I don't know how to translate ????????. Gosh darn compound verbs,> > can't look them up in a dictionary.> I only found two examples searching for ???? in eijiro (www.alc.co.jp):
> ???????????????> share a dirty needle with
I think this is the meaning I'm looking for: "share", as in: "In thisfashion, the majority of the code that makes up the hash tableimplementation can share it." (BTW, great example, heh heh)
> > In the text, the explanation is one data type per hash table. Did this> > change in Ruby 1.8.x?> Yes, only one type: VALUE... I don't see any problem here...> The comparison function can use inheritance/singleton methods/whatever...
Whoa. So in the example I had, the keys that were either ruby symbols,ruby strings, or integers were converted into VALUEs and thendo_hash()'d?
Best regards,Clifford Caoile--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From vincent.isambart at gmail.com  Thu Mar 23 03:53:55 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 09:53:55 +0100
Subject: [rhg-discussion] News
Message-ID: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>

Hi everyone,

First, I've made some changes in the repository, splitting it in
directories by language. I'm not sure we'll later have multiple
languages in the repository, but if so it's easier to reorganize now.
And even if we do not, I do not see any problem in this
reorganisation.

Clifford and Meinrad have been granted access to the repository.
You've already seen Clifford's translation in the ML, and Meirad sent
me his first version of the diagrams. If you do not have a crappy
proxy like I do, you should be able to see them here:
http://rhg.rubyforge.org/chapter04.html (note that the chapter 4 has
not changed since yesterday, there are still crappy sentences).

Of course you are welcome to review the diagrams and tell what you
like/don't like :). We should maybe do a page with the explation for
the different symbols. Could you do a diagrams explaining all that
Meirad?

If I have some time this evening, I should be able to put chapter 6 in
the repository tomorrow. This week-end I'll finish chapter 4 and will
probably start a new one (I've yet to decide which one).

Cheers,
Vincent


From vincent.isambart at gmail.com  Thu Mar 23 04:31:11 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 10:31:11 +0100
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 3,
	4 of 10
In-Reply-To: <1f748ec60603221419x7841b2afj6f215b4bcc11d69b@mail.gmail.com>
References: <1f748ec60603220717x4de601dv8325855b058bf5@mail.gmail.com>
	<7d9a1f530603220810h41ffc13fjac53f5bb74b80c62@mail.gmail.com>
	<1f748ec60603221419x7841b2afj6f215b4bcc11d69b@mail.gmail.com>
Message-ID: <7d9a1f530603230131m681dc4f7y114e28dee52a396f@mail.gmail.com>

> > > In the text, the explanation is one data type per hash table.
> > Yes, only one type: VALUE... I don't see any problem here...
> > The comparison function can use inheritance/singleton methods/whatever...
> Whoa. So in the example I had, the keys that were either ruby symbols,ruby strings, or
> integers were converted into VALUEs and thendo_hash()'d?
Converted? No. In C, any Ruby object is a VALUE (cf chapter 2).


From meinrad.recheis at gmail.com  Thu Mar 23 05:02:50 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Thu, 23 Mar 2006 11:02:50 +0100
Subject: [rhg-discussion] News
In-Reply-To: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>
References: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>
Message-ID: <43d756720603230202q7dfbdd85p8e4b81bc581067e0@mail.gmail.com>

On 3/23/06, Vincent Isambart  wrote:
> Hi everyone,
>
> First, I've made some changes in the repository, splitting it in
> directories by language. I'm not sure we'll later have multiple
> languages in the repository, but if so it's easier to reorganize now.
> And even if we do not, I do not see any problem in this
> reorganisation.
>
> Clifford and Meinrad have been granted access to the repository.
> You've already seen Clifford's translation in the ML, and Meirad sent
> me his first version of the diagrams. If you do not have a crappy
> proxy like I do, you should be able to see them here:
> http://rhg.rubyforge.org/chapter04.html (note that the chapter 4 has
> not changed since yesterday, there are still crappy sentences).
>
> Of course you are welcome to review the diagrams and tell what you
> like/don't like :). We should maybe do a page with the explation for
> the different symbols. Could you do a diagrams explaining all that
> Meirad?
of course!

i have two remarks to the diagrams:
i will remove the shape of "singleton class" and replace it by a
normal round shape but use grey colors. i think that is much better
and less visual noise. i you look at the last diagram you will see
that all the include classes are grey. i made them grey because they
are not visible on the Ruby level. singleton classes are also not
visible so i will use the same style for them.

of course any comments, etc about the diagrams are welcome.
@native speakers: please review the texts inside the diagrams!

take care,
-- henon


From vincent.isambart at gmail.com  Thu Mar 23 07:20:10 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 13:20:10 +0100
Subject: [rhg-discussion] Choice of vocabulary
Message-ID: <7d9a1f530603230420q76f3661l8fdf11ea4f1f8b8e@mail.gmail.com>

Hi everyone,

For the translations of chapter 2 and 4 I used the word "diagram",
whereas Clifford what came first to his mind while making his
translation, which is "figure".

Which one do you think feels more natural? Either way, it just takes 5
minutes to change it, but it's better to standardize it...

Cheers,
Vincent


From piyokun at gmail.com  Thu Mar 23 09:09:01 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 23:09:01 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 5, 6,
	7 of 10
Message-ID: <1f748ec60603230609p3ce53cc7wa34f862f6a1c0ed8@mail.gmail.com>

Here's a translation from Japanese to English of part of Chapter 03
"Names and name tables", parts 5, 6, 7 of 10. I "svn commit"-ted it
already, but I will continute to attach and inline post it here for
viewing convenience.

Chapter 03 : "Names and name tables"
part 5: "st_table" : st_lookup()
part 6: "st_table" : st_add_direct()
part 7: "st_table" : st_insert()

Summary: Let's add data to our hash table! Here we have some simple
link list implementation, which gets Lisp cons-y. No figures to
translate here.

Action items:
8. I don't know what ? and ? mean. I suppose it means true and false
respectively?

Patch is already commited as svn://rubyforge.org/var/svn/rhg -r19
---- BEGIN PATCH
Index: en/chapter03.txt

===================================================================

--- en/chapter03.txt	(????? 18)

+++ en/chapter03.txt	(????? 19)

@@ -261,8 +261,9 @@


 h3. `st_lookup()`

-???????????????????????????????????
-?????????????????????`st_lookup()`???????
+Now then, let us look at the function that uses this data structure. At first,
+it is good to look at the function that does the search. Shown below is the
+function that searches the hash table, `st_lookup()`.

 ? `st_lookup()`
 
@@ -290,8 +291,8 @@

 (st.c)
 


-???????????`do_hash()`?`FIND_ENTRY()`???????????
-??????
+The important parts are pretty much in `do_hash()` and `FIND_ENTRY()`. Let us
+look at them in order.

 ? `do_hash()`
 
@@ -300,17 +301,18 @@

 (st.c)
 


-??????????????????????
+Just in case, let us write down the macro body that is difficult to understand:

 
 (table)->type->hash
 


-????????????`key`???????????????????
-`*`?`table`??????????????????????????
-`type->hash`????`key`??????????????????????
+is a function pointer where the `key` is passed as a parameter. This is the
+syntax for calling the function. `*` is not applied to `table`. In other words,
+this macro is a hash value generator for a `key`, using the prepared hash
+function `type->hash` for each data type.

-???`FIND_ENTRY()`????
+Continuing, let us examine `FIND_ENTRY()`.

 ? `FIND_ENTRY()`
 
@@ -335,35 +337,38 @@

 (st.c)
 


-`COLLISION`???????????????????(????)?
+`COLLISION` is a macro for debug so we will (should) ignore it.

-`FIND_ENTRY()`???????
+The parameters of `FIND_ENTRY()`, starting from the left are:

 # `st_table`
-# ???????????
-# ?????
-# ????
+# the found entry will be substituted into this parameter
+# hash value
+# temporary variable

-???????????????????`st_table_entry*`???????
+And, the second parameter will store the found `st_table_entry*`.

-??????????????????????????????`do`?
-`while(0)`??????????`ruby`???????C?????????
-?????????`if(1)`??`else`?????????????
-`while(1)`?????`break`???????
+At the outermost side, a `do` .. `while(0)` is used to safely wrap up a
+multiple expression macro. This is `ruby`'s, rather, C language's preprocessor
+idiom. In the case of `if(1)`, there may be a danger of adding an `else` part.
+In the case of `while(1)`, it becomes necessary to add a `break` at the very
+end.

-`while(0)`???????????????????????????
+Also, there is no semicolon added after the `while(0)`.

 
 FIND_ENTRY();
 


-????????????????????????????????
+This is so that the semicolon that is normally written at the end of an
+expression will not go to waste.

 h3. `st_add_direct()`

-??????????????????????????`st_add_direct()`?
-??????????????????????????????????
-?????????????????????????`direct`??????
+Continuing on, let us examine `st_add_direct()` which is a function that adds a
+new relation to the hash table. This function does not check if the key is
+already registered. It always adds a new entry. This is the meaning of `direct`
+in the function name.

 ? `st_add_direct()`
 
@@ -383,12 +388,12 @@

 (st.c)
 


-??????????????????`do_hash()`???????????
-?????`FIND_ENTRY()`????????????????????????
-????????
+Just as before, the `do_hash()` macro that obtains a value is called here.
+After that, the next calculation is the same as at the beginning of
+`FIND_ENTRY()`, which is to exchange the hash value for a real index.

-??????????`ADD_DIRECT()`??????????????????
-???????????????????????????
+Then the insertion operation looks like it is implemented by `ADD_DIRECT()`.
+Since the name is all uppercase, we can anticipate that is a macro.

 ? `ADD_DIRECT()`
 
@@ -416,23 +421,23 @@

 (st.c)
 


-???`if`??????????????????????????
+The first `if` is an exception case so I will explain it afterwards.

-(A)`st_table_entry`????????????
+(A)Allocate and initialize a `st_table_entry`.

-(B)`entry`?????????????
-???????????????????????
+(B)Insert the `entry` into the start of the list.
+This is the idiom for handling the list. In other words,

 
 entry->next = list_beg;
 list_beg = entry;
 


-????????????????????????Lisp???????
-?cons(???)??????????????`list_beg`?`NULL`??
-???????????????????
+makes it possible to insert an entry to the front of the list. This is similar
+to "cons-ing" in the Lisp language. Check for yourself that even if `list_beg`
+is NULL, this code holds true.

-??????????????????????
+Finally, let me explain the code I left aside.

 ? `ADD_DIRECT()`-`rehash`
 
@@ -445,13 +450,13 @@

 (st.c)
 


-`DENSITY`??????????????????????????????
-????????????
-`st_table`????`bin_pos`????????????????????
-???????????????????`bin`????
-???????????????`bin`????????????????
+`DENSITY` is "concentration". In other words, this conditional checks if the
+hash table is "crowded" or not. In the `st_table`, as the number of values that
+use the same `bin_pos` increases, the longer the link list becomes. In other
+words, search becomes slower. That is why for `bin` count, when the element
+count becomes too many, `bin` is increased and the crowding is reduced.

-??`ST_DEFAULT_MAX_DENSITY`?
+The current `ST_DEFAULT_MAX_DENSITY` is

 ? `ST_DEFAULT_MAX_DENSITY`
 
@@ -460,13 +465,13 @@

 (st.c)
 


-??????????????`bin_pos`????`st_table_entry`?????
-?????????????????????????????
+Because of this setting, if in all `bin_pos` there are 5 `st_table_entries`
+linked up, then the size will be increased.

 h3. `st_insert()`

-`st_insert()`?`st_add_direct()`?`st_lookup()`?????????????
-???????????????
+`st_insert()` is nothing more than combining `st_add_direct()` and
+`st_lookup()` together, so if you understand those two, this will be easy.

 ? `st_insert()`
 
@@ -495,9 +500,9 @@

 (st.c)
 


-????????????????????????
-??????????????????
-??????????????????????????
+It checks if the element is already registered in the table. Only when it is
+not registered will it be added. If there is a insertion, return 0. If there is
+no insertion, return a 1.

 h2. `ID`?????

---- END PATCH

Best regards,
Clifford Caoile
--
irb(main):001:0> p my.greeting( :"rhg-discussion" )
"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
=> nil
-------------- next part --------------
Index: en/chapter03.txt
===================================================================
--- en/chapter03.txt	(??????????????? 18)
+++ en/chapter03.txt	(??????????????? 19)
@@ -261,8 +261,9 @@
 
 h3. `st_lookup()`
 
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-???????????????????????????????????????????????????????????????`st_lookup()`?????????????????????
+Now then, let us look at the function that uses this data structure. At first,
+it is good to look at the function that does the search. Shown below is the
+function that searches the hash table, `st_lookup()`.
 
 ??? `st_lookup()`
 
@@ -290,8 +291,8 @@
 (st.c)
 

 
-?????????????????????????????????`do_hash()`???`FIND_ENTRY()`?????????????????????????????????
-??????????????????
+The important parts are pretty much in `do_hash()` and `FIND_ENTRY()`. Let us
+look at them in order.
 
 ??? `do_hash()`
 
@@ -300,17 +301,18 @@
 (st.c)
 

 
-??????????????????????????????????????????????????????????????????
+Just in case, let us write down the macro body that is difficult to understand:
 
 
 (table)->type->hash
 

 
-????????????????????????????????????`key`?????????????????????????????????????????????????????????
-`*`???`table`??????????????????????????????????????????????????????????????????????????????
-`type->hash`????????????`key`??????????????????????????????????????????????????????????????????
+is a function pointer where the `key` is passed as a parameter. This is the
+syntax for calling the function. `*` is not applied to `table`. In other words,
+this macro is a hash value generator for a `key`, using the prepared hash
+function `type->hash` for each data type.
 
-?????????`FIND_ENTRY()`????????????
+Continuing, let us examine `FIND_ENTRY()`.
 
 ??? `FIND_ENTRY()`
 
@@ -335,35 +337,38 @@
 (st.c)
 

 
-`COLLISION`?????????????????????????????????????????????????????????(????????????)???
+`COLLISION` is a macro for debug so we will (should) ignore it.
 
-`FIND_ENTRY()`?????????????????????
+The parameters of `FIND_ENTRY()`, starting from the left are:
 
 # `st_table`
-# ?????????????????????????????????
-# ???????????????
-# ????????????
+# the found entry will be substituted into this parameter
+# hash value
+# temporary variable
 
-?????????????????????????????????????????????????????????`st_table_entry*`?????????????????????
+And, the second parameter will store the found `st_table_entry*`.
 
-???????????????????????????????????????????????????????????????????
??????????????????????`do`???
-`while(0)`??????????????????????????????`ruby`?????????????????????C???????????????????????????
-???????????????????????????`if(1)`??????`else`???????????????????????????????????????
-`while(1)`???????????????`break`?????
???????????????
+At the outermost side, a `do` .. `while(0)` is used to safely wrap up a
+multiple expression macro. This is `ruby`'s, rather, C language's preprocessor
+idiom. In the case of `if(1)`, there may be a danger of adding an `else` part.
+In the case of `while(1)`, it becomes necessary to add a `break` at the very
+end.
 
-`while(0)`?????????????????????????????????????????????????????????????????????????????????
+Also, there is no semicolon added after the `while(0)`.
 
 
 FIND_ENTRY();
 

 
-????????????????????????????????????????????????????????????????????????????????????????????????
+This is so that the semicolon that is normally written at the end of an
+expression will not go to waste.
 
 h3. `st_add_direct()`
 
-??????????????????????????????????????????????????????????????????????????????`st_add_direct()`???
-??????????????????????????????????????????????????????????????????????????????????????????????????????
-???????????????????????????????????????????????????????????????????????????`direct`??????????????????
+Continuing on, let us examine `st_add_direct()` which is a function that adds a
+new relation to the hash table. This function does not check if the key is
+already registered. It always adds a new entry. This is the meaning of `direct`
+in the function name.
 
 ??? `st_add_direct()`
 
@@ -383,12 +388,12 @@
 (st.c)
 

 
-?
????????????????????????????????????????????????????`do_hash()`?????????????????????????????????
-???????????????`FIND_ENTRY()`????????????????????????????????????????????????????????????????????????
-????????????????????????
+Just as before, the `do_hash()` macro that obtains a value is called here.
+After that, the next calculation is the same as at the beginning of
+`FIND_ENTRY()`, which is to exchange the hash value for a real index.
 
-?????????????
????????????????`ADD_DIRECT()`??????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????
+Then the insertion operation looks like it is implemented by `ADD_DIRECT()`.
+Since the name is all uppercase, we can anticipate that is a macro.
 
 ??? `ADD_DIRECT()`
 
@@ -416,23 +421,23 @@
 (st.c)
 

 
-?????????`if`??????????????????????????????????????????????????????????????????????????????
+The first `if` is an exception case so I will explain it afterwards.
 
-(A)`st_table_entry`????????????????????????????????????
+(A)Allocate and initialize a `st_table_entry`. 
 
-(B)`entry`????????????????
??????????????????????
-?????????????????????????????????????????????????????????????????????
+(B)Insert the `entry` into the start of the list.
+This is the idiom for handling the list. In other words,
 
 
 entry->next = list_beg;
 list_beg = entry;
 

 
-????????????????
???????????????????????????????????????????????????????Lisp?????????????????????
-???cons(?????????)??????????????????????????????????????????`list_beg`???`NULL`??????
-?????????????????????????????????????????????????????????
+makes it possible to insert an entry to the front of the list. This is similar
+to "cons-ing" in the Lisp language. Check for yourself that even if `list_beg`
+is NULL, this code holds true.
 
-??????????????????????????????????????????????????????????????????
+Finally, let me explain the code I left aside.
 
 ??? `ADD_DIRECT()`-`rehash`
 
@@ -445,13 +450,13 @@
 (st.c)
 

 
-`DENSITY`??????????????????????????????????????????????????????????????????????????????????????????
-????????????????????????????????????
-`st_table`????????????`bin_pos`????????????????????????????????????????????????????????????
-???????????????????????????????????
?????????????????????`bin`????????????
-?????????????????????????????????????????????`bin`????????????????????????????????????????????????
+`DENSITY` is "concentration". In other words, this conditional checks if the
+hash table is "crowded" or not. In the `st_table`, as the number of values that
+use the same `bin_pos` increases, the longer the link list becomes. In other
+words, search becomes slower. That is why for `bin` count, when the element
+count becomes too many, `bin` is increased and the crowding is reduced.
 
-??????`ST_DEFAULT_MAX_DENSITY`???
+The current `ST_DEFAULT_MAX_DENSITY` is
 
 ??? `ST_DEFAULT_MAX_DENSITY`
 
@@ -460,13 +465,13 @@
 (st.c)
 

 
-??????????????????????????????????
???????`bin_pos`????????????`st_table_entry`???????????????
-???????????????????????????????????????????????????????????????????????????????????????
+Because of this setting, if in all `bin_pos` there are 5 `st_table_entries`
+linked up, then the size will be increased.
 
 h3. `st_insert()`
 
-`st_insert()`???`st_add_direct()`???`st_lookup()`???????????????????????????????????????
-?????????????????????????????????????????????
+`st_insert()` is nothing more than combining `st_add_direct()` and
+`st_lookup()` together, so if you understand those two, this will be easy.
 
 ??? `st_insert()`
 
@@ -495,9 +500,9 @@
 (st.c)
 

 
-????????????????????????????????????????????????????????????????????????
-??????????????????????????????????????????????????????
-??????????????????????????????????????????????????????????????????????????????
+It checks if the element is already registered in the table. Only when it is
+not registered will it be added. If there is a insertion, return 0. If there is
+no insertion, return a 1.
 
 h2. `ID`???????????????
 



From vincent.isambart at gmail.com  Thu Mar 23 09:21:55 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 15:21:55 +0100
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 5, 6,
	7 of 10
In-Reply-To: <1f748ec60603230609p3ce53cc7wa34f862f6a1c0ed8@mail.gmail.com>
References: <1f748ec60603230609p3ce53cc7wa34f862f6a1c0ed8@mail.gmail.com>
Message-ID: <7d9a1f530603230621v3d695804x16624331866cfedd@mail.gmail.com>

> Here's a translation from Japanese to English of part of Chapter 03
> "Names and name tables", parts 5, 6, 7 of 10. I "svn commit"-ted it
> already, but I will continute to attach and inline post it here for
> viewing convenience.

Just a short comment: in the text file, you should remove the 
 at
the end and what's after.


From piyokun at gmail.com  Thu Mar 23 09:22:32 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 23:22:32 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 - part
	8, 9, 10 of 10
Message-ID: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>

RHG-discussion:
Vincent says:> Well, to make everything more simple I'll say chapter 3 is yours :).> Put no problem to send them 3 by 3 :).
Just in case, I'll announce the "assignment grab" for it.If nobody else minds, I'll start translating parts 8, 9, 10 (of 10) ofChapter 03. This will finish off Chapter 03.
part 8: ID and Symbols : from char* to IDpart 9: ID and Symbols : from ID to char*part 10: ID and Symbols : Exchanging VALUE and ID
May I remind everyone, if you're looking for something proofread inEnglish, take a look at what I previously did with chapter 3, parts 1to 7 (of 10):
http://rubyforge.org/plugins/scmsvn/viewcvs.php/en/chapter03.txt?root=rhg&rev=19&view=markup
Best regards,Clifford Caoile--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From vincent.isambart at gmail.com  Thu Mar 23 09:27:32 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 15:27:32 +0100
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 -
	part 8, 9, 10 of 10
In-Reply-To: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>
References: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>
Message-ID: <7d9a1f530603230627x2ef4ba93uc2ce5925f0560061@mail.gmail.com>

Just one thing: I do not know why, but in your last mails some end of
lines seem to have disappeared, so it's a little hard to read. Maybe
it's since you put GMail in UTF-8 mode...


From piyokun at gmail.com  Thu Mar 23 09:29:46 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 23:29:46 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 5, 6,
	7 of 10
In-Reply-To: <7d9a1f530603230621v3d695804x16624331866cfedd@mail.gmail.com>
References: <1f748ec60603230609p3ce53cc7wa34f862f6a1c0ed8@mail.gmail.com>
	<7d9a1f530603230621v3d695804x16624331866cfedd@mail.gmail.com>
Message-ID: <1f748ec60603230629s2300293cq88409b72d705f170@mail.gmail.com>

> Just a short comment: in the text file, you should remove the 
 at> the end and what's after.
OK.This is now completed (svn://rubyforge.org/var/svn/rhg -r20)
Best regards,Clifford Caoile--irb(main):001:0> p my.greeting( :"rhg-discussion" )"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"=> nil

From piyokun at gmail.com  Thu Mar 23 09:40:06 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 23:40:06 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 -
	part 8, 9, 10 of 10
In-Reply-To: <7d9a1f530603230627x2ef4ba93uc2ce5925f0560061@mail.gmail.com>
References: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>
	<7d9a1f530603230627x2ef4ba93uc2ce5925f0560061@mail.gmail.com>
Message-ID: <1f748ec60603230640t3decc324w3977c4f460033e15@mail.gmail.com>

On 3/23/06, Vincent Isambart  wrote:
> Just one thing: I do not know why, but in your last mails some end of
> lines seem to have disappeared, so it's a little hard to read. Maybe
> it's since you put GMail in UTF-8 mode...

Ugh, wow it's way hard to read.
http://rubyforge.org/pipermail/rhg-discussion/2006-March/000081.html

I guess I'll turn Gmail's setting back to "Outgoing message encoding:
Use default text encoding for outgoing messages ". Hope this fixes
things... But I fear that the Japanese text may not come out
correctly.

????????????????

Best regards,
Clifford Caoile
--
irb(main):001:0> p my.greeting( :"rhg-discussion" )
"http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
=> nil

From vincent.isambart at gmail.com  Thu Mar 23 09:43:34 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Thu, 23 Mar 2006 15:43:34 +0100
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 -
	part 8, 9, 10 of 10
In-Reply-To: <1f748ec60603230640t3decc324w3977c4f460033e15@mail.gmail.com>
References: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>
	<7d9a1f530603230627x2ef4ba93uc2ce5925f0560061@mail.gmail.com>
	<1f748ec60603230640t3decc324w3977c4f460033e15@mail.gmail.com>
Message-ID: <7d9a1f530603230643k65a6321ck2b10a02298faf99d@mail.gmail.com>

> Ugh, wow it's way hard to read.
?????

> http://rubyforge.org/pipermail/rhg-discussion/2006-March/000081.html
>
> I guess I'll turn Gmail's setting back to "Outgoing message encoding:
> Use default text encoding for outgoing messages ". Hope this fixes
> things... But I fear that the Japanese text may not come out
> correctly.
>
> ????????????????
????????
Works fine :-)
It was sent as ISO-2022-JP, quite normal for a mail with some Japanese :).

From piyokun at gmail.com  Thu Mar 23 09:49:40 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Thu, 23 Mar 2006 23:49:40 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 03 -
	part 8, 9, 10 of 10
In-Reply-To: <7d9a1f530603230643k65a6321ck2b10a02298faf99d@mail.gmail.com>
References: <1f748ec60603230622yb98f73fr9ff66f8ecba5bb63@mail.gmail.com>
	<7d9a1f530603230627x2ef4ba93uc2ce5925f0560061@mail.gmail.com>
	<1f748ec60603230640t3decc324w3977c4f460033e15@mail.gmail.com>
	<7d9a1f530603230643k65a6321ck2b10a02298faf99d@mail.gmail.com>
Message-ID: <1f748ec60603230649g59868239k767a3ca55efb9c5c@mail.gmail.com>

> > ????????????????
> ????????
> Works fine :-)
> It was sent as ISO-2022-JP, quite normal for a mail with some Japanese :).

OK, I'm pretty new at this email thing. ;-) or at least it seems like it, ha.

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"

From j at rjimlad.org  Thu Mar 23 13:31:17 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Thu, 23 Mar 2006 18:31:17 +0000
Subject: [rhg-discussion] News
In-Reply-To: <43d756720603230202q7dfbdd85p8e4b81bc581067e0@mail.gmail.com>
References: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>
	<43d756720603230202q7dfbdd85p8e4b81bc581067e0@mail.gmail.com>
Message-ID: <8E56F420-0630-477E-845A-291124BA0412@rjimlad.org>

Hi,

On 23 Mar 2006, at 10:02, Meinrad Recheis wrote:

> On 3/23/06, Vincent Isambart  wrote:
>> Of course you are welcome to review the diagrams and tell what you
>> like/don't like :). We should maybe do a page with the explation for
>> the different symbols. Could you do a diagrams explaining all that
>> Meirad?
> of course!
>
> i have two remarks to the diagrams:
> i will remove the shape of "singleton class" and replace it by a
> normal round shape but use grey colors. i think that is much better
> and less visual noise. i you look at the last diagram you will see
> that all the include classes are grey. i made them grey because they
> are not visible on the Ruby level. singleton classes are also not
> visible so i will use the same style for them.
>
> of course any comments, etc about the diagrams are welcome.
> @native speakers: please review the texts inside the diagrams!

Native English speakers, I assume? :)

It might be an idea to have the source SVG for the images non-gzipped  
so that useful diffs can be made. Yeah, that'd make the whole  
repository rather large, but incremental updates would be easier.

Anyway:
en/diagrams/chapter04-diagram01.svgz (aka ch_class_addsclass.png):  
"state" would be a better choice than "condition" there.
en/diagrams/chapter04-diagram03.svgz (aka ch_class_reqlink.png): it's  
common to write "first class" as "first-class"; that should also help  
affirm that we're not actually talking about 'classes' here.
en/diagrams/chapter04-diagram13.svgz (aka ch_class_simulate.png):  
"loop iteration" may be better than "loop cycle"

It might also be worthwhile making the word "obj" bold or italic when  
it appears in the diagrams in a descriptive label (eg "obj's real  
class") - I think by convention it would be italic - to indicate that  
we're referring to a specifically named part of the diagram.

Jim

From j at rjimlad.org  Thu Mar 23 13:35:31 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Thu, 23 Mar 2006 18:35:31 +0000
Subject: [rhg-discussion] Choice of vocabulary
In-Reply-To: <7d9a1f530603230420q76f3661l8fdf11ea4f1f8b8e@mail.gmail.com>
References: <7d9a1f530603230420q76f3661l8fdf11ea4f1f8b8e@mail.gmail.com>
Message-ID: <569099DF-92DA-4032-8B52-9915F7384C1A@rjimlad.org>

Hi Vincent,

On 23 Mar 2006, at 12:20, Vincent Isambart wrote:

> For the translations of chapter 2 and 4 I used the word "diagram",
> whereas Clifford what came first to his mind while making his
> translation, which is "figure".
>
> Which one do you think feels more natural? Either way, it just takes 5
> minutes to change it, but it's better to standardize it...

Interesting question... I think they're basically interchangeable,  
but  in books it seems to be normal to use "figure" so that you can  
refer to "figure 4" and the like (which somehow is hard to read as  
"diagram 4"). Looking at "Agile Web Development with Rails", that  
uses "figure" everywhere, so I suppose that's the best bet.

Jim

From meinrad.recheis at gmail.com  Thu Mar 23 20:56:15 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Fri, 24 Mar 2006 02:56:15 +0100
Subject: [rhg-discussion] News
In-Reply-To: <8E56F420-0630-477E-845A-291124BA0412@rjimlad.org>
References: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>
	<43d756720603230202q7dfbdd85p8e4b81bc581067e0@mail.gmail.com>
	<8E56F420-0630-477E-845A-291124BA0412@rjimlad.org>
Message-ID: <43d756720603231756v6b37ca56v9c7b19f2af6437a5@mail.gmail.com>

On 3/23/06, Jim Driscoll  wrote:
[...]
> Native English speakers, I assume? :)
>
> It might be an idea to have the source SVG for the images non-gzipped
> so that useful diffs can be made. Yeah, that'd make the whole
> repository rather large, but incremental updates would be easier.

ok.
>
> Anyway:
> en/diagrams/chapter04-diagram01.svgz (aka ch_class_addsclass.png):
> "state" would be a better choice than "condition" there.
> en/diagrams/chapter04-diagram03.svgz (aka ch_class_reqlink.png): it's
> common to write "first class" as "first-class"; that should also help
> affirm that we're not actually talking about 'classes' here.
> en/diagrams/chapter04-diagram13.svgz (aka ch_class_simulate.png):
> "loop iteration" may be better than "loop cycle"
>
> It might also be worthwhile making the word "obj" bold or italic when
> it appears in the diagrams in a descriptive label (eg "obj's real
> class") - I think by convention it would be italic - to indicate that
> we're referring to a specifically named part of the diagram.
>
> Jim

thanks Jim! going to change that tomorrow *yawn* ;)

news: i added a Rakefile to ./en that generates the *.html and *.png
files if their sources have changed. since the png's are also part of
the repository there should not be any troubles for those who don't
have inkscape installed (i hope). otherwise i add annother rake target
:images that is not required by :default.

good night,
-- henon


From vincent.isambart at gmail.com  Fri Mar 24 05:49:31 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Fri, 24 Mar 2006 11:49:31 +0100
Subject: [rhg-discussion] Chapter 6
Message-ID: <7d9a1f530603240249g6af5dfd9oc7fe913e48273fe4@mail.gmail.com>

Hi everyone,

Chapter 6 is now in the repository, open for review :).
I also changed most of the "diagram" to "figure".
Here is the translation of the figures:
- figure 1: no Japanese text
- figure 2:
  * ?????? = variable is undefined
  * ????? = variable is defined
  * ????? = a warning appears
  * ?????????????? = can be read like a normal variable
  * ?????????????? (this line is twice in the diagram) = can be
written like a normal variable
  * undef_setter????????? = transition to the state below done by undef_setter

A little note for the Ruby scripts: I'd prefer if the indentation used
was always two spaces, no tabs (yes that's for you, Meinrad ;)).

This week-end I won't be able to check my mails, but I'll finish
correcting chapter 4 and will begin working on chapter 9.

Cheers,
Vincent

From piyokun at gmail.com  Fri Mar 24 09:41:25 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Fri, 24 Mar 2006 23:41:25 +0900
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 8, 9,
	10 of 10
Message-ID: <1f748ec60603240641h3e1a2b0dm6d3f385628ea906e@mail.gmail.com>

Here's a translation from Japanese to English of part of Chapter 03
"Names and name tables", parts 8,9,10  of 10. I "svn commit"-ted it
already, but I will continute to attach and inline post it here for
viewing convenience.

Chapter 03 : "Names and name tables"
part 8: ID and Symbols : from char* to ID
part 9: ID and Symbols : from ID to char*
part 10: ID and Symbols : Converting VALUE and ID

Summary: Finally the magic of symbols. Wait there's nothing very
magical about them. Convert a char* to unsigned int. Convert it back.
Ho hum. There is however a discussion on the consistancy of the
boundary policy between the Ruby API and other C code regarding
memory. It actually makes using the Ruby API easy to chain, or so Aoki
claims.

This completes the initial translation of Chapter 3 "Names and name
tables" so I would appreciate a review of the translation and
proofreading in English. There are no figures to translate here.

Action items:
9. This is where I'm unsure of the translation, so I added my own
clarifications by using "(())" (double parentheses).

Patch is already commited as svn://rubyforge.org/var/svn/rhg -r23
---- BEGIN PATCH
Index: en/chapter03.txt

===================================================================
--- en/chapter03.txt	(????? 22)
+++ en/chapter03.txt	(????? 23)
@@ -504,21 +504,21 @@

 not registered will it be added. If there is a insertion, return 0. If there is
 no insertion, return a 1.

-h2. `ID`?????
+h2. `ID` and Symbols

-`ID`?????????????????????????????????
-???????????????????????????????????
-`unsigned int`??
+I've already discussed what an `ID` is. It is an correspondence between an
+arbitrary string of characters and a value. It is used to declare various
+names. The actual data type is `unsigned int`.

-h3. `char*`??`ID`
+h3. From `char*` to `ID`

-?????`ID`?????`rb_intern()`???????
-????????????????????????
+The conversion from string to `ID` is executed by `rb_intern()`. This function
+is rather long, so let's omit the middle.

-? `rb_intern()`(???)
+? `rb_intern()` (simplified)
 
-5451  static st_table *sym_tbl;       /*  char* ? ID   */
-5452  static st_table *sym_rev_tbl;   /*  ID ? char*   */
+5451  static st_table *sym_tbl;       /*  char* to ID   */
+5452  static st_table *sym_rev_tbl;   /*  ID to char*   */

 5469  ID
 5470  rb_intern(name)
@@ -528,13 +528,14 @@

 5474      ID id;
 5475      int last;
 5476
-          /* ??name?????ID?????????????? */
+          /* If for a name, there is a corresponding ID that is already
+          registered, then return that ID */
 5477      if (st_lookup(sym_tbl, name, &id))
 5478          return id;

-          /* ???????ID??? */
+          /* omitted ... create a new ID */

-          /* name?ID???????? */
+          /* register the name and ID relation */
 5538    id_regist:
 5539      name = strdup(name);
 5540      st_add_direct(sym_tbl, name, id);
@@ -545,25 +546,26 @@

 (parse.y)
 


-????`ID`???????`st_table`??????????
-???????????????
+The string and `ID` correspondence relation can be accomplished by using the
+`st_table`. There probably isn't any especially difficult part here.

-????????????????????????????????
-??????????????????????????????
-?????`ID`????
-?????????????????`ID`?????????????????
-?????????????
+What is the omitted section doing? It is treating global variable names and
+instance variables names as special and flagging ((attributing?)) them. This is
+because in the parser, it is necessary to know the variable's classification
+((scope? either ID_GLOBAL, ID_CLASS or ID_INSTANCE var)) from the
`ID`. However,
+the fundamental part of `ID` is unrelated to this, so I won't explain it here.

-h3. `ID`??`char*`
+h3. From `ID` to `char*`

-`rb_intern()`???`ID`??`char*`??????????`rb_id2name()`????
-????????`id2name`?2?to?????to?two?????????
-??????????????????????????????????
+The reverse of `rb_intern()` is `rb_id2name(), which takes an `ID` and
+generates a `char*`. You probably know this, but the 2 in `id2name` is "to".
+"To" and "two" have the same pronounciation, so "2" is used for "to". This
+syntax is often seen.

-?????`ID`???????????????????????????
-??????????????????
+This function also sets the `ID` classification flags so it is long. Let me
+simplify it.

-? `rb_id2name()`(???)
+? `rb_id2name()` (simplified)
 
 char *
 rb_id2name(id)
@@ -577,23 +579,25 @@

 }
 


-????????????????????
-???????????????????
+Maybe it seems that it is a little over-simplified, but in reality if we remove
+the details it really becomes this simple.

-???????????????`name`???????????????`ruby`?
-API?????????`free()`???????(???????)?????
-????????????????????????????????????
-`ruby`????????????????????
+The point I want to emphasize is that the found `name` is not copied. The
+`ruby` API does not require (((rather)), it forbids) the `free()`-ing of the
+return value. Also, when parameters are passed ((to the `ruby` API)), it always
+copies them. In other words, the creation and release ((of memory)) is
+completed by one side, either by the user or by `ruby`.

-????????????????????(?????????????)
-???????????????????Ruby???????????????
-??????????Ruby??????????????????????
-?????????????????????
+So then, when creation and release cannot be accomplished (when passed it is
+not returned) on a value, then a Ruby object is used. I have not yet discussed
+it, but a Ruby object is automatically released when it is no longer needed,
+even if we are not taking care of the object.

-h3. `VALUE`?`ID`???
+h3. Converting `VALUE` and `ID`

-`ID`?Ruby?????`Symbol`?????????????????`"string".intern`?
-????????????????`String#intern`????`rb_str_intern()`??
+`ID` is shown as an instance of the `Symbol` class at the Ruby level.
+And it can be obtained like so: `"string".intern`. The implementation of
+`String#intern` is `rb_str_intern()`.

 ? `rb_str_intern()`
 
@@ -615,16 +619,16 @@

 (string.c)
 


-?????`ruby`??????????????????????????
-`RSTRING()`?????????????????????????????
-????????
+This function is quite reasonable as a `ruby` class library code example.
+Please pay attention to the part where `RSTRING()` is used and casted, and
+where the data structure's member is accessed.

-??????????`rb_raise()`????????????????????
-????????`rb_intern()`????`ID2SYM()`????`ID2SYM()`?`ID`?
-`Symbol`????????????
+Let's read the code. First, `rb_raise()` is merely error handling so we ignore
+it for now. The `rb_intern()` we previously examined is here, and also ID2SYM
+is here. `ID2SYM()` is a macro that converts `ID` to `Symbol`.

-?????????`Symbol#to_s`???????
-?????`sym_to_s`????
+And the reverse operation is accomplished by `Symbol#to_s` and such.
+The implementation is in `sym_to_s`.

 ? `sym_to_s()`
 
@@ -638,10 +642,11 @@

 (object.c)
 


-`SYM2ID()`?`Symbol`(`VALUE`)?`ID`????????????
+`SYM2ID()` is the macro that converts `Symbol` (`VALUE`) to an `ID`.

-???????????????????????????????????
-`rb_id2name()`?`free()`???????`char*`????`rb_str_new2()`????
-`char*`????????(??????????????)??????
-?????????????????????????????
-
+It looks like the function is ((not doing anything unreasonable)). However, it
+is probably necessary to pay attention to the area around the memory handling.
+`rb_id2name()` returns a `char*` that must not be `free()`. `rb_str_new2()`
+copies the parameter's `char*` and uses ((the copy)) (and does not change the
+parameter). In this way the policy is consistent, which allows ((the
line)) to be
+written just by chaining the functions.
---- END PATCH

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
-------------- next part --------------
Index: en/chapter03.txt
===================================================================
--- en/chapter03.txt	(??????????????? 22)
+++ en/chapter03.txt	(??????????????? 23)
@@ -504,21 +504,21 @@
 not registered will it be added. If there is a insertion, return 0. If there is
 no insertion, return a 1.
 
-h2. `ID`???????????????
+h2. `ID` and Symbols
 
-`ID`???????????????????????????????????????????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-`unsigned int`??????
+I've already discussed what an `ID` is. It is an correspondence between an
+arbitrary string of characters and a value. It is used to declare various
+names. The actual data type is `unsigned int`.
 
-h3. `char*`??????`ID`
+h3. From `char*` to `ID`
 
-???????????????`ID`???????????????`rb_intern()`?????????????????????
-????????????????????????????????????????????????????????????????????????
+The conversion from string to `ID` is executed by `rb_intern()`. This function
+is rather long, so let's omit the middle.
 
-??? `rb_intern()`(?????????)
+??? `rb_intern()` (simplified)
 
-5451  static st_table *sym_tbl;       /*  char* ??? ID   */
-5452  static st_table *sym_rev_tbl;   /*  ID ??? char*   */
+5451  static st_table *sym_tbl;       /*  char* to ID   */
+5452  static st_table *sym_rev_tbl;   /*  ID to char*   */
 
 5469  ID
 5470  rb_intern(name)
@@ -528,13 +528,14 @@
 5474      ID id;
 5475      int last;
 5476
-          /* ??????name???????????????ID?????????????????????????????????????????? */
+          /* If for a name, there is a corresponding ID that is already
+          registered, then return that ID */
 5477      if (st_lookup(sym_tbl, name, &id))
 5478          return id;
 
-          /* ?????????????????????ID????????? */
+          /* omitted ... create a new ID */
 
-          /* name???ID???????????????????????? */
+          /* register the name and ID relation */
 5538    id_regist:
 5539      name = strdup(name);
 5540      st_add_direct(sym_tbl, name, id);
@@ -545,25 +546,26 @@
 (parse.y)
 

 
-????????????`ID`?????????????????????`st_table`??????????????????????????????
-?????????????????????????????????????????????
+The string and `ID` correspondence relation can be accomplished by using the
+`st_table`. There probably isn't any especially difficult part here.
 
-????????????????????????????????????????????????????????????????????????????????????????????????
-??????????????????????????????????????????????????????????????????????????????????????????
-???????????????`ID`????????????
-???????????????????????????????????????????????????`ID`???????????????????????????????????????????????????
-???????????????????????????????????????
+What is the omitted section doing? It is treating global variable names and
+instance variables names as special and flagging ((attributing?)) them. This is
+because in the parser, it is necessary to know the variable's classification
+((scope? either ID_GLOBAL, ID_CLASS or ID_INSTANCE var)) from the `ID`. However,
+the fundamental part of `ID` is unrelated to this, so I won't explain it here.
 
-h3. `ID`??????`char*`
+h3. From `ID` to `char*`
 
-`rb_intern()`?????????`ID`??????`char*`??????????????????????????????`rb_id2name()`????????????
-????????????????????????`id2name`???2???to???????????????to???two???????????????????????????
-??????????????????????????????????????????????????????????????????????????????????????????????????????
+The reverse of `rb_intern()` is `rb_id2name(), which takes an `ID` and
+generates a `char*`. You probably know this, but the 2 in `id2name` is "to".
+"To" and "two" have the same pronounciation, so "2" is used for "to". This
+syntax is often seen.
 
-???????????????`ID`?????????????????????????????????????????????????????????????????????????????????
-??????????????????????????????????????????????????????
+This function also sets the `ID` classification flags so it is long. Let me
+simplify it.
 
-??? `rb_id2name()`(?????????)
+??? `rb_id2name()` (simplified)
 
 char *
 rb_id2name(id)
@@ -577,23 +579,25 @@
 }
 

 
-????????????????????????????????????????????????????????????
-?????????????????????????????????????????????????????????
+Maybe it seems that it is a little over-simplified, but in reality if we remove
+the details it really becomes this simple.
 
-?????????????????????????????????????????????`name`?????????????????????????????????????????????`ruby`???
-API???????????????????????????`free()`?????????????????????(?????????????????????)???????????????
-????????????????????????????????????????????????????????????????????????????????????????????????????????????
-`ruby`????????????????????????????????????????????????????????????
+The point I want to emphasize is that the found `name` is not copied. The
+`ruby` API does not require (((rather)), it forbids) the `free()`-ing of the
+return value. Also, when parameters are passed ((to the `ruby` API)), it always
+copies them. In other words, the creation and release ((of memory)) is
+completed by one side, either by the user or by `ruby`.
 
-????????????????????????????????????????????????????????????(???????????????????????????????????????)
-?????????????????????????????????????????????????????????Ruby?????????????????????????????????????????????
-??????????????????????????????Ruby??????????????????????????????????????????????????????????????????
-???????????????????????????????????????????????????????????????
+So then, when creation and release cannot be accomplished (when passed it is
+not returned) on a value, then a Ruby object is used. I have not yet discussed
+it, but a Ruby object is automatically released when it is no longer needed,
+even if we are not taking care of the object.
 
-h3. `VALUE`???`ID`?????????
+h3. Converting `VALUE` and `ID`
 
-`ID`???Ruby???????????????`Symbol`???????????????????????????????????????????????????`"string".intern`???
-????????????????????????????????????????????????`String#intern`????????????`rb_str_intern()`??????
+`ID` is shown as an instance of the `Symbol` class at the Ruby level.
+And it can be obtained like so: `"string".intern`. The implementation of
+`String#intern` is `rb_str_intern()`.
 
 ??? `rb_str_intern()`
 
@@ -615,16 +619,16 @@
 (string.c)
 

 
-???????????????`ruby`??????????????????????????????????????????????????????????????????????????????
-`RSTRING()`???????????????????????????????????????????????????????????????????????????????????????
-????????????????????????
+This function is quite reasonable as a `ruby` class library code example.
+Please pay attention to the part where `RSTRING()` is used and casted, and
+where the data structure's member is accessed.
 
-??????????????????????????????`rb_raise()`????????????????????????????????????????????????????????????
-????????????????????????`rb_intern()`????????????`ID2SYM()`????????????`ID2SYM()`???`ID`???
-`Symbol`????????????????????????????????????
+Let's read the code. First, `rb_raise()` is merely error handling so we ignore
+it for now. The `rb_intern()` we previously examined is here, and also ID2SYM
+is here. `ID2SYM()` is a macro that converts `ID` to `Symbol`. 
 
-???????????????????????????`Symbol#to_s`?????????????????????
-???????????????`sym_to_s`????????????
+And the reverse operation is accomplished by `Symbol#to_s` and such.
+The implementation is in `sym_to_s`.
 
 ??? `sym_to_s()`
 
@@ -638,10 +642,11 @@
 (object.c)
 

 
-`SYM2ID()`???`Symbol`(`VALUE`)???`ID`????????????????????????????????????
+`SYM2ID()` is the macro that converts `Symbol` (`VALUE`) to an `ID`.
 
-?????????????????????????????????????????????????????????????????????????????????????????????????????????
-`rb_id2name()`???`free()`?????????????????????`char*`????????????`rb_str_new2()`????????????
-`char*`????????????????????????(??????????????????????????????????????????)??????????????????
-???????????????????????????????????????????????????????????????????????????????????????
-
+It looks like the function is ((not doing anything unreasonable)). However, it
+is probably necessary to pay attention to the area around the memory handling.
+`rb_id2name()` returns a `char*` that must not be `free()`. `rb_str_new2()`
+copies the parameter's `char*` and uses ((the copy)) (and does not change the
+parameter). In this way the policy is consistent, which allows ((the line)) to be
+written just by chaining the functions.





From piyokun at gmail.com  Fri Mar 24 09:56:14 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Fri, 24 Mar 2006 23:56:14 +0900
Subject: [rhg-discussion] assignment grab: translation of Chapter 07,
	parts 1-5 of 9
Message-ID: <1f748ec60603240656k54e01317u1f72250b02f7654d@mail.gmail.com>

RHG-discussion:

Hi everybody, I'm going to start another chapter.
If nobody else minds, I'll start translating Chapter 07 "Security"
parts 1-5 (of 9).

I'm a security dilletante so this topic is interesting to me.
Unfortunately the treatment here is sparse because the author doesn't
trust Ruby's security (at Ruby 1.7.3). Well, it will be a short run to
translate this chapter.

Chapter 07: "Security"
part 1: General principle
part 2: General principle : Level 2
part 3: General principle : Level 4
part 4: General principle : Security Increment
part 5: General principle : $SAFE trustworthiness

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"


From piyokun at gmail.com  Fri Mar 24 10:13:50 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Sat, 25 Mar 2006 00:13:50 +0900
Subject: [rhg-discussion] Updating the main homepage?
Message-ID: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>

Vincent:

> This week-end I won't be able to check my mails, but I'll finish
> correcting chapter 4 and will begin working on chapter 9.

Just before you go, perhaps it would be good to publish on the main
homepage [1] the current chapters we have now (2, 3, and 4)?

It would be good advertising, maybe?

[1] http://rhg.rubyforge.org/

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"


From vincent.isambart at gmail.com  Fri Mar 24 10:33:21 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Fri, 24 Mar 2006 16:33:21 +0100
Subject: [rhg-discussion] Updating the main homepage?
In-Reply-To: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>
References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>
Message-ID: <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com>

> Just before you go, perhaps it would be good to publish on the main
> homepage [1] the current chapters we have now (2, 3, and 4)?
>
> It would be good advertising, maybe?
Well, I've already uploaded the chapters
(http://rhg.rubyforge.org/chapter0X.html) - I just have to launch the
upload.rb script to do it and I've done it at least once each day.
But I'm not sure about adding links to chapter 3 and 4 because they're
not really finished: there are still some rough sentences in chapter 4
(and Meinrad wants to different changes on its diagrams), and in
chapter 3 there is no diagram yet.
Not that I want the chapters to be perfect before release (well my
chapter 2 was full of typos and small mistakes), but I'd like at least
to have the rough sentences fixed and the diagrams added.

So I think we should wait next week to announce them... We'll also
probably be able to announce chapter 6 at the same time (and maybe
more) as it just needs 2 diagrams and a proofreading.

What do you think?


From piyokun at gmail.com  Fri Mar 24 10:48:57 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Sat, 25 Mar 2006 00:48:57 +0900
Subject: [rhg-discussion] Updating the main homepage?
In-Reply-To: <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com>
References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>
	<7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com>
Message-ID: <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com>

> So I think we should wait next week to announce them... We'll also
> probably be able to announce chapter 6 at the same time (and maybe
> more) as it just needs 2 diagrams and a proofreading.

I can understand your point of view, but showing some sort of progress
by the weekend when most people are probably free may encourage more
people to join. I suppose it's quiet during the weekdays because of
work.

About the rough edges, I myself am dying to get feedback and
criticisms about the chapter 3.

Anyways you did the job of translating, let others do the job of proofreading.

But if you decide to wait till next week, that's fine too.

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"


From vincent.isambart at gmail.com  Fri Mar 24 10:48:58 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Fri, 24 Mar 2006 16:48:58 +0100
Subject: [rhg-discussion] [translation, patch] Chapter 03 - Part 8, 9,
	10 of 10
In-Reply-To: <1f748ec60603240641h3e1a2b0dm6d3f385628ea906e@mail.gmail.com>
References: <1f748ec60603240641h3e1a2b0dm6d3f385628ea906e@mail.gmail.com>
Message-ID: <7d9a1f530603240748x24f7d755i52576905ea5bf81d@mail.gmail.com>

I have not time to check it today, but I just have a remark.

> -????????????????????????????????
> -??????????????????????????????
> -?????`ID`????
> -?????????????????`ID`?????????????????
> -?????????????
> +What is the omitted section doing? It is treating global variable names and
> +instance variables names as special and flagging ((attributing?)) them. This is

I'd go for "flagging". I copied below rb_intern's source code (taken
from the latest ruby CVS). Search for example for "id |= ID_CLASS;".
I've clarified more than once some points I had troubles to understand
by looking directly at ruby's source code.

ID
rb_intern(const char *name)
{
    const char *m = name;
    ID id;
    int last;

    if (st_lookup(global_symbols.tbl, (st_data_t)name, (st_data_t *)&id))
	return id;

    last = strlen(name)-1;
    id = 0;
    switch (*name) {
      case '$':
	id |= ID_GLOBAL;
	if (is_special_global_name(++m)) goto new_id;
	break;
      case '@':
	if (name[1] == '@') {
	    m++;
	    id |= ID_CLASS;
	}
	else {
	    id |= ID_INSTANCE;
	}
	m++;
	break;
      default:
	if (name[0] != '_' && ISASCII(name[0]) && !ISALNUM(name[0])) {
	    /* operators */
	    int i;

	    for (i=0; op_tbl[i].token; i++) {
		if (*op_tbl[i].name == *name &&
		    strcmp(op_tbl[i].name, name) == 0) {
		    id = op_tbl[i].token;
		    goto id_regist;
		}
	    }
	}

	if (name[last] == '=') {
	    /* attribute assignment */
	    char *buf = ALLOCA_N(char,last+1);

	    strncpy(buf, name, last);
	    buf[last] = '\0';
	    id = rb_intern(buf);
	    if (id > tLAST_TOKEN && !is_attrset_id(id)) {
		id = rb_id_attrset(id);
		goto id_regist;
	    }
	    id = ID_ATTRSET;
	}
	else if (ISUPPER(name[0])) {
	    id = ID_CONST;
	}
	else {
	    id = ID_LOCAL;
	}
	break;
    }
    if (!ISDIGIT(*m)) {
	while (m <= name + last && is_identchar(*m)) {
	    m += mbclen(*m);
	}
    }
    if (*m) id = ID_JUNK;
  new_id:
    id |= ++global_symbols.last_id << ID_SCOPE_SHIFT;
  id_regist:
    name = strdup(name);
    st_add_direct(global_symbols.tbl, (st_data_t)name, id);
    st_add_direct(global_symbols.rev, id, (st_data_t)name);
    return id;
}

Cheers

From vincent.isambart at gmail.com  Fri Mar 24 10:57:35 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Fri, 24 Mar 2006 16:57:35 +0100
Subject: [rhg-discussion] Updating the main homepage?
In-Reply-To: <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com>
References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>
	<7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com>
	<1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com>
Message-ID: <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com>

> > So I think we should wait next week to announce them... We'll also
> > probably be able to announce chapter 6 at the same time (and maybe
> > more) as it just needs 2 diagrams and a proofreading.
>
> I can understand your point of view, but showing some sort of progress
> by the weekend when most people are probably free may encourage more
> people to join. I suppose it's quiet during the weekdays because of
> work.
That's what I thought at first but I'm not so sure. If you look at the
mailing list, I did not have anyone joining before at least Sunday.
But it was maybe because I did not make it clear at first that anyone
wanting to join the project should join the ML (it was on the web
page, not on the announcement mail) and because Daigo had not
announced it on RedHanded. However, there are not much going the
week-end on the Web.

> About the rough edges, I myself am dying to get feedback and
> criticisms about the chapter 3.
Well, after all it's your chapter ;), so I think I'm gonna do the following:
- update the index and put a big ALPHA near chapter 3 and 4
- but do not announce it officially (keep the announcements for
chapters in a better shape)
How's that?


From meinrad.recheis at gmail.com  Fri Mar 24 11:19:26 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Fri, 24 Mar 2006 17:19:26 +0100
Subject: [rhg-discussion] News
In-Reply-To: <43d756720603231756v6b37ca56v9c7b19f2af6437a5@mail.gmail.com>
References: <7d9a1f530603230053l3cb57fd5nd39b3198e1d60d65@mail.gmail.com>
	<43d756720603230202q7dfbdd85p8e4b81bc581067e0@mail.gmail.com>
	<8E56F420-0630-477E-845A-291124BA0412@rjimlad.org>
	<43d756720603231756v6b37ca56v9c7b19f2af6437a5@mail.gmail.com>
Message-ID: <43d756720603240819p50fda259na09001740b893bf7@mail.gmail.com>

On 3/24/06, Meinrad Recheis  wrote:
[...]
> thanks Jim! going to change that tomorrow *yawn* ;)

and so it happened:
the English of the chapter4 figures is corrected and the style of
singleton classes has been simplified.

the much discussed figure 2 has been reset to it's original
representation because i think (despite the enhancments) it didn't fit
to the rest of the figures. i consider my part of chapter4 finished
and will move on to the figures of chapter3.

the inkscape-svgz files have been changed to inkscape-svg files.
that's it for revision 24.

best wishes,
-- henon


From meinrad.recheis at gmail.com  Fri Mar 24 11:22:21 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Fri, 24 Mar 2006 17:22:21 +0100
Subject: [rhg-discussion] Chapter 6
In-Reply-To: <7d9a1f530603240249g6af5dfd9oc7fe913e48273fe4@mail.gmail.com>
References: <7d9a1f530603240249g6af5dfd9oc7fe913e48273fe4@mail.gmail.com>
Message-ID: <43d756720603240822j59e952a1r51a6a72f7cd2fe39@mail.gmail.com>

On 3/24/06, Vincent Isambart  wrote:
> Hi everyone,
>
> Chapter 6 is now in the repository, open for review :).
> I also changed most of the "diagram" to "figure".
> Here is the translation of the figures:
> - figure 1: no Japanese text
> - figure 2:
>   * ?????? = variable is undefined
>   * ????? = variable is defined
>   * ????? = a warning appears
>   * ?????????????? = can be read like a normal variable
>   * ?????????????? (this line is twice in the diagram) = can be
> written like a normal variable
>   * undef_setter????????? = transition to the state below done by undef_setter
>
> A little note for the Ruby scripts: I'd prefer if the indentation used
> was always two spaces, no tabs (yes that's for you, Meinrad ;)).
ok.
hehe, i won't start a fight about intendation of a makefile ^^.
(although i think tab is the best intendation character)
>
> This week-end I won't be able to check my mails, but I'll finish
> correcting chapter 4 and will begin working on chapter 9.
>
> Cheers,
> Vincent
> _______________________________________________
> rhg-discussion mailing list
> rhg-discussion at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rhg-discussion
>

From vincent.isambart at gmail.com  Fri Mar 24 11:36:14 2006
From: vincent.isambart at gmail.com (Vincent Isambart)
Date: Fri, 24 Mar 2006 17:36:14 +0100
Subject: [rhg-discussion] Updating the main homepage?
In-Reply-To: <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com>
References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com>
	<7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com>
	<1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com>
	<7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com>
Message-ID: <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com>

> > About the rough edges, I myself am dying to get feedback and
> > criticisms about the chapter 3.
> Well, after all it's your chapter ;), so I think I'm gonna do the following:
> - update the index and put a big ALPHA near chapter 3 and 4
> - but do not announce it officially (keep the announcements for
> chapters in a better shape)
> How's that?

Well, I just added a missing backquote to chapter 3, modified the
index with links to the new chapters (and a big PREVIEW next to the
chapters) and uploaded everything, without forgetting Meinrad's last
diagrams.

Cheers,
Vincent


From j at rjimlad.org  Fri Mar 24 13:15:34 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Fri, 24 Mar 2006 18:15:34 +0000
Subject: [rhg-discussion] assignment grab: translation of Chapter 07,
	parts 1-5 of 9
In-Reply-To: <1f748ec60603240656k54e01317u1f72250b02f7654d@mail.gmail.com>
References: <1f748ec60603240656k54e01317u1f72250b02f7654d@mail.gmail.com>
Message-ID: <8A7661EA-F1C3-43D0-8A1B-86C34097D650@rjimlad.org>

Hi Clifford,

On 24 Mar 2006, at 14:56, Clifford Caoile wrote:

> I'm a security dilettante so this topic is interesting to me.
> Unfortunately the treatment here is sparse because the author doesn't
> trust Ruby's security (at Ruby 1.7.3). Well, it will be a short run to
> translate this chapter.

Excellent, me too. I'll be interested to see how the translation looks.

Jim

From j at rjimlad.org  Fri Mar 24 14:26:59 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Fri, 24 Mar 2006 19:26:59 +0000
Subject: [rhg-discussion] Chapter 3 tweaks
Message-ID: 

Hi all,

More minor tweaks from me, with some notes regarding parts that I  
didn't try to correct:

I don't know what this means:

"Only the parts where the
implementation changes with a differing data type will bundled up into a
function, and a pointer to that function will be used."

I think it's saying that only the parts of the hash system which need  
to be changed, are changed. Or something. As for the untranslated bit  
immediately after, I think (just from the context, bear in mind that  
I speak no Japanese) it's saying that the majority of the code can be  
shared (ie: Don't Repeat Yourself) between hash functions for  
different data types.

I think this block...

"In object-oriented languages, in the first place, you can attach a  
procedure
to an object and pass it (around), so this mechanism is not necessary."

...is trying to say:

"In object-oriented languages, you can define a method on an object,  
and pass
that method, so this mechanism is not necessary."

...which is to say that you could (and I suspect maybe do in Ruby  
nowadays) provide some kind of to_hash_value() and compare() methods  
on the object itself.

I've also not tried to deal with more than one of the blocks of  
double-brackets [(( ))], which I assume are unconcluded translations?

Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chapter-3-en-cleanup.patch
Type: application/octet-stream
Size: 12611 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060324/b95353ef/attachment-0001.obj 

From meinrad.recheis at gmail.com  Fri Mar 24 15:35:56 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Fri, 24 Mar 2006 21:35:56 +0100
Subject: [rhg-discussion] visual language chart
Message-ID: <43d756720603241235p1f4510aarb5be29c6d2a60545@mail.gmail.com>

hi group,
as requested, i put together an explanation of the shapes and
color-styles i developed. shape, structure and color of an object
carry semantic information.
there is always room for improvement ... so you are welcome to comment it.

it can be found at ./en/images/visual_language.png.

take care,
-- henon


From j at rjimlad.org  Sun Mar 26 03:40:13 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Sun, 26 Mar 2006 09:40:13 +0100
Subject: [rhg-discussion] Rakefile tweak (inkscape path)
Message-ID: <55D48E2A-043D-4F30-B5F7-D278F405332A@rjimlad.org>

Hi all,

For humble Mac users (and, I suppose, Windows users, but that  
introduces a whole slew of other problems), Inkscape may well be  
installed, but it's not going to be in the PATH. There are two ways  
to handle this: stick its location into ENV["PATH"], or allow the  
script to be explicitly informed of the path to this particular  
binary. This is a patch to do the latter, using an environment  
variable called INKSCAPE_PATH. Thanks to the magic of rake, this can  
also be supplied along with the args, like:

rake INKSCAPE_PATH=/Applications/Graphics/Inkscape.app/Contents/ 
Resources/bin

Anyway, it's convenient for me (and does seem to work)

Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhg-rakefile-inkscape-path.patch
Type: application/octet-stream
Size: 521 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060326/d08d78c1/attachment.obj 

From j at rjimlad.org  Sun Mar 26 04:19:35 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Sun, 26 Mar 2006 10:19:35 +0100
Subject: [rhg-discussion] Chapter 6 tweaks
Message-ID: <8DAA5F38-FA99-47B0-9364-F499D2CAFE8F@rjimlad.org>

Hi all,

Looks like Vincent got tired part way through this, as the earlier  
sections are much more fluent than the later ones!

I mostly understood this all fine, with a few exceptions that I'll  
have to come back to at some point. But then all the chapters will  
need more proof-reading passes anyway :)

Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhg-chapter06-tweaks.patch
Type: application/octet-stream
Size: 15400 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060326/02401262/attachment.obj 

From meinrad.recheis at gmail.com  Sun Mar 26 05:29:15 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Sun, 26 Mar 2006 11:29:15 +0100
Subject: [rhg-discussion] Rakefile tweak (inkscape path)
In-Reply-To: <55D48E2A-043D-4F30-B5F7-D278F405332A@rjimlad.org>
References: <55D48E2A-043D-4F30-B5F7-D278F405332A@rjimlad.org>
Message-ID: <43d756720603260229q4078aa60k2deb605f4e8beb38@mail.gmail.com>

committed.
-- henon

On 3/26/06, Jim Driscoll  wrote:
> Hi all,
>
> For humble Mac users (and, I suppose, Windows users, but that
> introduces a whole slew of other problems), Inkscape may well be
> installed, but it's not going to be in the PATH. There are two ways
> to handle this: stick its location into ENV["PATH"], or allow the
> script to be explicitly informed of the path to this particular
> binary. This is a patch to do the latter, using an environment
> variable called INKSCAPE_PATH. Thanks to the magic of rake, this can
> also be supplied along with the args, like:
>
> rake INKSCAPE_PATH=/Applications/Graphics/Inkscape.app/Contents/
> Resources/bin
>
> Anyway, it's convenient for me (and does seem to work)
>
> Jim
>
>
>
> _______________________________________________
> rhg-discussion mailing list
> rhg-discussion at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rhg-discussion
>
>
>


From piyokun at gmail.com  Sun Mar 26 06:48:28 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Sun, 26 Mar 2006 20:48:28 +0900
Subject: [rhg-discussion] Chapter 3 tweaks
In-Reply-To: 
References: 
Message-ID: <1f748ec60603260348i693ca335h5a0443639caf768e@mail.gmail.com>

Jim:

Jim Driscoll said:
> More minor tweaks from me,

Thanks for the patch. I used all but three of the corrections. I "svn
commit"-ted it as -r 30. Here are my reasons why:

---- BEGIN PATCH chapter03-jimdriscollcomment-unused.txt
Index: chapter03.txt
===================================================================
--- chapter03.txt	(revision 30)
+++ chapter03.txt	(working copy)
@@ -27,7 +27,7 @@

 However, this method is slow. If the list contains a thousand items, in the
 worst case, it is necessary to traverse links a thousand times. In other
-words, in proportion to the number of elements, the search time increases.
+words, the search time is proportional to the number of events.
 This is bad. Since ancient times, various speed improvement methods have
 been conceived. The hash table is one of those improved methods. In other
 words, the point is not that the hash table is necessary but that it can be

The original japanese text is emphasizing that the search time can grow worse,
not that it can change.

@@ -84,9 +84,9 @@

 !images/ch_name_nexti.jpg(Open addressing)!

-Other than using the array like this, there are other possible
approaches, like using
-a pointer to a respective linked list in each element of the array. Then when a
-collision occurs, grow the linked list. This is called chaining. (Figure
+Other than using the array like this, there are other possible
apporaches, like using
+pointers (in each element of the array) to a linked list. Then when a
+collision occurs, you append to the linked list. This is called
chaining. (Figure
 4) `st_table` uses this chaining method.

 !images/ch_name_chain.jpg(Chaining)!

I changed it one more time to read like this:

Other than using the array like this, there are other possible
approaches, like using
a pointer to a respective linked list in each each element of the
array. Then when a
collision occurs, grow the linked list. This is called chaining. (Figure
...

because the pointer part was not clear enough. Also, there are many ways to use
a linked list, but saying "append" here is not correct, since it implies doing
the operation at the end of the linked list. The implementation seems to be
inserting at the front of the list.

@@ -450,7 +450,7 @@
 (st.c)
 


-`DENSITY` is "concentration". In other words, this conditional checks if the
+`DENSITY` is "concentration". In other words, this condition checks if the
 hash table is "crowded" or not. In the `st_table`, as the number of values that
 use the same `bin_pos` increases, the longer the link list becomes. In other
 words, search becomes slower. That is why for a given `bin` count,
when the average elements

A "conditional" is a programming language statement, whereas a
"condition" refers
to a state.
---- END PATCH

> ... with some notes regarding parts that I
> didn't try to correct:
>
> I don't know what this means:
>
> "Only the parts where the
> implementation changes with a differing data type will bundled up into a
> function, and a pointer to that function will be used."
>
> I think it's saying that only the parts of the hash system which need
> to be changed, are changed. Or something.

I think Aoki is saying not just changing the parts, but making it
data-variant code as modular. That's why he uses "bundled" in the
Japanese.

> As for the untranslated bit
> immediately after, I think (just from the context, bear in mind that
> I speak no Japanese) it's saying that the majority of the code can be
> shared (ie: Don't Repeat Yourself) between hash functions for
> different data types.

This is correct. Sorry for that translation. That japanese word is
"shared". I will correct in a future revision.

Then again, who is using who? I think it's the hash algorithm
substituting the data-variant code, not the data-variant code using
the hash algorithm.

> I think this block...
>
> "In object-oriented languages, in the first place, you can attach a
> procedure
> to an object and pass it (around), so this mechanism is not necessary."
>
> ...is trying to say:
>
> "In object-oriented languages, you can define a method on an object,
> and pass
> that method, so this mechanism is not necessary."

The point in this part is that the object is passed around, not just
the procedure. Notice that the `hash` is bundled with the `compare`
and given over as one object.

> ...which is to say that you could (and I suspect maybe do in Ruby
> nowadays) provide some kind of to_hash_value() and compare() methods
> on the object itself.
>
> I've also not tried to deal with more than one of the blocks of
> double-brackets [(( ))], which I assume are unconcluded translations?

Yeah, I was hoping that some other Japanese readers would pick up on
this and correct my interpretation. But a weekend helps to change
perspective, and I think I will go with my best shot, which means some
of those (()) are going to go away.

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"
-------------- next part --------------
Index: chapter03.txt
===================================================================
--- chapter03.txt	(revision 30)
+++ chapter03.txt	(working copy)
@@ -27,7 +27,7 @@
 
 However, this method is slow. If the list contains a thousand items, in the
 worst case, it is necessary to traverse links a thousand times. In other
-words, in proportion to the number of elements, the search time increases.
+words, the search time is proportional to the number of events.
 This is bad. Since ancient times, various speed improvement methods have
 been conceived. The hash table is one of those improved methods. In other
 words, the point is not that the hash table is necessary but that it can be

The original japanese text is emphasizing that the search time can grow worse,
not that it can change.

@@ -84,9 +84,9 @@
 
 !images/ch_name_nexti.jpg(Open addressing)!
 
-Other than using the array like this, there are other possible approaches, like using
-a pointer to a respective linked list in each element of the array. Then when a
-collision occurs, grow the linked list. This is called chaining. (Figure
+Other than using the array like this, there are other possible apporaches, like using
+pointers (in each element of the array) to a linked list. Then when a
+collision occurs, you append to the linked list. This is called chaining. (Figure
 4) `st_table` uses this chaining method.
 
 !images/ch_name_chain.jpg(Chaining)!

I changed it one more time to read like this:

Other than using the array like this, there are other possible approaches, like using
a pointer to a respective linked list in each each element of the array. Then when a
collision occurs, grow the linked list. This is called chaining. (Figure
...

because the pointer part was not clear enough. Also, there are many ways to use
a linked list, but saying "append" here is not correct, since it implies doing
the operation at the end of the linked list. The implementation seems to be
inserting at the front of the list.

@@ -450,7 +450,7 @@
 (st.c)
 

 
-`DENSITY` is "concentration". In other words, this conditional checks if the
+`DENSITY` is "concentration". In other words, this condition checks if the
 hash table is "crowded" or not. In the `st_table`, as the number of values that
 use the same `bin_pos` increases, the longer the link list becomes. In other
 words, search becomes slower. That is why for a given `bin` count, when the average elements

A "conditional" is a programming language statement, whereas a "condition" refers
to a state.


From piyokun at gmail.com  Sun Mar 26 06:49:55 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Sun, 26 Mar 2006 20:49:55 +0900
Subject: [rhg-discussion] visual language chart
In-Reply-To: <43d756720603241235p1f4510aarb5be29c6d2a60545@mail.gmail.com>
References: <43d756720603241235p1f4510aarb5be29c6d2a60545@mail.gmail.com>
Message-ID: <1f748ec60603260349o43c71614ia6780e643a9be1c4@mail.gmail.com>

Thanks for the clarification.

> it can be found at ./en/images/visual_language.png.

For those who just can't wait to see it:

http://rubyforge.org/plugins/scmsvn/viewcvs.php/en/images/visual_language.png?root=rhg&rev=30&view=markup

--
Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"


From piyokun at gmail.com  Sun Mar 26 07:00:27 2006
From: piyokun at gmail.com (Clifford Caoile)
Date: Sun, 26 Mar 2006 21:00:27 +0900
Subject: [rhg-discussion] visual language chart
In-Reply-To: <1f748ec60603260349o43c71614ia6780e643a9be1c4@mail.gmail.com>
References: <43d756720603241235p1f4510aarb5be29c6d2a60545@mail.gmail.com>
	<1f748ec60603260349o43c71614ia6780e643a9be1c4@mail.gmail.com>
Message-ID: <1f748ec60603260400t7dd60944i6c05ed22a23c3297@mail.gmail.com>

My comments:

The colors don't seem to be consistent. Is it C code vs Ruby code?

You have the iclass (C) and the singleton class (C) as gray, but the
next C struct (C) example is blue. Is the C gray and the ruby blue?

(Hey, why blue? It's gotta be ruby colored! just kidding)

Maybe you could use different shapes just in case the color-deficient
cannot pick up the difference?

Also with the arrows, perhaps an english word above the arrow for some
tricky relations would help. I think it would be good for 20% that are
hard to understand, like the scope discussions?

Best regards,
Clifford Caoile
--
irb(main):001:0> my.greeting( :"rhg-discussion" )
=> "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html"


From meinrad.recheis at gmail.com  Sun Mar 26 09:23:51 2006
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Sun, 26 Mar 2006 15:23:51 +0100
Subject: [rhg-discussion] visual language chart
In-Reply-To: <1f748ec60603260400t7dd60944i6c05ed22a23c3297@mail.gmail.com>
References: <43d756720603241235p1f4510aarb5be29c6d2a60545@mail.gmail.com>
	<1f748ec60603260349o43c71614ia6780e643a9be1c4@mail.gmail.com>
	<1f748ec60603260400t7dd60944i6c05ed22a23c3297@mail.gmail.com>
Message-ID: <43d756720603260623v427ba622i4ece65716cbd73fe@mail.gmail.com>

On 3/26/06, Clifford Caoile  wrote:
> My comments:
>
> The colors don't seem to be consistent. Is it C code vs Ruby code?
i assumed that that is obvious from the context and not so important.
maybe i am wrong.
>
> You have the iclass (C) and the singleton class (C) as gray, but the
> next C struct (C) example is blue. Is the C gray and the ruby blue?

by now the color does not distinguish between C and Ruby.
i only wanted to distinguish objects that are visible at the ruby
level from hidden implementation objects. color also distinguishes
between objects and classes.

currently i focused more on:
* is it an object or a class
* is it hidden on the ruby level
* is it a hash table or a struct
* arrows: inheritance vs reference
maybe there are other important aspects to emphasize?
if you think it's important to also emphasize the Language (C vs Ruby)
i'll try to come up with an encoding (shape/color whatever).

>
> (Hey, why blue? It's gotta be ruby colored! just kidding)
mainly because i like blue very much ;)
>
> Maybe you could use different shapes just in case the color-deficient
> cannot pick up the difference?

blue blindness is *extremely* rare. red-green blindness is distributed
over about 10% of male persons. if they were red or green this would
be a good reason ;).
>
> Also with the arrows, perhaps an english word above the arrow for some
> tricky relations would help. I think it would be good for 20% that are
> hard to understand, like the scope discussions?

text above an arrow could be a problem because it maybe would be too
small. i must try it out. alternative would be other arrow styles and
a caption somewhere aside the figure explaining the different arrow
styles.
which figures do you mean?

-- henon


From j at rjimlad.org  Sun Mar 26 10:39:10 2006
From: j at rjimlad.org (Jim Driscoll)
Date: Sun, 26 Mar 2006 16:39:10 +0100
Subject: [rhg-discussion] Chapter 3 tweaks
In-Reply-To: <1f748ec60603260348i693ca335h5a0443639caf768e@mail.gmail.com>
References: 
	<1f748ec60603260348i693ca335h5a0443639caf768e@mail.gmail.com>
Message-ID: <2775C398-6EFC-417B-B2A5-8110F469DADF@rjimlad.org>

Hi Clifford,

On 26 Mar 2006, at 12:48, Clifford Caoile wrote:

> Jim:
>
> Jim Driscoll said:
>> More minor tweaks from me,
>
> Thanks for the patch. I used all but three of the corrections. I "svn
> commit"-ted it as -r 30. Here are my reasons why:

Yup, that's fine. They are just suggestions, and I'm quite open to  
counter-suggestions.

>
>  However, this method is slow. If the list contains a thousand  
> items, in the
>  worst case, it is necessary to traverse links a thousand times. In  
> other
> -words, in proportion to the number of elements, the search time  
> increases.
> +words, the search time is proportional to the number of events.
>  This is bad. Since ancient times, various speed improvement  
> methods have
>  been conceived. The hash table is one of those improved methods.  
> In other
>  words, the point is not that the hash table is necessary but that  
> it can be
>
> The original japanese text is emphasizing that the search time can  
> grow worse,
> not that it can change.

Yes, that's the same thing. Greater number of elements, greater  
search time. Smaller number of elements, smaller search time. That's  
what proportional means; the word "increases" is effectively  
redundant. If you want to keep it, the sentence should be re-ordered  
because that particular form "in proportion... (something)" would  
seem to suggest two values on the same scale which are  
disproportionate. In other words: "the search time increases in  
proportion to the number of events".

>
> @@ -84,9 +84,9 @@
>
>  !images/ch_name_nexti.jpg(Open addressing)!
>
> -Other than using the array like this, there are other possible
> approaches, like using
> -a pointer to a respective linked list in each element of the  
> array. Then when a
> -collision occurs, grow the linked list. This is called chaining.  
> (Figure
> +Other than using the array like this, there are other possible
> apporaches, like using
> +pointers (in each element of the array) to a linked list. Then when a
> +collision occurs, you append to the linked list. This is called
> chaining. (Figure
>  4) `st_table` uses this chaining method.
>
>  !images/ch_name_chain.jpg(Chaining)!
>
> I changed it one more time to read like this:
>
> Other than using the array like this, there are other possible
> approaches, like using
> a pointer to a respective linked list in each each element of the
> array. Then when a
> collision occurs, grow the linked list. This is called chaining.  
> (Figure
> ...
>
> because the pointer part was not clear enough. Also, there are many  
> ways to use
> a linked list, but saying "append" here is not correct, since it  
> implies doing
> the operation at the end of the linked list. The implementation  
> seems to be
> inserting at the front of the list.

True (as I discovered reading further on). I'm used to having linked  
lists where the first item matters! However, I'd use the word  
"corresponding" rather than "respective" there. The former implies a  
relationship between a single item (the single pointer referred to)  
and something else,  whereas the latter would be for multiple items  
to multiple other things. "respectively" means, effectively, "with  
respect to each item", so it only really makes sense in a plural  
context.

>
> @@ -450,7 +450,7 @@
>  (st.c)
>
> > -`DENSITY` is "concentration". In other words, this conditional > checks if the > +`DENSITY` is "concentration". In other words, this condition > checks if the > hash table is "crowded" or not. In the `st_table`, as the number > of values that > use the same `bin_pos` increases, the longer the link list > becomes. In other > words, search becomes slower. That is why for a given `bin` count, > when the average elements > > A "conditional" is a programming language statement, whereas a > "condition" refers > to a state. That's an "expression". Sadly, I have seen "conditional" used as a noun before, in the way you suggest, but it is in fact an adjective. I suppose people use it as an abbreviation of "conditional expression". There is precedent for doing this: "variable" is, of course, also an adjective rather than a noun, but I don't believe it's broadly accepted (in the programming community) that "conditional" is a valid noun. > ---- END PATCH > > I think Aoki is saying not just changing the parts, but making it > data-variant code as modular. That's why he uses "bundled" in the > Japanese. Pardon? >> I think this block... >> >> "In object-oriented languages, in the first place, you can attach a >> procedure >> to an object and pass it (around), so this mechanism is not >> necessary." >> >> ...is trying to say: >> >> "In object-oriented languages, you can define a method on an object, >> and pass >> that method, so this mechanism is not necessary." > > The point in this part is that the object is passed around, not just > the procedure. Notice that the `hash` is bundled with the `compare` > and given over as one object. Yup, I was thinking too "C++" there, I believe (behind the scenes, you're always using a function with the object as the first argument). Nonetheless, the hash function does have access to the object anyway - the difference is that the object is providing its own method rather than relying on a built-in one. Jim From j at rjimlad.org Sun Mar 26 10:46:59 2006 From: j at rjimlad.org (Jim Driscoll) Date: Sun, 26 Mar 2006 16:46:59 +0100 Subject: [rhg-discussion] Chapter 3 tweaks In-Reply-To: <2775C398-6EFC-417B-B2A5-8110F469DADF@rjimlad.org> References: <1f748ec60603260348i693ca335h5a0443639caf768e@mail.gmail.com> <2775C398-6EFC-417B-B2A5-8110F469DADF@rjimlad.org> Message-ID: (Just adding something I forgot below) On 26 Mar 2006, at 16:39, Jim Driscoll wrote: > Yes, that's the same thing. Greater number of elements, greater > search time. Smaller number of elements, smaller search time. That's > what proportional means; the word "increases" is effectively > redundant. If you want to keep it, the sentence should be re-ordered > because that particular form "in proportion... (something)" would > seem to suggest two values on the same scale which are > disproportionate. In other words: "the search time increases in > proportion to the number of events". > For that last sentence, I meant that as a suggested rewording for keeping "increases" in, not as an indication of two values (nominally) on the same scale which are disproportionate. Of the latter I can't think of a real-world example. Just to clarify, "proportional" does describe the specific type of relationship between two values. You'd have to say "inversely proportional" to indicate that an increase in one implies a decrease in the other (which I suppose would make it O(1/N) or something, depending on the context). Jim From meinrad.recheis at gmail.com Sun Mar 26 13:32:55 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Sun, 26 Mar 2006 19:32:55 +0100 Subject: [rhg-discussion] Chapter 3 tweaks In-Reply-To: References: Message-ID: <43d756720603261032r5920895fn7475dba74a11452a@mail.gmail.com> i am reading chapter 3 and drawing figures. how about making identifiers such as "i" and "f" italic for better readability? -- henon From vincent.isambart at gmail.com Mon Mar 27 03:01:04 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 27 Mar 2006 10:01:04 +0200 Subject: [rhg-discussion] Chapter 6 tweaks In-Reply-To: <8DAA5F38-FA99-47B0-9364-F499D2CAFE8F@rjimlad.org> References: <8DAA5F38-FA99-47B0-9364-F499D2CAFE8F@rjimlad.org> Message-ID: <7d9a1f530603270001v2d65102axc7e78c4543c44046@mail.gmail.com> Hi, > Looks like Vincent got tired part way through this, as the earlier > sections are much more fluent than the later ones! I did not think it was so easy to see ;). I just spent more time one the first half :P. Thanks for the corrections :). I applied everything except this one: will return different `ID`s for "`@var`" and "`@@var`". At the Ruby level, the variable type is determined only by the prefix so there's -no way to access a class variable called `@var` from Ruby. +no way to have a class variable called `@var` from Ruby. I changed it to "no way to have access to a class variable called `@var` from Ruby." What do you think? And it also looks like I'll have to study a little more "this"/"that", as you corrected them most of the time ;). > I mostly understood this all fine, with a few exceptions that I'll > have to come back to at some point. When you want. But by waiting too much, you risk forgetting it ;). > But then all the chapters will > need more proof-reading passes anyway :) They sure do :). PS: I also uploaded the last version of the chapters on the web page. Cheers, Vincent From vincent.isambart at gmail.com Mon Mar 27 05:41:59 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 27 Mar 2006 12:41:59 +0200 Subject: [rhg-discussion] Updating the main homepage? In-Reply-To: <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com> References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com> <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com> <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com> <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com> <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com> Message-ID: <7d9a1f530603270241s8162b07xdf93e1c90d0e570a@mail.gmail.com> Hi, Could someone check the new index page? It's better not to have too many mistakes on the page introducing the project ;). Cheers, Vincent From vincent.isambart at gmail.com Mon Mar 27 07:29:46 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Mon, 27 Mar 2006 14:29:46 +0200 Subject: [rhg-discussion] Chapter 4 Message-ID: <7d9a1f530603270429k1fb1a580hd84817030d59bd5c@mail.gmail.com> Hi, I've done some tweaking of the first half of chapter 4 (it's done up to the summary just above the metaclass part). Do not hesitate to make comments :). Cheers, Vincent From j at rjimlad.org Mon Mar 27 12:08:46 2006 From: j at rjimlad.org (Jim Driscoll) Date: Mon, 27 Mar 2006 18:08:46 +0100 Subject: [rhg-discussion] Chapter 6 tweaks In-Reply-To: <7d9a1f530603270001v2d65102axc7e78c4543c44046@mail.gmail.com> References: <8DAA5F38-FA99-47B0-9364-F499D2CAFE8F@rjimlad.org> <7d9a1f530603270001v2d65102axc7e78c4543c44046@mail.gmail.com> Message-ID: <3FE3BCEF-92A0-489F-A28D-49AD4BA3295F@rjimlad.org> Hi Vincent, On 27 Mar 2006, at 09:01, Vincent Isambart wrote: > Thanks for the corrections :). I applied everything except this one: > > will return different `ID`s for "`@var`" and "`@@var`". At the Ruby > level, the variable type is determined only by the prefix so there's > -no way to access a class variable called `@var` from Ruby. > +no way to have a class variable called `@var` from Ruby. > > I changed it to "no way to have access to a class variable called > `@var` from Ruby." What do you think? > Hmmm... well, it doesn't matter, really, as it's the same thing. Both reading and writing to such a (theoretical) class variable are should- never-happen scenarios. If you want to indicate that read access is impossible, the original text ("no way to access") is best. > And it also looks like I'll have to study a little more "this"/"that", > as you corrected them most of the time ;). "This" always refers to the current context (usually the most recently used noun); "that" always refers to something else. I'm afraid I can't think of any easy way to remember that, though :) Jim From j at rjimlad.org Mon Mar 27 12:20:01 2006 From: j at rjimlad.org (Jim Driscoll) Date: Mon, 27 Mar 2006 18:20:01 +0100 Subject: [rhg-discussion] Updating the main homepage? In-Reply-To: <7d9a1f530603270241s8162b07xdf93e1c90d0e570a@mail.gmail.com> References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com> <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com> <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com> <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com> <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com> <7d9a1f530603270241s8162b07xdf93e1c90d0e570a@mail.gmail.com> Message-ID: <7C8934BF-7D5D-4FC2-8030-7E06A4C88BA8@rjimlad.org> Hi Vincent, On 27 Mar 2006, at 11:41, Vincent Isambart wrote: > Could someone check the new index page? It's better not to have too > many mistakes on the page introducing the project ;). I actually avoided doing that before, because I thought that'd be a bit intrusive or picky (or even arrogant) of me to do! Patch attached. You'll definitely want to look through it, though, because some of them may not be the best tweaks. Jim From j at rjimlad.org Mon Mar 27 12:21:38 2006 From: j at rjimlad.org (Jim Driscoll) Date: Mon, 27 Mar 2006 18:21:38 +0100 Subject: [rhg-discussion] Updating the main homepage? In-Reply-To: <7C8934BF-7D5D-4FC2-8030-7E06A4C88BA8@rjimlad.org> References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com> <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com> <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com> <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com> <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com> <7d9a1f530603270241s8162b07xdf93e1c90d0e570a@mail.gmail.com> <7C8934BF-7D5D-4FC2-8030-7E06A4C88BA8@rjimlad.org> Message-ID: I hate it when I do this... On 27 Mar 2006, at 18:20, Jim Driscoll wrote: > Patch attached. You'll definitely want to look through it, though, > because some of them may not be the best tweaks. > Patch attached *now*. Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: rhg-index-tweaks.patch Type: application/octet-stream Size: 3937 bytes Desc: not available Url : http://rubyforge.org/pipermail/rhg-discussion/attachments/20060327/6687dcd8/attachment.obj From meinrad.recheis at gmail.com Mon Mar 27 19:35:12 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Tue, 28 Mar 2006 02:35:12 +0200 Subject: [rhg-discussion] figures for chapter03 completed Message-ID: <43d756720603271635la3215a2y26140854be53f9d3@mail.gmail.com> hi group, figures for chapter03 have been completed and checked in as r37. please check the English. any comments? best wishes, -- henon From vincent.isambart at gmail.com Tue Mar 28 02:02:37 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Tue, 28 Mar 2006 09:02:37 +0200 Subject: [rhg-discussion] Updating the main homepage? In-Reply-To: <7C8934BF-7D5D-4FC2-8030-7E06A4C88BA8@rjimlad.org> References: <1f748ec60603240713x474d2598r278ecc1e6d69a1d4@mail.gmail.com> <7d9a1f530603240733o40c47ca5w5f10d29fe753fcfe@mail.gmail.com> <1f748ec60603240748r35f7e0f8p341ff3cffa68caf8@mail.gmail.com> <7d9a1f530603240757t24b82e99pbc22aecd02893ca8@mail.gmail.com> <7d9a1f530603240836u3d73540fmda1ded7f920ad2df@mail.gmail.com> <7d9a1f530603270241s8162b07xdf93e1c90d0e570a@mail.gmail.com> <7C8934BF-7D5D-4FC2-8030-7E06A4C88BA8@rjimlad.org> Message-ID: <7d9a1f530603272302w5e4f2c79k105f59744feaae06@mail.gmail.com> Hi Jim, > > Could someone check the new index page? It's better not to have too > > many mistakes on the page introducing the project ;). > > I actually avoided doing that before, because I thought that'd be a > bit intrusive or picky (or even arrogant) of me to do! Well personnaly I don't think correcting my crappy sentences is intrusive or picky at all. It even helps me improve my English so it's a great thing ;) From vincent.isambart at gmail.com Wed Mar 29 03:33:10 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Wed, 29 Mar 2006 10:33:10 +0200 Subject: [rhg-discussion] Last news Message-ID: <7d9a1f530603290033y55c456b9pc4720c0783e3f49c@mail.gmail.com> Hi everyone, I've made some improvements on generate_html.rb: - we can now put comments that won't be in the generated HTML using "$comment(my comment)$". It was mainly done to be able to force the encoding to UTF-8 in Emacs and VIM. I also added this to all the text files in English in the repository. - there's also warnings if the extension of the images used in the text files is JPG instead of PNG - there's also support for special tags in the text files and header/footer. The syntax is $tag(tag name)$. For the moment, the tags available are "title" (the title of the text file, that means what's beneath h1.) and "translation by" (the name of the translator(s)). The're only used in the header and footer for the moment, but I'll probably add later something like the last modification date or generation date. I've got an English question: is there in English a way to say that a note has been added by the translator (and was not in the original). In French, we use "NdT : note" (NdT = Note du Traducteur), for example something like "blah blah blah (NdT: This is no longer the case...)." I've also got a Japanese/English question, about how to translate the name of an other book by Minero AOKI, called "Ruby?256???????????". The best I could find is "The book to use 256 times more of Ruby - Unreasonable edition". At first I had problems with the ?, but I think what I came up with is not too bad, but I'm not 100% sure, and I'm far from sure about the ??? part. Cheers, Vincent From piyokun at gmail.com Wed Mar 29 06:46:20 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Wed, 29 Mar 2006 20:46:20 +0900 Subject: [rhg-discussion] Last news In-Reply-To: <7d9a1f530603290033y55c456b9pc4720c0783e3f49c@mail.gmail.com> References: <7d9a1f530603290033y55c456b9pc4720c0783e3f49c@mail.gmail.com> Message-ID: <1f748ec60603290346w60dffd25v2aacff65a0d7147e@mail.gmail.com> Hey Vincent: On 3/29/06, Vincent Isambart wrote: > I've made some improvements on generate_html.rb: Definately going to start using the comments tag. You have that problem of forcing Emacs to do utf-8, too? Check it: (find-file "ja/chapter03.txt") ; ugh the japanese doesn't come out. (set-buffer-file-coding-system "utf-8") (revert-buffer) ; sweet! > I've got an English question: is there in English a way to say that a I don't know. > I've also got a Japanese/English question, about how to translate the > name of an other book by Minero AOKI, called "Ruby?256???????????". Heh, the ?Ruby?256????????is a series of books: http://ruby256.hp.infoseek.co.jp/ Ruby?256??????????? Ruby?256??????????? Ruby?256??????????? Ruby?256+??????? ????? Ruby?256+??????? ????? Ruby?256??????????? Ruby?256???????????????? Ruby?256??????????? I suppose looking at this lineup, there's a certain "evil" theme with the naming. I don't think it has anything to do with Ruby being bad, though, and it certainly doesn't have anything to do with the contents. ??: unreasonable, lacking morals ??: cruelty ??: criminal, ganster ??: satanic, ? bad magic ????: outdoor/street fighting ????: Ruby mastery ??: ? network? ??: ? entering the road? > The best I could find is "The book to use 256 times more of Ruby - > Unreasonable edition". At first I had problems with the ?, but I think > what I came up with is not too bad, but I'm not 100% sure, and I'm far > from sure about the ??? part. Seems okay for lit. translation. I'd go with "256.times { eval( :Ruby.to_s ) }". You know, whatever Ruby refers to. -- Best regards, Clifford Caoile -- irb(main):001:0> my.greeting( :"rhg-discussion" ) => "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html" From meinrad.recheis at gmail.com Wed Mar 29 11:41:29 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Wed, 29 Mar 2006 18:41:29 +0200 Subject: [rhg-discussion] Last news In-Reply-To: <1f748ec60603290346w60dffd25v2aacff65a0d7147e@mail.gmail.com> References: <7d9a1f530603290033y55c456b9pc4720c0783e3f49c@mail.gmail.com> <1f748ec60603290346w60dffd25v2aacff65a0d7147e@mail.gmail.com> Message-ID: <43d756720603290841w6db44b69p91a3ae9550f4c5@mail.gmail.com> On 3/29/06, Clifford Caoile wrote: > Heh, the ?Ruby?256????????is a series of books: > http://ruby256.hp.infoseek.co.jp/ > > Ruby?256??????????? > Ruby?256??????????? > Ruby?256??????????? > Ruby?256+??????? ????? > Ruby?256+??????? ????? > Ruby?256??????????? > Ruby?256???????????????? > Ruby?256??????????? > > I suppose looking at this lineup, there's a certain "evil" theme with the > naming. I don't think it has anything to do with Ruby being bad, though, and it > certainly doesn't have anything to do with the contents. > hehe, seems there are still lot's of ruby books waiting to be translated ;) From vincent.isambart at gmail.com Fri Mar 31 03:03:46 2006 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Fri, 31 Mar 2006 10:03:46 +0200 Subject: [rhg-discussion] Plans Message-ID: <7d9a1f530603310003y42a14101h8601c5bb98bbf756@mail.gmail.com> Hi everyone, I went through the second half of chapter 4, it should be much easier to understand. I put it on SubVersion and on the web site just a few minutes ago. So I think the current plans before making a new announcement on ruby-talk for chapter 3, 4 and 6 should be: - proofreading, and report of hard to understand sentences in those chapters - Meinrad should take care the diagrams for chapter 6 - Clifford should clean the annotations between double-parentheses in chapter 3 (remove just the parentheses, remove what's inside them... it's your call). Personnaly, I did not hesitate to had some precisions that were not (at least not explicitely) in the Japanese. Are you OK with this? Cheers, Vincent From piyokun at gmail.com Fri Mar 31 07:37:54 2006 From: piyokun at gmail.com (Clifford Caoile) Date: Fri, 31 Mar 2006 21:37:54 +0900 Subject: [rhg-discussion] Plans In-Reply-To: <7d9a1f530603310003y42a14101h8601c5bb98bbf756@mail.gmail.com> References: <7d9a1f530603310003y42a14101h8601c5bb98bbf756@mail.gmail.com> Message-ID: <1f748ec60603310437v5ce8c2dcqef8f12d80c90915e@mail.gmail.com> > - Clifford should clean the annotations between double-parentheses in > chapter 3 (remove just the parentheses, remove what's inside them... > it's your call). Personnaly, I did not hesitate to had some precisions > that were not (at least not explicitely) in the Japanese. Okay, will do. Gotta go with the best shot. -- Best regards, Clifford Caoile -- irb(main):001:0> my.greeting( :"rhg-discussion" ) => "http://rubyforge.org/pipermail/rhg-discussion/2006-March/000015.html" From meinrad.recheis at gmail.com Fri Mar 31 14:44:25 2006 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Fri, 31 Mar 2006 21:44:25 +0200 Subject: [rhg-discussion] Plans In-Reply-To: <7d9a1f530603310003y42a14101h8601c5bb98bbf756@mail.gmail.com> References: <7d9a1f530603310003y42a14101h8601c5bb98bbf756@mail.gmail.com> Message-ID: <43d756720603311144xb016744w2fa641bcbb087cae@mail.gmail.com> On 3/31/06, Vincent Isambart wrote: > Hi everyone, > > I went through the second half of chapter 4, it should be much easier > to understand. I put it on SubVersion and on the web site just a few > minutes ago. > > So I think the current plans before making a new announcement on > ruby-talk for chapter 3, 4 and 6 should be: > - proofreading, and report of hard to understand sentences in those chapters > - Meinrad should take care the diagrams for chapter 6 acknowledged. -- henon