1419-1650

1232-1482 subjects 1651-1905

Ruby Tk on Mac OS X
1419 [mwilson13@co] I found a way to get Ruby Tk to work on Mac OS X. I have not
1420 [nobu.nokada@] You don't have to modify the file.  Use
1421 [mwilson13@co] Thank you. I will try this. I also plan to (1) try installation with
+ 1422 [ehughes@bl e] And the real problem is that's not the solution wanted by most Mac OS X
+ 1423 [nobu.nokada@] Unfortunately, I don't have a Mac.

curses.c and Mac OS X
1432 [ehughes@bl e] This nasty patch allows the current CVS version of Ruby to build on Mac OS
1433 [matz@ru y- a] Hmm, how did other OS X users succeed to compile?
1434 [ryand@ze sp ] I can confirm.
1435 [nobu.nokada@] It's my fault, sorry.
1436 [ehughes@bl e] No.
1437 [nobu.nokada@] It seems that _XOPEN_SOURCE_EXTENDED has no effect at all.
1438 [nobu.nokada@] Sorry, the patch for extconf.rb was useless.
1439 [ehughes@bl e] Sorry I haven't had chance to check this out yet; I'll give you a definitive
1440 [ehughes@bl e] that works for me on Mac OS.

Modified cgi.rb with documentation
1441 [gsinclair@so] Folks,

using procs with returns result in thread error
1445 [chr_news@gm ] The following snippet
+ 1446 [chr_news@gm ] ooops;-)
+ 1488 [matz@ru y- a] Probably we need better description.  I meant "return jump can't
  1489 [batsman.geo@] Why worry? Anyway the new semantics in 1.8 make this a non-issue.
  1490 [matz@ru y- a] Because it still happens if we use Proc.new instead of proc.

[PATCH] ruby-mode.el
1447 [rpav@us rs s] ...
+ 1449 [ryand-ruby@z] Yeaaaa!!! Vote this up, yo!
+ 1450 [rpav@me hl .] ...
  1464 [matz@ru y- a] Looks nice.  But heredoc terminator can be any identifier or string,

NODE_DSTR and NODE_EVSTR?
1454 [feldt@ce ch ] How are "dynamic" strings represented internally?
1455 [nobu.nokada@] NodeDump or ii would help you.
1456 [feldt@ce ch ] Have you been able to compile them with 1.8? I haven't.
1457 [nobu.nokada@] Hmmm, the latest in PragProg site still seems 0.1.7 for 1.6.
1458 [Dave@Pr gP o] Could you possibly e-mail your nodeDump.c - I must have updated my
+ 1459 [feldt@ce ch ] I've got a new version of ruth here that (tries) to do
+ 1460 [nobu.nokada@] ...
  1461 [george.marro] And very nice it is too. The compiler for ByteCodeRuby [1] runs very
  1463 [feldt@ce ch ] but it needs more testing and bug reports (although it will

%y{ ... } patch for 1.8.0
1465 [ruby-core@wh] hey, y'alls.

[PATCH] my next attempt... (Was: [PATCH] ruby-mode.el)
1466 [rpav@me hl .] ...
1467 [matz@ru y- a] Nice.  Here's the one I made from the latest CVS.
1468 [rpav@me hl .] Works for me, the patch succeeds against the version I've got with some

Re: Ruby ChangeLog format
1483 [ruby-core@wh] Ah, sorry.  I'll turn off 'expandtab' when I edit the ChangeLog.  Or
1484 [matz@ru y- a] Use Emacs. ;-)
1485 [ruby-core@wh] Ok.  Anything for the cause.

Bug fix for check_uint() in numeric.c
1486 [lyle@kn lo y] An FXRuby user discovered this problem when running some of the FXRuby
1487 [matz@ru y- a] Thank you.  May I add you name in the ChangeLog entry?

bug
1491 [matju@sy pa ] version 1.6.8. The following should raise a Errno::EAGAIN, but does not

non-blocking mode behavior (Re: bug)
1492 [nobu.nokada@] Behavior in non-blocking mode has been changed.  Also IO#gets
1493 [matju@sy pa ] * never, ever wait
1494 [akr@m1 n. rg] Because non-blocking mode may be set by other process if opened file
1531 [matju@sy pa ] Thanks for the reply. I didn't reply before because I was busy with other

