196325-199437

196087-197990 subjects 196409-199088

properly extending test::unit to add logging
196325 [rsanheim@gm ] I'd like to open up test::unit to add default logging to setup and
196326 [ara.t.howard] whenever you wrap methods like this __always__, __always__, __always__ do this
196379 [rsanheim@gm ] Thanks for the tip.  Besides that, are there any other gotchas related
196381 [ mfp@ac .o g] This one is at least as conspicuous as the above one, but just in case...

[ANN] RubyWrap - intelligent wrapping of comments in ruby (and other languages)
196328 [chris.alfeld] After getting frustrated with existing solutions I threw together a

how do I impose a method call delay?
196336 [jsallis@gm i] I've got a simple Ruby class that has one method which uses open-uri to
+ 196346 [ara.t.howard] #! /usr/bin/env ruby
+ 196347 [chris.hulan@] class politeGet
  + 196349 [chris.hulan@] Need to swap the last two statements in getDoc so it returns the doc and
  + 196350 [jsallis@gm i] Thanks to both of you...I think Chris' idea is probably sufficient for
  + 196360 [ljz@as as .c] Well, this does force a delay, but I'm pretty sure that it won't solve
    196361 [jsallis@gm i] My apologies, Lloyd...after re-reading my initial post, the language was
    196365 [ljz@as as .c] Well, thanks for clearing that up.  However, Chris's procedure, as
    196367 [jsallis@gm i] More food for thought.  I'm going to collect some more information
    196371 [ljz@as as .c] Well, recall that Ara T. Howard's methodology will indeed ensure that no

Setting HTTP Headers
196342 [doug.bromley] ...
+ 196352 [mictro@gm il] "By adding headers at any point in the script?" Just to be sure, we talk about http?
+ 196353 [asbradbury@t] open("http://www.ruby-lang.org/en/",
  196354 [dandiebolt@y] ...
  196358 [asbradbury@t] Documentation may be lacking in some areas, but you can rely on RDoc to at

Using IRB from a script
196344 [jgbailey@gm ] ...

Ruby Installer - now or later?
196345 [andy14@ya oo] Windows Installer or waiting for the final bits as it sounds like they
196396 [ml.chibbs@gm] ...

EURUKO 2006
196359 [sigma.kappa@] after reading about RubyConf and the two RailsConfs, I thought that it
+ 196502 [matthias-lue] very good idea, I would certainly attend! And talking about locations I
| + 196504 [james_b@ne r] If I am able to make over to Europe, Munich would get my vote:  Family
| + 196569 [chneukirchen] +1
|   196598 [codeblogger@] ...
|   196717 [shortcutter@] I guess the individual or organization that will organize it should
+ 196505 [daniel.schie] I'd like to cast my vote for Copenhagen -- not too far from where I live :)
| 196548 [jes@lu et nk] Make that Copenhagen for me too.
+ 196550 [a2800276@gm ] Further north would be my preference, too. How about K?ln (Cologne)?
  + 196551 [robert.feldt] I vote for Copenhagen too; would increase my chances of being able to
  | 196556 [laurent.sans] Well I have nothing against Copenhagen (it would even allow me to
  | 196557 [a2800276@gm ] Is there currently anyone here that's part of an organization
  + 197484 [ jupp@gm .d ] cologne.supporters.push("Jupp")
    197559 [listbox@ju i] +1, close to Utrecht - 1.5 hours by train
    199378 [rubytalk@sp ] to keep this thread alive: +1 anywhere in Europe (preferably not
    199437 [a2800276@gm ] I think at this point the only way to keep this thread alive is for

output delay
196362 [dshackel@ar ] Howdy,
196375 [M.B.Smillie@] This is the result of buffered output, one simple change ought to fix
196432 [dshackel@ar ] Thank you, that was exactly what I needed.  Last night as I was trying

sending false to logger outputs nil?
196363 [rsanheim@gm ] Am I missing something?  Why would sending false to the logger just

Requiring a file into a different namespace
196364 [mjudge@su ve] ["a","b"].each do |name|
+ 196368 [logancapaldo] Search the mailing list archives, this was discussed very recently.
+ 196383 [transfire@gm] ["a","b"].each do |name|
| 196473 [lukfugl@gm i] $ cat a.rb
| + 196483 [transfire@gm] module_eval File.read("#{name}.rb")
| + 196485 [transfire@gm] Sounds good. Although I think the most recent develpoment "trial" is
| + 196536 [vjoel@pa h. ] Until then, http://raa.ruby-lang.org/project/script may be useful.
+ 196387 [dave@bu t. d] It's not weird. Require (or load) is going to load the script normally

DRMAA for Ruby
196380 [Andreas.Haas] please find under

Using a string to find a class
196388 [pergesu@gm i] I've got a string, and I want to find out if there's a class with that
+ 196389 [has.sox@gm i] This ones come up a few times on the list
| 196440 [ruby@an hr p] } Although in some methods that I have seen in the rails source there has been
+ 196390 [dave@bu t. d] module.const_get "Foo"
| 196391 [james_b@ne r] You'll get an exception if Foo isn't defined.
+ 196428 [transfire@gm] Use Facets' kernel/constant
+ 196441 [ruby@an hr p] } I've got a string, and I want to find out if there's a class with that

[ANN] SimpleGraphs 0.00000001
196393 [jp@je fp it ] This is a follow up to a recent thread about "BrainDeadBarGraphs".

Problems with rb_struct_define and 64 bit Ruby
196395 [djberg96@gm ] ...
196406 [decoux@mo lo] "gamma", NULL);
196508 [halostatue@g] Gah. That's one of the things that I absolutely *despise* about C as
196553 [decoux@mo lo] Well, the architecture x86_64 was created to make in sort that C

