[#20675] RCR: non-bang equivalent to []= — Tobias Reif <tobiasreif@...>

Hi,

49 messages 2001/09/01
[#20774] Re: RCR: non-bang equivalent to []= — Tobias Reif <tobiasreif@...> 2001/09/03

I wrote:

[#20778] Re: RCR: non-bang equivalent to []= — Kevin Smith <kevinbsmith@...> 2001/09/03

--- Tobias Reif <tobiasreif@pinkjuice.com> wrote:

[#20715] oreilly buch von matz - website online — markus jais <info@...>

hi

43 messages 2001/09/02
[#20717] Re: OReilly Ruby book has snail on cover — ptkwt@...1.aracnet.com (Phil Tomson) 2001/09/02

Actually, thanks for posting it here. I was trying to search OReilly's

[#20922] Re: OReilly Ruby book has snail on cover — Paul Brannan <pbrannan@...> 2001/09/05

On Mon, 3 Sep 2001, Phil Tomson wrote:

[#20768] Minor cgi.rb question — "Hal E. Fulton" <hal9000@...>

I don't have much experience with

25 messages 2001/09/03

[#20770] Calling member methods from C++ — jglueck@... (Bernhard Glk)

Some quetsions have been solved for me, but my message system does not

12 messages 2001/09/03

[#20976] destructor — Frank Sonnemans <ruby@...>

Does Ruby have a destructor as in C++?

25 messages 2001/09/07

[#21218] Ruby objects <-> XML: anyone working on this? — senderista@... (Tobin Baker)

Are there any Ruby analogs of these two Python modules (xml_pickle,

13 messages 2001/09/15

[#21296] nested require files need path internally — Bob Gustafson <bobgus@...>

Version: 1.64

29 messages 2001/09/18
[#21298] Re: nested require files need path internally — David Alan Black <dblack@...> 2001/09/18

Hello --

[#21302] Re: nested require files need path internally — Bob Gustafson <bobgus@...> 2001/09/18

On Tue, 18 Sep 2001, David Alan Black wrote:

[#21303] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21306] Re: nested require files need path internally — Lars Christensen <larsch@...> 2001/09/18

On Tue, 18 Sep 2001, Yukihiro Matsumoto wrote:

[#21307] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21331] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/18

> The big difference is C++ search done in compile time, Ruby search

[#21340] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/18

Hi,

[#21353] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/18

On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

[#21366] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/19

Hi,

[#21368] Re: nested require files need path internally — "Julian Fitzell" <julian-ml@...4.com> 2001/09/19

On 19/09/2001 at 10:12 AM matz@ruby-lang.org wrote:

[#21376] Re: nested require files need path internally — matz@... (Yukihiro Matsumoto) 2001/09/19

Hi,

[#21406] Re: nested require files need path internally — Paul Brannan <pbrannan@...> 2001/09/19

On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

[#21315] Suggestions for new CGI lib — anders@... (Anders Johannsen)

From the comp.lang.ruby thread "Minor cgi.rb question" (2001-09-03), I

21 messages 2001/09/18

[#21413] Ruby/objects book in style of The Little Lisper — Brian Marick <marick@...>

I fell in love with Lisp in the early 80's. Back then, I read a book called

36 messages 2001/09/19
[#21420] Re: Ruby/objects book in style of The Little Lisper — Christopher Sawtell <csawtell@...> 2001/09/20

On 20 Sep 2001 06:19:44 +0900, Brian Marick wrote:

[#21479] Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/21

--- Christopher Sawtell <csawtell@paradise.net.nz> wrote:

[#21491] SV: Re: Ruby/objects book in style of The Little Lisper — "Mikkel Damsgaard" <mikkel_damsgaard@...> 2001/09/21

[#21494] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/21

--- Mikkel Damsgaard <mikkel_damsgaard@mailme.dk> wrote:

[#21510] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Todd Gillespie <toddg@...> 2001/09/22

On Sat, 22 Sep 2001, Kevin Smith wrote:

[#21514] Re: SV: Re: Ruby/objects book in style of The Little Lisper — Kevin Smith <kevinbsmith@...> 2001/09/22

--- Todd Gillespie <toddg@mail.ma.utexas.edu> wrote:

[#21535] irb — Fabio <fabio.spelta@...>

Hello. :) I'm new here, and I have not found an archive of the previous

15 messages 2001/09/22

[#21616] opening a named pipe? — "Avdi B. Grimm" <avdi@...>

I'm having trouble reading from a named pipe in linux. basicly, I'm

12 messages 2001/09/24

[#21685] manipulating "immutable" objects such as Fixnum from within callbacks & al... — Guillaume Cottenceau <gc@...>

Hello,

15 messages 2001/09/25

[#21798] Ruby internal (guide to the source) — "Benoit Cerrina" <benoit.cerrina@...>

Hi,

22 messages 2001/09/28

[ruby-talk:20683] eruby 0.9.6 doesn't work with ruby 1.7.1

From: Aleksi Niemel<aleksi.niemela@...>
Date: 2001-09-01 19:51:37 UTC
List: ruby-talk #20683
I can't make eruby 0.9.6 work with ruby 1.7.1. It works fine with ruby
1.6.1.

Here's a small eruby script which core dumps on every run (eruby core
dumps with other standard libraries as well):

  <%
    require 'thread'
  %>

And as far as I'm able to decipher the debugger output the file is being
closed (by calling rb_io_close) normally after succesful read, but in
the meanwhile the IO object gets messed so that RFILE(io)->fptr (on
io.c:1107) actually points to 0x8 instead of some meaningful struct
containing FILE pointers.

Where and why it's messed up beats me. Here's some debugging info. The
platform is i686-linux on a bit modernized Redhat 7.0. Many thanks.

    - Aleksi


Here are the strace outputs (first core dumps and the latter with 1.6.4
works):

[eruby-0.9.6-1.7]$ strace ./eruby ~/public_html/monitor3.rhtml
...
stat64("/usr/local/lib/ruby/1.7/thread.rb", {st_mode=S_IFREG|0644,
st_size=4350, ...}) = 0
open("/usr/local/lib/ruby/1.7/thread.rb", O_RDONLY) = 4
close(4)                                = 0
open("/usr/local/lib/ruby/1.7/thread.rb", O_RDONLY) = 4
close(4)                                = 0
open("/usr/local/lib/ruby/1.7/thread.rb", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=4350, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40018000
read(4, "#\n#\t\tthread.rb - thread support "..., 4096) = 4096
brk(0x8115000)                          = 0x8115000
brk(0x8116000)                          = 0x8116000
read(4, "it.shift\n\tt.wakeup if t\n      re"..., 4096) = 254
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x40018000, 4096)                = 0
close(3)                                = 0
munmap(0x40017000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
write(2, "./eruby: [BUG] Segmentation faul"..., 33./eruby: [BUG]
Segmentation fault) = 33
write(2, "\n", 1
)                       = 1
write(2, "ruby 1.7.1 (2001-08-29) [i686-li"..., 37ruby 1.7.1
(2001-08-29) [i686-linux]
) = 37
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
getpid()                                = 13817
kill(13817, SIGABRT)                    = 0
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++





[eruby-0.9.6-1.6]$ strace ./eruby ~/public_html/monitor3.rhtml
...
stat64("/usr/local/lib/ruby/1.6/thread.rb", {st_mode=S_IFREG|0644,
st_size=4301, ...}) = 0
stat64("/usr/local/lib/ruby/1.6/thread.rb", {st_mode=S_IFREG|0644,
st_size=4301, ...}) = 0
open("/usr/local/lib/ruby/1.6/thread.rb", O_RDONLY) = 4
close(4)                                = 0
open("/usr/local/lib/ruby/1.6/thread.rb", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=4301, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40018000
read(4, "#\n#\t\tthread.rb - thread support "..., 4096) = 4096
brk(0x810a000)                          = 0x810a000
brk(0x810b000)                          = 0x810b000
read(4, "\tretry\n      ensure\n\tThread.crit"..., 4096) = 205
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x40018000, 4096)                = 0
close(3)                                = 0
munmap(0x40017000, 4096)                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 12), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40017000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "\n", 1
)                       = 1
write(1, "\n", 1
)                       = 1
munmap(0x40017000, 4096)                = 0
_exit(0)                                = ?




And finally a gdb stacktrace:

Starting program: /home/aleksi/imu/ruby/raa/eruby-0.9.6-1.7/eruby
/home/aleksi/public_html/monitor3.rhtml

Program received signal SIGSEGV, Segmentation fault.
rb_io_fptr_close (fptr=0x8) at io.c:1094
1094	    if (!fptr->f && !fptr->f2) return;
(gdb) bt
#0  rb_io_fptr_close (fptr=0x8) at io.c:1094
#1  0x807918f in rb_io_close (io=1075559332) at io.c:1108
#2  0x8053ac9 in eruby_load (
    filename=0xbffff8cb "/home/aleksi/public_html/monitor3.rhtml",
wrap=0, 
    state=0xbffff690) at eruby_lib.c:692
#3  0x80523cd in run () at eruby_main.c:531
#4  0x8052503 in main (argc=2, argv=0xbffff72c) at eruby_main.c:558
#5  0x40093b5c in __libc_start_main (main=0x80524e4 <main>, argc=2, 
    ubp_av=0xbffff72c, init=0x80507b4 <_init>, fini=0x80bab90 <_fini>, 
    rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffff724)
    at ../sysdeps/generic/libc-start.c:129


This transmission is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is private and confidential. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any distribution, dissemination or copying of this message is strictly prohibited.
If you have received this message in error, please notify the sender immediately by return E-mail and remove the original message. Thank You. The content of this message is not given or endorsed by HEX unless such content relates to the official business of the firm.
HEX reserves the right to monitor all E-mail communications through its networks. The attachments have been scanned for viruses prior to leaving our E-mail server. HEX shall not be liable for any consequences of any virus being passed on.

In This Thread

Prev Next