|rcr|.xv  Index Variables ( *_with_index )
1495 [dooby@d1 .k ] ...
+ 1496 [gsinclair@so] I like the idea, and read nearly every word (skipping some
| 1497 [dooby@d1 .k ] So true.  Scan was an obvious example to show that the rule
+ 1498 [ruby-core@wh] A good, exhaustive trip through this particular debacle.  Your citations
  + 1499 [george.marro] What about hashes? Could/should the keys get passed to the index variable?
  | + 1500 [gsinclair@so] My understanding is that it's an automatic block-argument.  It is
  | + 1504 [dooby@d1 .k ] No, because you can use any current iterator which passes
  + 1505 [dooby@d1 .k ] Selectively quoting from your post http://www.ruby-talk.org/56845
    1506 [george.marro] (Mail originally sent privately by mistake - sorry for any confusion &
    1508 [dooby@d1 .k ] $XITER (horrible temporary name chosen by me to avoid clashes:)
    1509 [george.marro] Yes, I saw that - thanks. I'll try to give a bit more thought to syntax and

String#downcase! bug/oddness (?)
1501 [rpav@me hl .] This may or may not be considered a bug, but I don't see it documented
1502 [gsinclair@so] It's common, and I think controversial, that bang methods typically return

Re: [BUG] Additional info regarding ruby-talk:66239
1503 [decoux@mo lo] [[ followup in ruby-core ]]
+ 1507 [matz@ru y- a] Indeed.  Thank you for pointing out.
+ 1511 [decoux@mo lo] If I've well understood frame->argv is a value which is in the stack of

[OT] Posting apologies - was RE: |rcr|.xv  Index Variables ( *_wi th_index )
1510 [george.marro] (public mail sent privately, private mail sent publicly etc). I shall now

New tests
1512 [Dave@Pr gP o] I was looking through the new test/ruby/* stuff just now, and notices
+ 1513 [chad@ch df w] # I was looking through the new test/ruby/* stuff just now, and notices
+ 1514 [nahi@ke na t] Definitely.  Splitter.rb which I made only translates 'test_ok' into 'assert'.
  1515 [chad@ch df w] # Beside this, rubicon should be located at test/rubicon and supersedes test/ruby.
  1516 [nahi@ke na t] The problem left is; who will do it. :)
  1517 [chad@ch df w] # Hi, Chad,

[bug] Silent death of "ruby -e"
1518 [holmberg@ia ] I've found a weird bug. It can occur when running Ruby 1.8 with the
1519 [nobu.nokada@] It seems to depend on the shell.  You run mswin or mingw ruby
1520 [holmberg@ia ] But you are right: it seems like it is the eternal problem with
1521 [nobu.nokada@] It was a simple bug.  Thank you for the report.

Integrating Etc support for Win32
1522 [djberg96@ya ] I recently published sys-win32etc, a Ruby package that

Assignment to $--, $- and the like
1523 [batsman.geo@] Moin!
1524 [matz@ru y- a] Seems nice.  Thank you.

SuperCollider's new Rubyisms
1525 [matju@sy pa ] Apparently Supercollider (a sound processing language) got a more

report
1526 [supriya_b66@] how can i generate a Report using ruby cgi/ruby tk.

why does it take so long?
1527 [matju@sy pa ] time ruby -e '(3**40000)'
1528 [matz@ru y- a] Error print routine tries "inspect" first, then when it's too long, use

PATCH: open3.rb comments misleading
1529 [androflux@so] I found the comments in open3.rb misleading because it uses "in", which
+ 1530 [matz@ru y- a] Thank you for suggestion.
+ 1532 [rz@li ux m6 ] did you mean which?
  1540 [androflux@so] Yes, I did.

GC  disable / enable   question
1533 [torsten.rueg] Moi,
1534 [nobu.nokada@] Something wrong in your "partly constructing" way.  How are you
1535 [torsten.rueg] Is there ?  I'm reconstructing a possibly cyclic graph of objects from
+ 1536 [decoux@mo lo] why this question is in ruby-core rather than ruby-lang ?
+ 1537 [nobu.nokada@] Can't you show concrete code?  Ruby's GC shouldn't collect
  1538 [torsten.rueg] Sorry, I was a bit ahead of myself: I don't have the code that caused
  1539 [nobu.nokada@] FYI, there is rb_mem_clear().

How to debug ?
1541 [torsten.rueg] Moi,
1542 [decoux@mo lo] Do you have defined end proc, via rb_set_end_proc() or any other
1543 [torsten.rueg] It's the unit test framework.
1544 [decoux@mo lo] It take me a few seconds to write an extension which crash ruby : now I
1545 [torsten.rueg] You must be right, I am on the wrong list. This is not helpful at all.
1546 [decoux@mo lo] You have not given the most important information : it crash when you use

Building 1.8.0 on Solaris with Sun CC
1547 [ruby-core@ml] Anyone try building 1.8.0 on Solaris with the Sun C compiler? On
1548 [matz@ru y- a] I believe no one has tried.  Ruby on Sparc requires inline assembler.

Problem with xsystem in lib/mkmf.rb
1549 [ruby-core@ml] def xsystem command

Schedule for 1.8.1?
1550 [nathaniel@ta] Is there any kind of a timeline for the release of 1.8.1? I have some
1564 [matz@ru y- a] Not too far.  I once thought to release it before JAOO, but have been

Hashes as keys
1551 [nathaniel@ta] I was just playing around with Hash#hash and discovered that you can't use a
+ 1552 [jim@fr ez .o] irb
| + 1553 [jim@fr ez .o] I think the id of {} is changing.
| + 1554 [nathaniel@ta] Sure, you can assign a Hash as a Hash key, but it's mostly useless. For
|   1555 [vjoel@PA H. ] I'd like to know, too. Maybe a hash is thought of as an object with
|   1560 [androflux@so] That appears to be the case. For instance, a Hash with the cool "block
+ 1563 [Eugene.Scrip] Implement #hash and #eql? methods in the way you think they should work
| 1565 [chr_news@gm ] Your Hash is not (in this case each enumerate) order independent
| 1566 [Eugene.Scrip] Yes, you are right. This was just a fast dirty example of redefining
| 1568 [chr_news@gm ] Your probably right but if you really want a good and fast hash
+ 1569 [matz@ru y- a] I believe you've understand now.  You *can* use hashes as keys, but

ostruct.rb patch
1556 [nathaniel@ta] I've been finding OpenStruct to be very useful lately, and then I discovered
+ 1557 [nahi@ke na t] You define == and hash, not eql? and hash, right?
| 1558 [nathaniel@ta] Oops! I forgot that #eql?, not #==, is the #hash counterpart (there's
| + 1559 [nahi@ke na t] Ah.  I tend to write 'def hashCode ...', too. :-)
| | 1562 [nobu.nokada@] Perhaps.  The instance_eval needs to push the block whereas a
| + 1567 [matz@ru y- a] Show me the latest diff.  I think I will agree to apply it.
|   1571 [nathaniel@ta] Here it is. I've dropped the #hash method, and changed to using a protected
|   1573 [matz@ru y- a] Looks nice.  Check them in, please.
+ 1561 [chr_news@gm ] This hash function depends on the order of @table.keys resp.

SciTE YAML lexer for 1.8.1 release
1570 [sean@ce so t] I've been working on a YAML lexer for SciTE and herr lucky_stiff has
1572 [rich@in oe h] Andy Hunt builds the win32 distribution on

Automatic vars and setjmp
1574 [batsman.geo@] rb_callcc

String#gsub bug?
1575 [gsinclair@so] Is this a bug in Ruby or a bug in my brain?  I've stared at it for long
+ 1576 [ehughes@bl e] * means zero or more. Looks like that matched zero. Try + (one or more)
+ 1577 [bruceb3@zi .] I can't reproduce the output you are showing.
  1578 [gsinclair@so] That's what I expect, too.  I'll try again and make sure I've got the

arity bug?
1579 [chr_news@gm ] the following (with (2003-09-18) [i386-mingw32]
1580 [decoux@mo lo] svg% ruby -e 'a = proc { p 12 }; a[1,2,3]; b = proc {|| 13 }; b[1]'
1581 [chr_news@gm ] I known that the calling convention is consistent with the arity
1582 [matz@ru y- a] Why don't you specify parameters explicitly if you want to get the
1594 [chr_news@gm ] But if I don't provide explicit parameters at definition time

mkmf.rb fix
1583 [matju@sy pa ] I was supposed to be getting a Permission Denied message when trying to
1585 [matz@ru y- a] Thank you.

C++ wrapper for Ruby interface?
1584 [matju@sy pa ] I would like to know whether there are wrappers for ruby.h and intern.h
1587 [berk@up et r] rubyxx ? (raa:rubyxx should find it)

Yielding to a block from a proc?
1586 [austin@ha os] On irc://irc.freenode.net/#ruby-lang tonight we were discussing procs. Among
1590 [vjoel@PA H. ] class << self
1591 [george.marro] I agree that the above example is something you might well want to do, but,
1592 [ser@ge ma e-] How does that matter?
1593 [chr_news@gm ] It seems to me that George gave a good explanation why passing
1595 [ser@ge ma e-] I wasn't arguing the usefulness of being able to pass blocks to procs.  In
1601 [chr_news@gm ] Ditto.
1602 [ser@ge ma e-] Ok, thanks.  I didn't know this.  I retract my comment.
1605 [george.marro] Sorry for the scoping red herring - I was trying to explain why procs have a

FreeBSD problem with processes
1588 [pinux@te ed ] I noticed a weird problem when starting processes after loading both

Success story. Ruby 1.8.0 + OpenSSL for Ruby 2
1589 [v.shahov@sa ] Last time (from begining of 2003 to now) we are intensively using different versions of ruby (1.7.2, 1.7.3, 1.8.0pre1, *pre2, -final) and ruby-openssl (0.1.3 and 0.2.0pre).

PATCH: Revive NextStep, OpenStep, Rhapsody ports
1596 [sunshine@su ] Here is a patch which revives the NextStep, OpenStep, and Rhapsody ports of
1597 [matz@ru y- a] Hmm.  It's huge.  Could somebody confirm these changes, especially
+ 1598 [ryand@ze sp ] YEAH! I have an excuse to get my NeXTCube working! :)
| 1599 [sunshine@su ] I can also supply a patch for ruby 1.8.0, if you like, which makes 1.8.0
+ 1606 [sunshine@su ] I can re-submit the patch without the fixes for those three methods in the
  1607 [matz@ru y- a] Or explain those modifies.  I'm waiting for confirmation anyway.
  1608 [sunshine@su ] I consulted several `man' pages and found that the existing curses extension

CVS access
1600 [ser@ge ma e-] I seem to have lost CVS access to the Ruby server; it claims that I'm not in
+ 1603 [matz@ru y- a] Your name is not in the CVS passwd file.  How did you check in REXML?
| 1604 [ser@ge ma e-] I'll email cvs-admin.  Thanks.
+ 1609 [chad@ch df w] This same thing happened to me (I had rubicon access).  I emailed
| + 1610 [ser@ge ma e-] Matz took care of it for me.  His CVS elves must be on vacation.
| + 1629 [knu@iD em ns] Could you tell me when you sent me the first mail so I can check out
+ 1628 [knu@iD em ns] Hmm, I don't think I read that mail...  Didn't you get a bounce mail?
  1630 [ser@ge ma e-] I might have, but I get enough spams that claim to be bounces that I could

set_trace_func/Array#fetch error
1611 [nathaniel@ta] set_trace_func(proc{})
+ 1612 [decoux@mo lo] The PUSH_TAG(PROT_FUNC) has the same scope when it call call_cfunc()
| 1616 [nathaniel@ta] Ummm... I wish I could turn that in to useful code, but I'm nowhere near
| 1617 [decoux@mo lo] svg% diff -u eval.c.old eval.c
| 1618 [nathaniel@ta] <snip patch>
| 1620 [nobu.nokada@] Unfortunately, I guess it doesn't solve the true problem.  It's
| + 1621 [decoux@mo lo] There are 2 different problems
| | 1622 [nobu.nokada@] Not different.
| | 1623 [decoux@mo lo] I've never liked how ruby worked : now it's as stupid as me :-))
| + 1624 [dooby@d1 .k ] IMvvHO connecting these two problems would lead to complications.
|   1625 [decoux@mo lo] Well, if you don't like the original construct (return in {}), you must
|   1626 [dooby@d1 .k ] There's a clumsy way of doing it, too.
|   1627 [decoux@mo lo] Well not really, here a stupid example
+ 1613 [dooby@d1 .k ] [].fetch(2) {nil}  # <--------- see Array#fetch w/ block
  + 1614 [decoux@mo lo] No, no : this is volontary. See lib/optparse.rb
  | 1619 [dooby@d1 .k ] Understood (took me a while).
  + 1615 [nathaniel@ta] Sure, that would get rid of the error, but the point is that

inconsistency with lexing number bases
1631 [ryand-ruby@z] 0b0
1632 [ryand-ruby@z] um... smoking crack. I think we were mixing up our interpreters between

Re: [OT] inconsistency with lexing number bases
1633 [dooby@d1 .k ] One part of Ruby which I wish hadn't been modelled on

stringy range bug
1634 [chr_news@gm ] ...
+ 1635 [decoux@mo lo] Well, the problem here is that
| 1636 [chr_news@gm ] I know - actually I try to point out that one doesn't need to
| 1637 [matz@ru y- a] I presume the linear relation between "start" and "end".  Object and
+ 1638 [matz@ru y- a] This is a bug.  Thank you for reporting.
  1639 [jim@fr ez .o] That is scary. Why didn't rubicon catch this?

SystemStackError in embedding
1640 [sentinel27@g] (xpertmud.sf.net if anyone cares)
+ 1641 [mwilson13@co] I think that your program is bumping up against the maximum stack level
| 1642 [sentinel27@g] I am running on Linux, and it is compilable both as a pure Qt or a KDE
| 1643 [sentinel27@g] I checked the stack and it looks like a pretty normal stack for a Qt app
+ 1644 [matju@sy pa ] Find the place in the Ruby source code that is generating this error
  1645 [sentinel27@g] I am calling ruby_init from within the constructor of the XMRuby class
  1646 [matju@sy pa ] Assuming you're on i686-compatible chips, then this is a known bug that
  1647 [sentinel27@g] Great many thanks.

Code duplication in core libraries
1648 [simon@re hi ] ...
1649 [ehughes@bl e] It's not very informative. I wasn't able to find the duplication it's
1650 [simon@re hi ] Hehehe re sometimes copy and paste is deliberate. I'll check it out. I
threads.html
top