Why the lack of mixing-in support for Class methods?
196402 [alder.green@] I'm confused as to why class methods aren't include'd by default along
+ 196405 [rubyfan@gm i] The main reason is because a different 'self' is involved, I would guess.
| 196407 [alder.green@] Yes, I'm using this idiom in my code. Note, however, that if you want
| 196418 [matz@ru y- a] Mix-in is used for several purposes and some of them can be hindered
| 196468 [alder.green@] I see your and Dblack's point about the need for an #include that
| 196476 [matz@ru y- a] I don't like the name #inherit.  Since it is not a inheritance.
| + 196478 [ara.t.howard] i've suggested 'mixin' in the past
| | + 196480 [james@gr yp ] I like that.
| | + 196486 [halostatue@g] * #include only deals with the inclusion of instance-level methods
| |   + 196499 [alder.green@] I like #blend. Goes well with #blend? etc.
| |   | 196501 [alex@bl ck e] derive (a little obscure)
| |   | 196503 [curi@cu i. s] evolve seems vague and makes people think of monkeys
| |   | + 196506 [james_b@ne r] Sure.  Monkey patching.
| |   | + 196514 [agorilla@gm ] What's wrong with that? ;)
| |   |   196519 [billk@ct .c ] enchant ?  enliven ?  enfold ?  incorporate ?  induct ?  ;)
| |   |   196525 [ara.t.howard] i like it.  i think i may have come up with that one a while back too.  that,
| |   |   196533 [halostatue@g] Sensible. You include functionality from a module, you extend an
| |   + 196549 [rubyfan@gm i] module A
| |     196554 [dblack@wo bl] I think that's a dangerous path to go down.  self is really just an
| + 196489 [transfire@gm] I knew you were going to say that ;) I actually hesitated to suggest
| | 196521 [transfire@gm] Considering the above (which by the way should also have an 'include
| | + 196537 [matz@ru y- a] I like this more than others, but I worry about that this is less
| | | + 196538 [hal9000@hy e] class Beanbag
| | | | 196559 [me@yo rh me ] I like this and it fits into the current scheme.
| | | + 196539 [logancapaldo] well we have class << self, which involves singleton methods
| | | | 196555 [dblack@wo bl] I'm not sure << really evokes "connected in some way with singleton
| | | | 196558 [james@gr yp ] Well, extend takes the instance methods of a module and makes them
| | | | 196565 [dblack@wo bl] I know (believe me, I've been through many iterations of this
| | | | + 196566 [dblack@wo bl] s/Instance/SomeInstance/ :-)
| | | | + 196571 [ara.t.howard] module Sync
| | | |   196599 [vjoel@pa h. ] Here's another shortcut, dunno how original it is. I don't like the
| | | |   + 196605 [alder.green@] Assuming #import would have a callback-hook like #included
| | | |   | 196607 [vjoel@pa h. ] The #imported callback might help (and it would inevitably be requested
| | | |   | 196614 [alder.green@] The major lack right now is a way to "include" module methods. Even if
| | | |   | 196662 [transfire@gm] I am suddenly reminded of the idea non-inherited methods --a way to
| | | |   + 196640 [transfire@gm] Hey, Joel. Have a look at Facets' class_inherit.rb. It is a complete
| | | + 196564 [transfire@gm] Unfortuantly, as it is, we cannot know. I have seen some bad practices
| | | + 196672 [matz@ru y- a] But I am still not sure if we need to provide the way to inject module
| | |   + 196699 [gm.vlkv@gm i] It's natural and more "perfect".
| | |   + 196708 [transfire@gm] I think the clearest use is with DSLs that also has useful instance
| | |     196725 [matz@ru y- a] I still have difficulties to imagine the concrete situation.
| | |     + 196730 [daniel.schie] class Module
| | |     | + 196739 [transfire@gm] Daniel! I think you actually make my point! Matz, see what Daniel has
| | |     | | 196747 [daniel.schie] Actually, that solution seems overly complicated -- that may be for
| | |     | | 196751 [transfire@gm] I'm not sure if you understand the important difference though --it's
| | |     | | 196770 [daniel.schie] What I like about my solution is the interface -- the implementation was
| | |     | | 196780 [ruby@an hr p] } What I like about my solution is the interface -- the implementation was
| | |     | | 196786 [daniel.schie] Wouldn't this fix it?
| | |     | | 196790 [ruby@an hr p] } >... if you don't call class_methods before
| | |     | | 196828 [daniel.schie] Still think it's rather complicated. Here's what I've got so far, using
| | |     | | 196844 [ruby@an hr p] } >Sure, I understand. And yes, that would fix it. Take a look at the complete
| | |     | | 196880 [daniel.schie] Because I'd like the meta-module methods to act as module methods -- if
| | |     | + 196744 [james@gr yp ] const_defined? :ClassMethods
| | |     |   196746 [daniel.schie] I'm not too fond of the nested module approach -- I think it's cleaner
| | |     |   196749 [james@gr yp ] Oh well, to each their own.
| | |     + 196735 [transfire@gm] The problem runs deeper than this. Having to depend on "some kind of
| | |       196738 [matz@ru y- a] Don't get me wrong.  I didn't say that I wouldn't do nothing, and let
| | |       + 196741 [dblack@wo bl] It looks reasonable though I would recommend not calling the method
| | |       | 196748 [daniel.schie] name. It's actually hard to pinpoint a reasonable one...
| | |       | 196755 [dblack@wo bl] Which might be telling us something.... :-)
| | |       + 196742 [alder.green@] IMHO, the best approach in this thread is the access-control style
| | |       + 196743 [transfire@gm] He he. That's ironic. Yes, Daniels solution is the right direction for
| | |         196805 [matz@ru y- a] Which is your "last post"?  Is it [ruby-talk:196751]?
| | |         + 196815 [transfire@gm] I concur with that. It is certainly not a simple thing, and I can only
| | |         | 196858 [matz@ru y- a] Because it makes thing more complex, I guess.  Mere #include should
| | |         | 196860 [ara.t.howard] what did you think about my solution matz?  it's solves the issue cleanly and
| | |         | 196866 [sean.ohalpin] I for one like it - pragmatic and straightforward. However, I'm not
| | |         | 196871 [ara.t.howard] module M
| | |         + 196825 [daniel.schie] I'm wondering why it's not possible to #include a class into a
| | |           196865 [logancapaldo] Then you have multiple inheritance.
| | |           196870 [daniel.schie] Yes.
| | |           + 196878 [logancapaldo] That's why it's not possible. matz. has strong feelings about MI.
| | |           | 196881 [daniel.schie] I'm not saying we should add it to core -- but I don't understand why we
| | |           + 196885 [transfire@gm] Not really. Mulitple Inheritance provides orthogonal heirarchies.
| | |             + 196889 [ara.t.howard] in my mind it's this that makes it __not__ mi
| | |             | 196893 [stonelists@g] ...
| | |             | 197092 [pertl@gm .o ] are you looking for that here?
| | |             + 196924 [alder.green@] Exactly.
| | |               196929 [logancapaldo] I think a little context has been lost in this conversation, if I may
| | |               196949 [transfire@gm] Techincally it isn't. Multiple inheritance can have iheritance
| | |               196977 [daniel.schie] I agree with you throughout the post, and I do enjoy being called Mr.
| | |               197012 [transfire@gm] You have to understand a little about how modules are tied into the
| | |               + 197019 [daniel.schie] All I wanted to know.
| | |               + 197025 [matz@ru y- a] I don't think I understand you.  Do you want to allow #include to
| | |                 + 197043 [gwtmp01@ma .] It isn't altogether obvious to me why a class passed to #include
| | |                 | 197044 [ara.t.howard] module M
| | |                 | 197063 [gwtmp01@ma .] I don't see how your example is any different than the problem
| | |                 | 197073 [ara.t.howard] yes.  the problem is that mixin modules, by design, seldom have name
| | |                 + 197053 [transfire@gm] No no. You'd still only be able to include modules. I'm thinking a
| | |                   197065 [matz@ru y- a] That makes modules too "special".  Every object has its own "singleton
| | |                   197140 [transfire@gm] I see your point. This solution is kind of drastic in that respect.
| | |                   + 197144 [matz@ru y- a] You got me wrong again.  I asked you what if I'd add Daniel's API to
| | |                   | + 197147 [transfire@gm] Ah yea, sorry for rambling. As I said, I already use that API, so, yea,
| | |                   | | 197162 [matz@ru y- a] module Moo
| | |                   | | 197163 [rubyfan@gm i] Maybe it could be called class_methods ?
| | |                   | | + 197166 [matz@ru y- a] I thought of the name first, but I changed my mind because it is too
| | |                   | | | + 197225 [james@gr yp ] I think I still prefer this approach, though the method thing is OK
| | |                   | | | | 197240 [transfire@gm] If you allow #class_extension (or whatever you want to call it) to also
| | |                   | | | | 197246 [matz@ru y- a] I think class_extension (or whatever) plus and include will do.
| | |                   | | | | 197249 [transfire@gm] Nice point.
| | |                   | | | | + 197250 [matz@ru y- a] I am not thinking about implementation detail yet.  What do you think
| | |                   | | | | | 197289 [transfire@gm] It's not as simple as it seems. After manuevering past the potential
| | |                   | | | | | + 197304 [vjoel@pa h. ] Why should the order of calling extend and adding methods matter? It
| | |                   | | | | | | 197306 [transfire@gm] It's a little more subtle than that, because it has to do with modules
| | |                   | | | | | | 197311 [vjoel@pa h. ] 1. Are chained inclusions of modules a good way to propagate class
| | |                   | | | | | | 197316 [transfire@gm] Yes, b/c if you don't you won't be able to propogate data/control
| | |                   | | | | | | 197375 [matz@ru y- a] I consider a module as a place holder of methods to be injected into
| | |                   | | | | | + 197376 [matz@ru y- a] It's how modules work, at least under the current implementation.
| | |                   | | | | |   197381 [transfire@gm] You mean to say you are going to eval the code directly into the target
| | |                   | | | | |   197382 [matz@ru y- a] No.  I just said `I am not going to call "extend @class_extension" for
| | |                   | | | | |   + 197387 [daniel.schie] module A
| | |                   | | | | |   | 197391 [matz@ru y- a] I meant A.foo would raise NoMethodError.  Since class_extension
| | |                   | | | | |   | 197395 [daniel.schie] Splendid! That was also my first hunch. I'll just fix my implementation
| | |                   | | | | |   + 197393 [transfire@gm] Okay. Whew. Scared me for a moment. Your last comment about me going
| | |                   | | | | + 197257 [gwtmp01@ma .] I was thinking that the block would just be evaluated in the context of
| | |                   | | | |   197294 [daniel.schie] Then inheritance problems will arise --  I think we need to use modules.
| | |                   | | | |   197296 [ara.t.howard] ...
| | |                   | | | |   197334 [daniel.schie] I can of course only speak for myself, but I'm not fond of the idea of
| | |                   | | | |   197345 [ara.t.howard] ...
| | |                   | | | |   + 197363 [sean.ohalpin] [snip persuasive code examples]
| | |                   | | | |   + 197379 [daniel.schie] I'm not saying it'll be easy, but I do think it's possible to use
| | |                   | | | |     197390 [daniel.schie] Okay, I've sorted out a few of the problems, and I hope I haven't
| | |                   | | | |     197396 [daniel.schie] class Module
| | |                   | | | |     197423 [daniel.schie] class Module
| | |                   | | | |     197439 [daniel.schie] Simplification. Tell me if I should stop spamming.
| | |                   | | | |     + 197451 [transfire@gm] Daniel,
| | |                   | | | |     | 197476 [daniel.schie] That, and it's nice to have an implementation that fits with the
| | |                   | | | |     | 197479 [matz@ru y- a] Yes, and there's something that only working code can prove.
| | |                   | | | |     | 197488 [ara.t.howard] do you think this is important?
| | |                   | | | |     | + 197492 [daniel.schie] This seems to have been resolved in the latest version.
| | |                   | | | |     | + 197504 [matz@ru y- a] The difference here is caused because a class statement with in
| | |                   | | | |     | | 197510 [ara.t.howard] yes it does.  that makes me feel better.  thanks for the explanation.
| | |                   | | | |     | + 197582 [sean.ohalpin] Well, I agree with you on both counts - I like your semantics and
| | |                   | | | |     |   197587 [transfire@gm] Right on. I and the Nitro project have been despretely needing a
| | |                   | | | |     + 197490 [daniel.schie] #class_extension is now private, the magic has been moved to
| | |                   | | | |       + 197494 [ara.t.howard] is this by design?
| | |                   | | | |       | + 197500 [daniel.schie] Yes, it's by design. Originally I extended the class that defined the
| | |                   | | | |       | + 197501 [matz@ru y- a] Yes.  class_extension add features to the target class but not to the
| | |                   | | | |       |   + 197511 [ara.t.howard] code.gsub! /M/, 'C'
| | |                   | | | |       |   | 197579 [matz@ru y- a] Yes, thank you.
| | |                   | | | |       |   + 197619 [dblack@wo bl] Will this happen if the module is included in another module?  If so,
| | |                   | | | |       |     197624 [matz@ru y- a] module M
| | |                   | | | |       |     + 197626 [daniel.schie] No, the class extension should be included into both modules and
| | |                   | | | |       |     + 197628 [angus@qu va ] I'd say yes.
| | |                   | | | |       |     + 197645 [transfire@gm] The name is not really incorrect because
| | |                   | | | |       |     + 197668 [ara.t.howard] singleton_methods &block
| | |                   | | | |       |     | 197674 [daniel.schie] * singleton_module
| | |                   | | | |       |     | 197679 [transfire@gm] Eeek! Please, no "singleton". Anything but "singleton".
| | |                   | | | |       |     | + 197682 [daniel.schie] `beer_module'?
| | |                   | | | |       |     | + 197690 [ara.t.howard] what's wrong with singleton?  alternatives?
| | |                   | | | |       |     |   + 197692 [gwtmp01@ma .] Uh oh.  Here we go again...
| | |                   | | | |       |     |   + 197720 [sean.ohalpin] extension &block
| | |                   | | | |       |     + 197747 [dblack@wo bl] Yes, I think so.
| | |                   | | | |       + 197498 [transfire@gm] Isn't #funcall now called #instance_exec?
| | |                   | | | |         + 197505 [daniel.schie] I think #instance_exec is an eval method.
| | |                   | | | |         + 197506 [matz@ru y- a] I don't.  Luckily or not.  For your information, 'funcall' is a lisp
| | |                   | | | |           + 197509 [daniel.schie] Ahh, the Ruby Collage of Inspiration. Cool.
| | |                   | | | |           + 197512 [transfire@gm] I see. I wouldn't otherwise have a problem with the name 'funcall' but
| | |                   | | | |             197588 [matz@ru y- a] Good point.  We will have __funcall__ as well.  Thank you.
| | |                   | | | |             197594 [halostatue@g] Should we have __dup__ and __clone__ and __class__ and __object_id__?
| | |                   | | | |             + 197596 [logancapaldo] I can definitely see __class__ and __object_id__. #dup and #clone
| | |                   | | | |             | 197605 [transfire@gm] Of course __dup__ and __clone__ can be overridden too. But I imagine
| | |                   | | | |             + 197603 [transfire@gm] I agree. And I did add __class__ in basic object, though I find it's
| | |                   | | | |             + 197648 [shugotenshi@] Heh, soon we'll end up adding other __*__ methods for the sake of it.
| | |                   | | | |             + 197697 [chneukirchen] Instead of further pythonizing the language (sorry, couldn't resist),
| | |                   | | | |               + 197712 [halostatue@g] I could get behind that. Probably worth an RCR, I think.
| | |                   | | | |               | 197803 [transfire@gm] I expiremented with that idea a while back when I was doing some work
| | |                   | | | |               + 197827 [ruby-talk@wh] So, it quacks like a dog, but if we really press it, we can get a proper
| | |                   | | | |                 197847 [chneukirchen] And what if I still feel more meta than you? ;-)
| | |                   | | | + 197278 [rubyfan@gm i] I mean your proposal seems more convenient than the common idiom I showed.
| | |                   | | + 197220 [james@gr yp ] I think that name misrepresents what the method does.
| | |                   | + 197152 [transfire@gm] Well, I hate to throw a wrench in the works at this point, but (by
| | |                   + 197201 [daniel.schie] module A
| | + 196593 [alder.green@] You can say in a comment or a discussion: "check if Fooable is
| |   196594 [ara.t.howard] assimilated?  borged?
| |   196596 [agorilla@gm ] incorporated!  _then_ Ruby will be Enterprise-ready ;)
| + 196737 [zdennis@mk e] Why change the name of include, why not just give it some options. The
+ 196417 [dblack@wo bl] It's actually a fairly specialized case.  In the general case, if a
+ 196422 [rosejn@gm il] You can do this without too much trouble.  This is what I use, which is
| 196431 [transfire@gm] Not the same thing.
+ 196430 [ara.t.howard] module M
  196433 [transfire@gm] Sigh. We've been through this Ara. It's a silly example --don't use
  196438 [ara.t.howard] indeed.  still - i see it being a bit anti POLS from someone's perspective,
  196459 [transfire@gm] Fair enough. No doubt it will come with it's own set of considerations
  196466 [ara.t.howard] right.  it's just that 'inheritence' with object generally follows this
  196488 [transfire@gm] Okay. I see what you're saying. Thouhg, I guess I'm thinking class
threads.html
top