1-226 subjects 394-614
Mem leaks in rb_str_become?
0199 [m.rokos@sh c] I'm not sure is following code doesn't mem leaks...
0200 [matz@ru y- a] OK.
Bug in enum.c?
0201 [m.rokos@sh c] there could be bug in enum_sort_by? (Jump to !!!!!!! below)
+ 0202 [nobu.nokada@] Yes, segfaulted and fixed by your patch.
+ 0203 [matz@ru y- a] It is a bug. Commit it please. Thank you.
0204 [m.rokos@sh c] Done. Thank you.
openbsd system call changes
0205 [jfh@ge ty gr] I'm assuming that this is the right place to send proposed patches for
+ 0206 [nobu.nokada@] Right.
| 0207 [jfh@ge ty gr] Pah! You're right.
| 0214 [kjana@dm la ] The patch around setpgrp() let me recall the bug of autoconf-2.52
| 0215 [jfh@ge ty gr] Aha. I'm using 2.52. I will upgrade.
+ 0210 [matz@ru y- a] Could somebody confirm this patch, especially on OpenBSD and other
0211 [sean@ru y- a] Works for FreeBSD 5.0-CURRENT. I'm re-sending the patch as an
RSTRING macro in array context
0208 [jfh@ge ty gr] Is this a typo?
0212 [matz@ru y- a] Yes, thank you for the patch.
OpenSSL in the base system?
0209 [sean@ru y- a] What are the odds of having Michal Rokos's OpenSSL included in the
0220 [m.rokos@sh c] There could be some problem with licences of some
Consistent class naming for TCPSocket...
0213 [sean@ru y- a] Attached is a patch to fix consistency issues with TCPSocket and
[PATCH] lib/mkfm.rb: have_bin()/find_bin()
0216 [sean@ru y- a] This could be me over looking something, but in mkmf.rb, there is no
0217 [sean@ru y- a] Whoops, wrong patch (the other patch was for fix to a security error
0218 [nobu.nokada@] I guess it's better to use CONFIG["EXEEXT"] and
0219 [sean@ch tt n] [resent]
Wiring up the Boehm GC to the Ruby interpreter
0221 [matthew@by e] I tried wiring up the Boehm GC (downloaded a couple of days ago) to the
+ 0222 [jfh@ge ty gr] Looks like what you've done is to replace ruby's calls to malloc with a
| 0223 [mattbee@so p] No, I took out the calls to the Ruby GC. There's obviously still some
+ 0224 [matz@ru y- a] gc.c allocates big chunks of memory using malloc() and chop them into
Re: [gclist] Wiring up the Boehm GC to the Ruby interpreter
0225 [matz@ru y- a] firstname.lastname@example.org
speed improvements during ruby_init
0227 [jfh@ge ty gr] Messing around with gprof after being agitated by a recent thread
Patch to stop TCPSocket.new blocking on DNS lookups
0228 [mattbee@so p] I'm using Ruby for a multi-threaded (50 or 60 threads at once) web spider and
+ 0229 [matz@ru y- a] How about using "Socket.do_not_reverse_lookup = true"?
| 0230 [mattbee@so p] The delays I'm experiencing were due to (necessary) forward lookups as far as
+ 0231 [decoux@mo lo] Well, getaddrinfo_a() is available only for glibc >= 2.2.4, no ?
0232 [mattbee@so p] Yup, I believe it's a pretty new call. But unless we roll a DNS resolver
0233 [matz@ru y- a] Then have you looked at resolv-replace.rb ? It replaces name lookup
Re: [PATCH] lib/mkmf.rb: have_bin()/find_bin()
0234 [nobu.nokada@] Sorry to be late.
0235 [matz@ru y- a] I feel like "bin" in have_bin and find_bin (BTW, why both?) is better
0323 [sean@ru y- a] executable works for me, I can update the patch. The reason for both
0236 [sdalu@ni .f ] - it fixes the TCP Requester, even if not directly used by the DNS class,
[PATCH] object.c ruby.h (fwd)
0237 [skaav@gm .n ] my name is Robert Skarwecki and this is my first contribution to the Ruby
0239 [gotoken@no w] Indeed introducing Boolean may make is-a relation clear in the
0240 [Dave@Pr gm t] For what it's worth, I think this is an evil side of the assert
0246 [gotoken@no w] Indeed assert() of Test::Unit::Assertions does not test true/false.
+ 0247 [Dave@Pr gm t] Hmm - I differ here. I'd expect assert() to work the same way as 'if'
| + 0248 [nobu.nokada@] How about "true?"?
| | 0249 [Dave@Pr gm t] Well, to me, a.true? would imply the same as a == true, which isn't
| | 0250 [nobu.nokada@] Hmmm, then a.t?. It would be lispy...
| | + 0251 [Dave@Pr gm t] Well, I guess the _ideal_ would be to have nothing, and to then have
| | + 0252 [gotoken@no w] Isn't it too hackish :)
| | 0253 [Dave@Pr gm t] If you call Regexp#match with a non-string argument, it calls that
| | + 0255 [gotoken@no w] Oops! Sorry, I misunderstood that `and' or `or' treat conditions as
| | | 0268 [masaki.suket] Older version of RubyUnit's assert() behavior is same as Test::Unit's.
| | | 0269 [Dave@Pr gm t] There's not much we can do if people call the incorrect method :)
| | | 0288 [masaki.suket] Ok. I will change the behavior of assert of RubyUnit like as Test::Unit.
| | | 0295 [nahi@ke na t] -1 for this change but I can live with it.
| | | 0304 [masaki.suket] If I add assert_true method which checks 'foo == true',
| | | 0313 [nahi@ke na t] Yes, I can. At the next, does method 'assert' become
| | | 0315 [masaki.suket] No, at least I never deprecate 'assert' method.
| | | 0320 [nahi@ke na t] It's slightly regrettable for me that it won't be deprecated.
| | + 0260 [kjana@dm la ] That's like my old proposal on.... where? :-) Matz rejected that since
| + 0258 [nahi@ke na t] +1 to gotoken. assert is for tester. When someone put on
+ 0262 [m.rokos@sh c] I think if the RTEST returns 0 for Qnil or Qfalse, so Qnil is
+ 0263 [Dave@Pr gm t] Although this is a pure approach, I think it would make programming in
+ 0266 [matz@ru y- a] Parhaps.
Boolean class (Re: [PATCH] object.c ruby.h)
0238 [matz@ru y- a] * use unified diff (diff -u) instead of plain old diff to create
Compiling ruby on SGI origins
0241 [W.L.Kleb@la ] I just tried compiling ruby-1.6.7 on a couple SGI origins (mips-sgi-irix6.5),
0245 [matz@ru y- a] You need to supply the directory where libtk8.0 is, by --with-tcl-lib=
0264 [W.L.Kleb@la ] Shouldn't configure have complained about not finding tk lib before I
+ 0265 [W.L.Kleb@la ] Anyway, I did this and now I'm getting the same error *as* on
+ 0267 [matz@ru y- a] It does on other platforms. I don't know why SGI is different.
0274 [W.L.Kleb@la ] It appears that gcc is not configured correctly on either SGI
unifying nil and false (Re: [PATCH] object.c ruby.h)
0242 [matz@ru y- a] "nil" and "false" are treated differently everywhere. Unifying them
0243 [Dave@Pr gm t] I know, I know... It was just a wistful question... :)
0244 [matz@ru y- a] How about going back to Ruby version 0.95? ;-)
A couple of questions on writing extensions
0254 [mattbee@so p] *) what does 'Died with exception wrong argument type Object (expected Data)'
+ 0256 [mattbee@so p] A bit more information: if I put a "print key.type" statement before & after
+ 0257 [nobu.nokada@] Literally, you passed something else to the method expecting
0259 [mattbee@so p] You're right, I think it was a misunderstanding with the mark/free functions
FYI: Updated Boehm GC
0261 [rich@in oe h] I know there were some activities a bit back on this...
Who'd be the best person to handle this?
0270 [Dave@Pr gm t] I just received the following from Jim Freeze <email@example.com>
0271 [decoux@mo lo] Not me :-)
Questions about installing in a corporate WAN
0272 [jim@fr ez .o] I have been trying to explore various install options
0273 [decoux@mo lo] Well, if you want a statically linked ruby, you must compile it with
0275 [decoux@mo lo] A small precision : you don't have problems with $SAFE <= 3
[Patch] Tini mini Range cleanup
0276 [m.rokos@sh c] there is nearly nothing to say about. Just 1 LONG2FIX conv, 1
0277 [matz@ru y- a] Commit them. Thank you.
0278 [m.rokos@sh c] Done. Thank you.
A truth? patch + benchmarks
0279 [chr_news@gm ] ...
0280 [decoux@mo lo] Not really sure but the values < 64 reserved for T_MASK
0283 [chr_news@gm ] Hm, what about using FL_USER7? More generally, is there any
0284 [matz@ru y- a] Unfortunately, there's no bit available for all objects. All flag
0285 [chr_news@gm ] To bad ... but maybe we might see something like it in 2.0? (or
+ 0286 [decoux@mo lo] Well, personnally I've not found a difference between the macro and inline
| 0287 [chr_news@gm ] inline
+ 0289 [matz@ru y- a] If it is really efficient, I think we can reserve a bit ot two for
0294 [chr_news@gm ] One bit should be enough. My tests indicate that for the current
0296 [nobu.nokada@] It's true with gcc 2.95.3 under i686-linux.
0281 [m.rokos@sh c] today I get a little bored, so I started to play with POSIX
0282 [decoux@mo lo] be carefull with this and see [ruby-talk:5956]
0290 [flori@ni e. ] some methods of File::Stat return 0 if the underlying feature isn't
Kernel Thread implementation
0291 [mattbee@so p] ...
0292 [decoux@mo lo] Put it in RAA
reply for your message
0293 [matz@ru y- a] Hmm,
0307 [rich@in oe h] returned
[Cleanup] GC longjmp macros
0297 [m.rokos@sh c] I think that these lines are odd in gc.c
0300 [matz@ru y- a] Why did you feel so?
0301 [m.rokos@sh c] Because they are not in use in gc.c? (At least I cannot see any
0302 [nobu.nokada@] gc.c:1166-1169
0303 [m.rokos@sh c] True. (I got lost in ARCH def on line 1080.)
Is there a bug in Matrix or Complex?
0298 [jim@fr ez .o] I found what I would call strange behavior with Matrix and Complex.
0299 [gotoken@no w] Elements above are floating point numbers, not integers. This odd
File::Stat#blksize etc. should return nil instead of 0
0305 [flori@ni e. ] Ok, nobody seems to use those platforms (MS Windows, I guess) anyway. ;)
0306 [matz@ru y- a] Sounds reasonable. If no one stands against the idea, I will apply
Q: OSSL in std. distr?
0308 [m.rokos@sh c] I just wanted to ask what should I do to 'OpenSSL for Ruby'
0310 [decoux@mo lo] * why OpenSSL *must* be in the standard distribution ?
0311 [m.rokos@sh c] The status is little vierd. The parts that are in OSSL are
0312 [jfh@ci e. fl] I am -- thanks for developing it!
Progress on incremental GC?
0309 [tjw@om ig ou] I noticed some messages in the archive about updating Ruby to use the
resolv.rb on 1.6.7
0314 [Dave@Pr gm t] I'm not sure if this is a ruby-core issue or not, so I'll keep it brief.
Embeding Ruby in C++ code.
0316 [kmak@cs .a t] #include <ruby.h>
0317 [nobu.nokada@] You forget "self".
C and Ruby...
0318 [kmak@cs .a t] How can i add an instance variable in a ruby class object?
0319 [nobu.nokada@] rb_ivar_set(obj, rb_intern("@foo"), Qtrue);
[ToDo] Ruby module, Warn(ing) interface
0321 [m.rokos@sh c] I've been reading through ToDo document and stuff like Warn(ing)
0322 [nobu.nokada@] I guess it's better to be printf-like as C version.
Mswin32 build flags
0324 [chr_news@gm ] the current mswin32 build unfortunately (globally;-)
0325 [usa@os .a t.] Because there are more problems with /Og flag
0422 [chr_news@gm ] Thanks (and sorry for the late reply)
Implications of a #force_free method in Object?
0326 [mattbee@so p] I'm wondering whether it would be a sensible idea to implement a #force_free
0327 [nobu.nokada@] It sounds very dangerous, and the method wouldn't be able to
[Cleanup?] Int vs Long
0328 [m.rokos@sh c] because I have nothing to do and I'm quite bored, I went through
+ 0332 [jfh@ci e. fl] How's ThreadSafeRuby coming along?
| 0335 [m.rokos@sh c] My idea was to bring real threads to Ruby (POSIX, Windows, or SW
+ 0333 [ryand@ze sp ] Is any work being done to speed up certain aspects of ruby? I was
0336 [matz@ru y- a] IKEGAMI Daisuke is working on faster bignum multiplication using
[Cleanup?] Int vs Long #2
0329 [m.rokos@sh c] ... and Diff is in this one :-))
0330 [matz@ru y- a] It looks like OK. Please commit.
0331 [m.rokos@sh c] Done. Thanks.
0334 [ryand@ze sp ] yeah... i'm a dope. I need more coffee today. Resent w/ a real subject.
[Cleanup] Int vs Long (2nd part)
0337 [m.rokos@sh c] I just noticed that I forgot to change 1 int to long in
+ 0338 [nobu.nokada@] This changes semantics.
| 0339 [m.rokos@sh c] thanks for review.
| + 0341 [m.rokos@sh c] is this OK then?
| + 0343 [matz@ru y- a] I think so too. The current bahavior creates an hash even when the
+ 0342 [matz@ru y- a] Commit this, please.
0347 [m.rokos@sh c] Done. (Commited the patch without changing ary_new() to
[Cleanup] Int vs Long #3
0340 [m.rokos@sh c] this is the 3rd part of int x long cleanups.
0344 [nobu.nokada@] Although I doubt if they can exceed INT limit, well, no
0348 [m.rokos@sh c] thank you for a kind review again.
0350 [nobu.nokada@] $ diff --help | grep -we -p
0351 [m.rokos@sh c] Ah, grep - I didn't get the context... :-)
Bug in gc.c or misunderstanding on my part?
0345 [tjw@om ig ou] I was just eyeballing through the Ruby source trying to evaluate it
0346 [cboos@bc -t ] rb_gc_stack_start is not only used for that, it is also
0349 [m.rokos@sh c] memory opt version of Array#select.
0354 [matz@ru y- a] Accepted.
0357 [m.rokos@sh c] Commited.
Re: [Cleanup] Int vs Long #3 (RESEND with -p)
0352 [m.rokos@sh c] Here's the -p version.
0371 [m.rokos@sh c] I'm sorry, I didn't receive any feedback for ruby-core:352 (this
0374 [matz@ru y- a] It's OK. If you believe your fixes are mere cleanup, you don't need
0377 [m.rokos@sh c] Thank you, but I'd rather post the patches to ML first.
[Cleanup?] File (struct stat handling)
0353 [m.rokos@sh c] when I tried to track down all remaining off_t leftovers, I saw
+ 0356 [nobu.nokada@] Since File::Stat.allocate doesn't initialize DATA_PTR, this
+ 0359 [matz@ru y- a] Why should we use memcpy instead of struct assigmnent?
0370 [m.rokos@sh c] Now, I see what's wrong on my patch. Thanks nobu, matz.
0375 [matz@ru y- a] Could you explain why you prefer memcpy? I'm just curious.
0379 [m.rokos@sh c] Shame on me...
[Useless] Array and .*ALLOC.* changes
0355 [m.rokos@sh c] In ruby-core:33 I sent some useless patches to array.c. In
0360 [matz@ru y- a] Go ahead.
0368 [m.rokos@sh c] Done.
[-Wall] node.h for eval.c
0358 [m.rokos@sh c] I touched node.h to make eval.c -Wall compilation happier.
+ 0361 [matz@ru y- a] Accepted.
| + 0362 [nobu.nokada@] Sorry, it's unnecessary, since rb_eval() always restores
| + 0369 [m.rokos@sh c] Commited. Thank you.
+ 0365 [ryand@ze sp ] I just spent an LAX to SEA plane trip cleaning all but two warnings for
Ruby embedding limitations
0363 [tjw@om ig ou] There are a couple of basic problems with Ruby's embedding support
0364 [vjoel@PA H. ] Fork a subprocess to run ruby on each game type, and use drb to
0366 [ryand@ze sp ] I don't think this is a very satisfactory answer. We should admit that
RE: Welcome to our (ruby-core ML) You are added automatically
0367 [girishs@wr x] My email-id firstname.lastname@example.org may not be valid from next month on, could
0372 [m.rokos@sh c] about month ago I prepared this cleanup, but forgot it :-)
0373 [nobu.nokada@] + str = rb_str_new(0, 2 + strlen(s) + 3 + SIZEOF_LONG * 2 + 1 + 1);
0378 [m.rokos@sh c] + long len;
0380 [nobu.nokada@] It's better.
0381 [m.rokos@sh c] If you agree, I will commit this version. (It's based on my 1st
0383 [nobu.nokada@] I agree, and guess your previous patch has no problem.
0384 [m.rokos@sh c] commited.
Virtual host and port number in CGI
0376 [raymond@th b] I am trying to figure out how to get the hostname and port # that was
[Update] Port match to new dup, clone framework
0382 [m.rokos@sh c] I spotted that match (in re.c) is not updated to new clone, dup
0385 [nobu.nokada@] You mean this? ;-)
0386 [m.rokos@sh c] I knew that you will definitely find some bug in it. (Shame on
0389 [matz@ru y- a] OK if you add class check to become method (orig may not be MatchData),
0391 [m.rokos@sh c] Added and commited.
0387 [m.rokos@sh c] condition FL_TEST(str2, ELTS_SHARED|STR_ASSOC) is allway true,
0390 [matz@ru y- a] Thank you for finding. Probably we need this too.
Native Threads (was Re: [Cleanup?] Int vs Long)
0388 [jfh@ci e. fl] Hmmm...if it were possible to have a hash that atomically raised an
[Patch] io.c read_all
0392 [m.rokos@sh c] ===========================ChangeLog===============================
[MemLeak] in dln.c
0393 [m.rokos@sh c] am I right?
+ 0397 [matz@ru y- a] Yes. Thank you for finding a memory leak.
+ 0398 [nobu.nokada@] This looks tiresome.
+ 0402 [m.rokos@sh c] Of course it's ugly, but ... it was friday evening and I had to
+ 0403 [m.rokos@sh c] Well, personally, I'd add (before line with /* FIXME: Mem
0404 [matz@ru y- a] I'd use alloca. I want dln.c to be separatable from Ruby as much as
0405 [m.rokos@sh c] So, #2 is a winner.
+ 0406 [matz@ru y- a] It seems OK (for me). If you check if it works, go ahead to commit.
| 0435 [m.rokos@sh c] Commited. (Including fix from ruby-core:407)
+ 0407 [nobu.nokada@] Ruby uses missing/alloca.c for such platforms, however I've
| + 0409 [m.rokos@sh c] yes, I definitely missed this.
| + 0411 [m.rokos@sh c] personally, I'd go for #3, than #1, and then #2.
| 0418 [matz@ru y- a] Since I want dln.c to be separatable, I prefer #2, #1, then #3.
+ 0408 [m.rokos@sh c] you have just introduced MEM leak, dude! :-)