He also posted a patch to change the thread. Matz wrote that
it would cause unexpected troubles if we didn’t block other
thread while loading a script.
[ruby-dev:21641] SOAP::StreamError: Illegal media type
SOAP4R’s test suite failed since it required pre-installed SOAP4R
library. Matz suggested that the test suite in ruby should use
not pre-installed libraries but use archived new libraries from
the archive.
[ruby-dev:21678] Problems of testing test/drb on Windows
U. Nakamura showed two opinions about test/drb on Windows as follows.
(a) test/drb/test_drbunix.rb failed if it was executed via
test/runner.rb, since Windows didn’t have Socket::UNIX*.
He thought that such error had better occur when loading
’drb/unix’.
(b) The result of test/drb/test_acl.rb was ‘E’, since the
ruby was compiled without AF_INET6 and IPAddr#ipv6?
caused NameError. He proposed some solutions to avoid
NameError.
[ruby-dev:21679] Proposal: string literal concatenation
Mput proposed a specification which enables us to concatenate
strings using a new line like the following script.
s = "foo1" "bar1"
"foo2" "bar2"
Matz answered that he will discard string literal concatenation.
[ruby-dev:21682] ruby-tk hangs when exception is raised
Akira Yamada received a bug report as a package maintainer of
Debian. The following Ruby/TK script caused a problem that
Ctrl+C was not available. This problem have not been solved yet.
require 'tk'
r = TkRoot.new
b = TkButton.new(r) { text "break me" }
b.command proc {
raise "error!"
}
b.pack
Tk.mainloop
So what will the result of the above two lines of code be?
Paul
···
On Fri, Oct 31, 2003 at 07:01:28AM +0900, Takaaki Tateishi wrote:
[ruby-dev:21679] Proposal: string literal concatenation
Mput proposed a specification which enables us to concatenate
strings using a new line like the following script.
s = "foo1" "bar1"
"foo2" "bar2"
Matz answered that he will discard string literal concatenation.
In message “Re: ruby-dev summary 21637-21729” on 03/11/06, Paul Brannan pbrannan@atdesk.com writes:
On Fri, Oct 31, 2003 at 07:01:28AM +0900, Takaaki Tateishi wrote:
[ruby-dev:21679] Proposal: string literal concatenation
Mput proposed a specification which enables us to concatenate
strings using a new line like the following script.
s = "foo1" "bar1"
"foo2" "bar2"
Matz answered that he will discard string literal concatenation.
So what will the result of the above two lines of code be?
Because of Ruby’s line-based syntax, Ruby guesses that if you have hit
the end of the line and the line as a whole is valid, then you have
finished that statement. This is essentially a limitation of the parser.
There are two ways around this - require statements to end with a
special character (eg a semicolon) so that if we get to the end of the
line and haven’t found that character yet we know the statement isn’t
finished, or implement look-ahead in the parser to take a look at the
next line and see if it, when combined with the current line, is a valid
statement as a whole. This is a lot more difficult; it involves
look-ahead and creates a whole new family of ambiguities; e.g. what do
you do if the next line creates a valid statement when combined with
this line, and also the two lines are valid statements by themselves? So
if the alternative is to require every statement to end in a semicolon
(noooo!) which takes a significant chunk out of the beauty of the
language, I must say that I prefer the way it is done now - and the same
applies to most of Matz’s decisions, which is why I love this language.
Tim Bates
···
On Fri, Nov 07, 2003 at 06:04:47PM +0900, Laurent Sansonetti wrote:
I think it’s always better to avoid operators in the end of lines (code
is therefore more readeable).
But AFAIK && unfortunately, Ruby does not handle this kind of syntax yet.
There’s always trade-off. Newline sensitive syntax do not allow
line concatenation by operator at the beginning of a line, e.g. how
can we distinguish
s = "this is a string "
+ "that I have chosen to break "
+ “into multiple lines”
which is a single assignment statement, from
s = "this is a string "
"that I have chosen to break "
“into multiple lines”
an assignment followed by two unary plus expression?
Because the String class does not provide the `+@’ method?
But as Tim pointed out, since Ruby seems to be parsed line by line, it
can be really hard to implement this. And of course, it can break the
current syntax (if we replace strings with integers, how the parser
should react since integers have `+@’ ?)
Well, isn’t “” \ load/compile-time concatenation and “” + run-time
concatenation? Right now, there’s code that uses “” \ so my first reason is
compatibility. Secondly, when (if?) Rite pre-compiles into bytecode, “” \
probably should be interpreted to mean “just slap them together” while “” +
should be “concatenate using the current implementation for the + operator”
(meaning it’s overridable, whereas the former is not).
Sean O'Dell
···
On Friday 07 November 2003 12:11 am, Yukihiro Matsumoto wrote:
Hi,
In message “Re: ruby-dev summary 21637-21729” > > on 03/11/07, “Sean O’Dell” sean@celsoft.com writes:
My 1 cent: I really wish “” \ style concatenation wouldn’t go away.
