ruby-dev summary 21637-21729

[Takaaki Tateishi]

Hello,

I present you a summary of the ruby-dev mailing list.

[ruby-dev:21639] load() blocks thread scheduling
Tietew posted the following scripts which didn't timeout and didn't
accept Ctrl+C.

-- main.rb --
require 'timeout'
timeout(60) { load 'block.rb' }

--- block.rb
loop { }

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

 

[Paul Brannan]

[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?

Paul

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 21637-21729"

|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?

Plain syntax error in 1.9.x.

matz.

 

[Paul Brannan]

In message "Re: ruby-dev summary 21637-21729"
|So what will the result of the above two lines of code be?

Plain syntax error in 1.9.x.

Is the syntax error because of the first line or because of the second?
I ask because I do this a lot in my code:

s = "this is a string " \
"that I have chosen to break " \
"into multiple lines

I would be happy to switch to using heredocs if there were an easy way
to indent heredocs.

Paul

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 21637-21729"

|Is the syntax error because of the first line or because of the second?

Both. Sequence of strings will no longer be valid.

|I ask because I do this a lot in my code:
|
| s = "this is a string " \
| "that I have chosen to break " \
| "into multiple lines"

How about

s = "this is a string " +
"that I have chosen to break " +
"into multiple lines"
?

matz.

 

[Paul Brannan]

In message "Re: ruby-dev summary 21637-21729"
|
| s = "this is a string " \
| "that I have chosen to break " \
| "into multiple lines"

How about

s = "this is a string " +
"that I have chosen to break " +
"into multiple lines"

This works, but the concatenation is done at run-time instead of at
compile-time.

Paul

 

[Robert Church]

This works, but the concatenation is done at run-time instead of at
compile-time.

Or so you assume. I don't know how Matz will handle this, but there's
no reason concatenation of string constants could not be done at
compile time.

 

[Eric Hodel]

--9Q2l3mYpK16UQ/iv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=20
Or so you assume. I don't know how Matz will handle this, but there's
no reason concatenation of string constants could not be done at
compile time.

You can redefine String#+, so no such optimization must be made at
compile time.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--9Q2l3mYpK16UQ/iv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/qtVWMypVHHlsnwQRAtPlAJ9DCuzf1TwhCsALULpNe8/BK3PC/gCcCjhw
gBjJP9ZU9QLi6bD30tO9TgA=
=LqSQ
-----END PGP SIGNATURE-----

--9Q2l3mYpK16UQ/iv--

 

[gabriele renzi]

il Fri, 7 Nov 2003 07:57:32 +0900, Paul Brannan <[email protected]>
ha scritto::

This works, but the concatenation is done at run-time instead of at
compile-time.

well, this could be meaningful if ruby had a real compiling fase.
And if it had it this could be esailt solved from the compiler (I
think javac does this, for example)

 

[Sean O'Dell]

Hi,

In message "Re: ruby-dev summary 21637-21729"

|Is the syntax error because of the first line or because of the second?

Both. Sequence of strings will no longer be valid.

|I ask because I do this a lot in my code:
|
| s = "this is a string " \
| "that I have chosen to break " \
| "into multiple lines"

How about

s = "this is a string " +
"that I have chosen to break " +
"into multiple lines"
?

My 1 cent: I really wish "" \ style concatenation wouldn't go away.

Sean O'Dell

 

[nobu.nokada]

Hi,

At Fri, 7 Nov 2003 07:57:32 +0900,

This works, but the concatenation is done at run-time instead of at
compile-time.

In 1.8, this is concatenated at compile-time.

s = "this is a string #{ # And you can write
""}that I have chosen to break #{ # comments!
""}into multiple lines"

 

[Joel VanderWerf]

In 1.8, this is concatenated at compile-time.

s = "this is a string #{ # And you can write
""}that I have chosen to break #{ # comments!
""}into multiple lines"

Very cool! It doesn't need the "", though, does it?

irb(main):001:0> "foo#{
irb(main):002:0" }bar"
=> "foobar"

 

[nobu.nokada]

Hi,

At Fri, 7 Nov 2003 10:42:51 +0900,

Very cool! It doesn't need the "", though, does it?

irb(main):001:0> "foo#{
irb(main):002:0" }bar"
=> "foobar"

It needs for compile-time concatenation, because nil.to_s might
be replaced.

$ ruby -rNodeDump -e '"foo#{' -e '}bar"'
NodeDump V0.9

NODE_NEWLINE: [-e:1]
NODE_DSTR: "foo"
NODE_EVSTR:
NODE_STR: "bar"

$ ruby -rNodeDump -e '"foo#{' -e '""}bar"'
NodeDump V0.9

NODE_NEWLINE: [-e:1]
NODE_STR: "foobar"

This optimization is limited to the case #{} ends with a
literal string (and preceding literals without any side
effects)

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 21637-21729"

|My 1 cent: I really wish "" \ style concatenation wouldn't go away.

Why?

matz.

 

[Laurent Sansonetti]

Hi,

Hi,

In message "Re: ruby-dev summary 21637-21729"

|Is the syntax error because of the first line or because of the second?

Both. Sequence of strings will no longer be valid.

|I ask because I do this a lot in my code:
|
| s = "this is a string " \
| "that I have chosen to break " \
| "into multiple lines"

How about

s = "this is a string " +
"that I have chosen to break " +
"into multiple lines"

I would prefer this:

s = "this is a string "
+ "that I have chosen to break "
+ "into multiple lines"

I think it's always better to avoid operators in the end of lines (code
is therefore more readeable).

Same think for this:

if ( expr1...
and expr2...
and expr3... )

# do something
end

But AFAIK && unfortunately, Ruby does not handle this kind of syntax yet.

Matz, what do you think about this?

Thanks,

 

[Tim Bates]

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.

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

 

[Yukihiro Matsumoto]

In message "Re: ruby-dev summary 21637-21729"

|I would prefer this:
|
|s = "this is a string "
| + "that I have chosen to break "
| + "into multiple lines"
|
|I think it's always better to avoid operators in the end of lines (code
|is therefore more readeable).
|
|Same think for this:
|
|if ( expr1...
| and expr2...
| and expr3... )
|
| # do something
|end
|
|But AFAIK && unfortunately, Ruby does not handle this kind of syntax yet.
|
|Matz, what do you think about this?

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?

matz.

 

[Laurent Sansonetti]

|Matz, what do you think about this?

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 `+@' ?)

So it's surely better to keep the current syntax.

 

[Fred Werne]

Hi Laurent!

I would prefer this:

s = "this is a string "
+ "that I have chosen to break "
+ "into multiple lines"

I think it's always better to avoid operators in the end of lines (code
is therefore more readeable).

I like Operators in the following line, too.

But I have no problems with

s = "this is a string " \ # And the reason for this
+ "that I have chosen to break " \ # is to have enough space
+ "into multiple lines" # for comments

Or don't I understand, what you mean?

Fred from Wuppertal, Germany

 

[Sean O'Dell]

Hi,

In message "Re: ruby-dev summary 21637-21729"

|My 1 cent: I really wish "" \ style concatenation wouldn't go away.

Why?

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