51506-52586
51194-52197 subjects 51624-52716
^ 'kakasi': different style for hiragana and katakana?
51506 [AntiATField_] KATAKANA
51533 [gotoken notw] As far as I know, kakasi doesn't have such function.
51578 [AntiATField_] Thanks! Where can I find an EUC-JP coding table (not containing each
^ RubyConf: Perl/Python folks?
51518 [hal9000 hype] Just curious...
51524 [mike stok.co] The spirit is willing, but the wallet is weak :-(
^ String gsub last '/\\%[0-8a-fA-F][0-8a-fA-F]/ match does not sub
51528 [robert_linde] This is a multi-part message in MIME format.
51544 [ryand zenspi] Why would it replace %29? your matching 0-8, not 0-9.
51551 [robert_linde] Me , Dummy.
51556 [drbrain segm] The other option is to use cgi-lib to unescape the string and use a
^ Where Is Method Call Precedence?
51530 [billtj y.glu] When I look at "Table 18.4: Ruby Operators" in the Pickaxe book, I cannot
51531 [matz ruby-la] Usually these are not handled by precedence order. They are just
+ 51618 [billtj z.glu] This is actually rather confusing to me, since in Ruby the '()' is
| 51718 [matz ruby-la] It's due to YACC restriction. It is relaxed in 1.7.x though.
+ 51706 [qrczak knm.o] f Ada, Eiffel, Haskell, Mercury, Perl, Pliant, Ruby, Tcl, Pascal
+ 51712 [pixel mandra] page .../syntax-across-languages.html can now be accessed per category
+ 51714 [mikkelfj-ant] tuple)
51750 [gsinclair so] Since Ruby is close to Python is *some* ways, and Python has tuples, I cast the
+ 51754 [billtj y.glu] If I remember correctly, tuples can be used as hash keys while an
| 51917 [bulatz integ] CLU roots? :)
| 51925 [matz ruby-la] Tried?
| 51941 [bulatz integ] p hash[s] #=> nil
| + 51955 [billtj z.glu] Everything below is "obvious" and natural, isn't it? That's why I don't
| | 51964 [bulatz integ] s = "mutable"
| | 51979 [billtj z.glu] When I first read your code below, it was also obvious to me, since the
| | + 51984 [dblack candl] hsh.rehash -> hsh
| | | 51992 [billtj z.glu] Wow, quite a revelation to me, David! Thanks a lot for pointing the *very
| | + 52073 [bulatz integ] not VALUES! it is OBVIOUS that hash keys must not change just because
| + 51971 [qrczak knm.o] It's not obvious that a Ruby hash doesn't put given objects as keys
| + 51982 [billtj z.glu] Thanks for the explanation; now it is more clear to me regarding the
| + 52012 [pixel mandra] on this subject, i've collected the behaviour of important types
| + 52023 [qrczak knm.o] You are wrong that OCaml string constructor allocates a copy.
| 52034 [pixel mandra] fixing
+ 51790 [mikkelfj-ant] cast the
| 51793 [billtj y.glu] I think Ruby NArray has about the same efficiency as the new array/tuple
+ 51916 [bulatz integ] tuple is an array with fixed size. when you have very large number of
51958 [billtj z.glu] Do you mean just because we need to story only "len" instead of "len" and
+ 51966 [bulatz integ] no, len is coded in tuple type (Tuple2, Tuple3 and so on). and if you
| 51981 [billtj z.glu] I am using Ruby v 1.6.7 (which is called the "stable version" at
| 52074 [bulatz integ] 1) sizeof(len)+sizeof(capa) == 8 :)
+ 51967 [bulatz integ] .... but Array_Of_Tuples is better candidate for realization. but in
+ 51994 [batsman.geo ] If size is fixed (de)allocation can be made much faster and is
+ 51998 [billtj z.glu] Isn't that in the current Ruby (1.6.7) the memory area is already managed
| 52025 [batsman.geo ] Agreed, we get to save a bit of mem per tuple, not per element. But it
+ 52001 [mikkelfj-ant] and
^ RDE Abbrev Option
51532 [volkmann2 ch] Can someone tell me the magic key sequence that causes an abbreviation to be
52586 [wvucenic net] Ctrl + K
^ www.ruby-lang.org maintenance
51561 [shugo ruby-l] www.ruby-lang.org will be DOWN at Wed Oct 2 4:00:00 UTC for the
52222 [shugo ruby-l] It was done successfully. Thank you.
52229 [ryand-ruby z] Shugo, you rock!
^ [ANN] New announcement-only moderated mailing list
51569 [ryand-ruby z] With great pleasure, I would like to announce the creation of a
+ 51612 [gsinclair so] Good idea, but wouldn't it be sensible to keep English-speaking mailing lists
+ 51615 [billtj z.glu] Will you cc the announcements there to comp.lang.ruby too? (To me,
51737 [dsafari para] Depending on how often an "announce" list gets used, hopefully the RWN will
^ R (was: adding overload to ruby)
51574 [tsiivola cc.] What I'd *love* would be to keep ruby dynamic as it is, and have a
+ 51576 [bulatz integ] my idea is opposite - ruby code with some hints can be effectively
| 51591 [tsiivola cc.] But never as effectively as purely static code... And when you introduce
| + 51593 [cboos bct-te] merd =
| | + 51595 [bulatz integ] i think that laguage author is just don't know that language
| | + 51597 [hal9000 hype] Well, the French abbreviation for OOP
| | 51598 [cboos bct-te] Well, I just want to apologize to Pixel, the Merd
| | 51600 [cboos bct-te] (sorry, I was too quick on my keyboard)
| + 51621 [billtj z.glu] I tend to agree with Bulat. If people think it isn't Ruby anymore, that's
| + 51623 [probertm nor] FWIW, a rather unfortunate choice of name...
| | 51632 [billtj z.glu] Oops, then should we call it "TRuby" instead? Well, never mind, this
| + 51628 [jason jvoege] While I certainly don't feel that such things should be a part of Ruby
| | 51642 [billtj z.glu] In general I agree with you that *contract* is really a good idea (I think
| | + 51649 [patrick.benn] Perl has done just fine making it in the corporate/business world, and
| | | 51686 [billtj z.glu] I think we *may* have the options of either following a path more like
| | + 51719 [dblack candl] But they won't, because they'll never have incentive to. And, even if
| | 51735 [billtj y.glu] In principle I agree with you. I am also aware of the danger of creating
| + 51679 [batsman.geo ] [deleted]
| | 51694 [billtj z.glu] Exactly. At this point, there is nothing fundamentally changed regarding
| | + 51708 [batsman.geo ] But all you're getting is "type error" instead of another description.
| | | 51731 [billtj y.glu] Agreed. The error message is just an example; in the real thing it may be
| | | 51773 [szegedy t-on] I think it's true.
| | + 51730 [matz ruby-la] Do you mean you don't care about dispatching?
| | 51736 [billtj y.glu] I am sorry, as I am not an advanced programmer, may I know the exact
| | 51931 [matz ruby-la] Your "syntax sugar" just checks types.
| | 51959 [billtj z.glu] Oh, I am really sorry, Matz. I was concentrating more on static
| + 51741 [tsiivola cc.] Actually the idea is almost the opposite: Ruby should be dynamic. R Should
| + 51747 [billtj y.glu] I think I agree with the above statements; I just want flexibility for
| | + 51752 [dblack candl] I don't know about the speed of C, but if you want the simplicity
| | | 51755 [billtj y.glu] Oh yes, in fact, this is one of our selling points, right? We show the
| | | + 51757 [dblack candl] I hope Ruby will continue to be Ruby even if you write this third
| | | | + 51759 [billtj y.glu] Exactly. Right now, I have only two choices. When I need ease of life, I
| | | | | + 51761 [alwagner tca] Who is this "we" you speak of?
| | | | | | 51766 [billtj y.glu] Anyone interested in R, including myself and probably Nikodemus? :)
| | | | | | 51777 [robert.calco] I'm currently working on a project I'm calling Ruby/FE, where FE stands for
| | | | | | 51791 [billtj y.glu] Thanks for sharing the information. I will especially be interested in
| | | | | + 51763 [alan digikat] Ruby-C integration really isn't that complicated. In fact, from my use, Ruby
| | | | | | 51808 [billtj y.glu] I think it is true in general, but please see also my discussion with Paul
| | | | | + 51839 [tsiivola cc.] Definitely.
| | | | | | 51960 [billtj z.glu] I am sorry, I am not trying to represent Matz. But if I am allowed to
| | | | | + 51928 [bulatz integ] c/pascal is last languages without gc. now gc is common aven for
| | | | + 51997 [qrczak knm.o] Not that significant. OCaml is fast and garbage-collected. I've
| | | | + 52003 [vjoel PATH.B] IIRC Ruby's GC never moves anything. It's mark and sweep.
| | | | + 52008 [billtj z.glu] Isn't that the "significance" is influenced by the type of gc and the
| | | | + 52042 [mikkelfj-ant] There is a technical paper at the OCaml site discussing strict typing versus
| | | + 51919 [bulatz integ] see Eiffel. it's bit old and stupid, i heard that Sather is more
| | + 51835 [tsiivola cc.] That would imply one language, would it not: one syntax. It may be doable,
| | | 51932 [bulatz integ] we don't have to lose open classes. these definitions work at
| | + 51918 [bulatz integ] main ruby speed problem - dynamic method dispatching, which don't
| | 51923 [matz ruby-la] I'm not sure. From my simple benchmarks, method cache hit rate is
| | 51938 [bulatz integ] but hash itself need time to work :) and other dispatching code too.
| | 51949 [matz ruby-la] No. Tree search result is stored in the cache, whose hit rate is more
| | 51953 [bulatz integ] well. consider "2+2" example. when we compile ruby to c, we need to
| | + 51969 [billtj z.glu] Exactly, exactly, Bulat. I have been thinking exactly the same
| | | 52070 [bulatz integ] no! c++ analog is NOT USING virtual keyword. and offsets instead of
| | | 52090 [tsiivola cc.] As far as R is concerned I am going to drop into quit head-scratching mode
| | | 52092 [bulatz integ] i don't understand you clearly, but how about just another ruby-to-c
| | | + 52095 [tsiivola cc.] Definitely a good idea, but not my cup of tea.
| | | + 52124 [billtj y.glu] I think that is exactly the point. At least one ruby-to-c translator
| | + 51975 [batsman.geo ] Do you have any idea about where they might be?
| | + 51989 [billtj z.glu] I guess that's why Java has two data types: the primitive types (such as
| | | 52077 [bulatz integ] nor c# :(( ;) but eiffel has better solution
| | + 52071 [bulatz integ] well, i think that we can combine hashing and offsets for method
| | 52267 [batsman.geo ] And sometimes per object too.
| | 52334 [bulatz integ] i say about COMBINING dynamic and static approaches
| | 52365 [batsman.geo ] How? Offset tables for methods known at compile-time and hashes for the
| | 52366 [bulatz integ] yes
| | 52368 [decoux moulo] After syntax analysis, ruby don't know the methods used.
| | 52372 [bulatz integ] ok, "after analysis" :)
| | 52374 [decoux moulo] Same response
| | 52443 [bulatz integ] you are wrong
| | 52470 [decoux moulo] The proof, i.e. a concrete implementation.
| | 52474 [bulatz integ] result of lexical analysis is stream of terms. on the next stages ruby
| | 52475 [decoux moulo] Like I've said : concrete implementation
| | 52476 [bulatz integ] File.new('p.rb').split(/[^a-zA-z0-9$@]/)
| | 52477 [decoux moulo] [[ this is my last message on this subject ]]
| | 52478 [bulatz integ] 10x!
| + 51795 [batsman.geo ] OK, I'll toy a little with the nature of the R language.
| | + 51802 [billtj y.glu] In general I agree with the layout. The only sticky point is the "have no
| | + 51844 [tsiivola cc.] Definitely.
| | 51866 [batsman.geo ] Then it could be made optional, and better yet, selected at runtime.
| | 51897 [tsiivola cc.] Good question. Partially the idea rose out of love of ruby, and dislike of
| + 52005 [qrczak knm.o] I don't see how lack of GC can be compatible with dynamic types.
| + 52010 [billtj z.glu] I think all the combinations are possible. For an example of dynamic type
| + 52020 [qrczak knm.o] It's unusable in practice. I talked about programming languages which
+ 51584 [ NO SPAM] It has not a Ruby syntax, but it seems to me that Ocaml fits in
| 51770 [szegedy t-on] 1) It is considerably less concise than Ruby.
| + 51779 [jason jvoege] I realize that such benchmarks must be taken with a large grain of salt,
| | 51789 [szegedy t-on] I was quite biased *for* ocaml because of those benchmarks.
| | + 51813 [frido q-soft] Are you kidding, the tests are a playground for C programs.
| | + 52482 [kgergely mla] and faster, than ruby :)
| + 51812 [frido q-soft] No it is not, you have to learn it a bit better.
+ 51636 [gsinclair so] This is certainly an interesting idea. If Ruby and R could be automatically
+ 51782 [szegedy t-on] I would like to have a Ruby like language which is
+ 51788 [dblack candl] Ruby > (Smalltalk + Perl) / 2
51805 [hal9000 hype] I just realized why this interesting statement
+ 51806 [billtj y.glu] Because it is ">" (or even ">="), why should Ruby be *worse* than one of
| 51827 [bilotta78 ho] (8+2)/2 = 5 ; 6>5 but 6<8
| 51863 [jason jvoege] I think William's point was (8 + 2)/2 = 5; 50 > 5 and 50 >8. Meaning
+ 51807 [dblack candl] I'm actually following up on what Bill points out in the next post.
51816 [hal9000 hype] Yes, you're both right, of course.
+ 51821 [vjoel PATH.B] Heh. But that's easy: 00
+ 51846 [dblack candl] Except then everyone would just roll their eyes and say, "Oh, a
^ Design patterns for communication protocols?
51586 [coma_killen ] I'm about to implement some custom communication protocols for a
+ 51589 [bulatz integ] erlang programming language
+ 51637 [hutch recurs] On 9/27/02 6:27 AM, "coma_killen@fastmail.fm" <coma_killen@fastmail.fm>
| 51922 [james jamesb] and
| 51973 [hutch recurs] Sorry James, I could have been a lot clearer in my wording. I knew about
| 51995 [james jamesb] Thanks for pointing this out. I checked the link to see if it was still
+ 51638 [hutch recurs] On 9/27/02 6:27 AM, "coma_killen@fastmail.fm" <coma_killen@fastmail.fm>
^ OT: merd (was Re: R (was: adding overload to ruby))
51602 [pixel mandra] if u wanna troll, try better ;p
51606 [bulatz integ] how many languages you know?
+ 51720 [matz ruby-la] I'm sure he knows a LOT. He's a language mania like me.
| 51914 [bulatz integ] me too :)
| 51950 [pixel mandra] well i've had pb mailing you privately [*]
| + 51951 [szegedy nosp] A 62 Kl Perl program...
| + 51957 [pbrengard bc] 62 KSLOC of Perl for DrakX ?
+ 51743 [leikind mova] I think http://merd.net/pixel/language-study/ is
^ REXML Attribute class
51604 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
^ [ANN] Russian Ruby mailing list
51605 [leikind mova] A Ruby mailing list in Russian has just been started!
+ 51611 [gsinclair so] Great to hear it! I won't be koining, though ;)
| 51634 [gsinclair so] Nor joining, for that matter.
+ 51690 [ptkwt shell1] horosho!
51749 [gsinclair so] I know that means "good" (or more likely "great") because "horrorshow" means
51758 [ptkwt shell1] Yup.
^ REXML namespace support
51616 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
51622 [kou cneti.ne] You can use REXML::Element#namespace if you are using a-la DOM API.
51639 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
+ 51658 [mgushee have] But you have a Document instance, don't you?
+ 51660 [mgushee have] (REXML::XPath.match(doc,'//*|//@*').detect \
| 51665 [kou cneti.ne] parser = REXML::SAX2Parser.new(xml)
+ 51962 [hutch recurs] XML namespaces are defined as xml is processed. The prefix may be reused.
+ 51965 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
+ 51983 [mgushee have] You mean 'prefix-to-namespace mappings are defined ...', don't you? Sorry
+ 51990 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
| 52013 [mgushee have] I'm not sure how to parse that sentence. Is ActiveState doing Ruby now?
| + 52014 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
| + 52017 [hutch recurs] W3C appears to have sanctioned the practice. Personally, I think the idea is
| 52019 [Mark.Volkman] This message is in MIME format. Since your mail reader does not understand
| 52022 [hutch recurs] Didn't mean to suggest otherwise. My sympathies :-)
+ 51996 [hutch recurs] I guess I meant both.
52004 [mgushee have] True. I used to teach an intro-to-XML course. The students were by no
+ 52016 [hutch recurs] [... discussion about XML documents with the same prefix referring to
+ 52027 [mikkelfj-ant] w.r.t.
52028 [mgushee have] Maybe I'm dense, but I don't follow this at all. Are you saying these
52037 [mikkelfj-ant] case
52045 [mgushee have] Okay, it starts to make a bit more sense then. Unfortunately I don't
52310 [mikkelfj-ant] I was referring to returning the namespace given a namespace prefix, not the
threads.html
top