[#2332] Ruby-Python fusion? — mrilu <mrilu@...>
Usually I give some time for news to settle before I pass the word, but
7 messages
2000/04/01
[#2353] Re: Function of Array.filter surprises me — schneik@...
5 messages
2000/04/03
[#2361] crontab — Hugh Sasse Staff Elec Eng <hgs@...>
I want to have a program that may be run between certain times.
11 messages
2000/04/05
[#2375] Marshal: Want string out, but want depth specified? — Hugh Sasse Staff Elec Eng <hgs@...>
@encoded = [Marshal.dump(@decoded, , depth)].pack("m")
7 messages
2000/04/07
[#2378] Re: Marshal: Want string out, but want depth specified?
— matz@... (Yukihiro Matsumoto)
2000/04/07
Hi,
[#2376] Iterator into array — Dave Thomas <Dave@...>
15 messages
2000/04/07
[#2397] Could missing 'end' be reported better? — mrilu <mrilu@...>
I'm not sure one could easily parse, or moreover report, this error better.
5 messages
2000/04/08
[#2404] Re: Iterator into array — Andrew Hunt <andy@...>
>It's still possible to introduce a new syntax for collecting yielded
6 messages
2000/04/08
[#2412] Re: Could missing 'end' be reported better? — h.fulton@...
7 messages
2000/04/09
[#2414] Re: Could missing 'end' be reported better?
— matz@... (Yukihiro Matsumoto)
2000/04/09
Hi,
[#2429] Please join me, I'm Hashing documentation — mrilu <mrilu@...>
This is a story about my hashing ventures, try to bear with me.
5 messages
2000/04/10
[#2459] Precedence question — Dave Thomas <Dave@...>
7 messages
2000/04/12
[#2474] Ruby 1.4.4 — Yukihiro Matsumoto <matz@...>
Ruby 1.4.4 is out, check out:
5 messages
2000/04/14
[#2494] ANNOUNCE : PL/Ruby — ts <decoux@...>
7 messages
2000/04/17
[#2514] frozen behavior — Andrew Hunt <Andy@...>
7 messages
2000/04/19
[#2530] Re: 'in' vs. 'into' — Andrew Hunt <andy@...>
>Hmm, I've not decided yet. Here's the list of options:
6 messages
2000/04/20
[#2535] Default naming for iterator parameters — mrilu <mrilu@...>
I'm back at my computer after some traveling. I know I think Ruby
5 messages
2000/04/20
[#2598] different thread semantics 1.4.3 -> 1.4.4 — hipster <hipster@...4all.nl>
Hi fellow rubies,
4 messages
2000/04/28
[ruby-talk:02609] linux-alpha/ccc / syntax
From:
Wes Nakamura <wknaka@...>
Date:
2000-04-30 09:02:42 UTC
List:
ruby-talk #2609
Hi,
I've been working on getting ruby to compile on linux/alpha using
Compaq's (DEC's) ccc compiler instead of gcc for higher performance.
To get ruby 1.4.4 to compile with ccc, in eval.c line 726 in rb_eval's
prototype, the NODE* must be changed to NODE* volatile; the same for
line 732 in module_setup. I believe this is also the case with 1.5.
Attempting to load a (shared object) module causes an unaligned trap
followed by a segmentation violation. Normally the kernel handles
unaligned accesses gracefully, but in this case it doesn't. I've traced
it to do_entUnaUser in the kernel, which is supposed to handle the
unaligned accesses, and apparently _dl_relocate_object, which appears to
be in libc. (glibc 2.1.1 in this case)
configure --without-gcc sets compilation to use -g. I've determined
that the flags used for the compilation of the modules affects the
loading. Using -O2 instead of -g causes everything to work fine (ruby
itself can still be compiled with -g and everything's okay). I'm not
sure what exactly the relationship is between ccc and egcs (ccc requires
that you have egcs installed), but I would assume that is a bug or some
other kind of incompatibility with ccc or egcs. This is with ccc
version 6.2.9.002 and egcs 1.1.2.
Well, now that I've got a working ccc-compiled ruby, is there a
benchmark (rubystone? - nice name) to compare performance differences
between the ccc and gcc compiled versions?
Also, I've got a syntax question. Using () across multiple lines for
method calls allows you to continue the parameter list without a \.
However, it doesn't work for grouping/precedence.
E.g. you can do:
object.method(arg0,
arg1)
but not:
if (this
|| that)
You *can* do
if (this ||
that)
but I'm wondering if there is a problem with allowing the previous
version to work as well. In python this allows you to avoid using \
quite often.
Wes.