[#105450] [Ruby master Feature#18228] Add a `timeout` option to `IO.copy_stream` — "byroot (Jean Boussier)" <noreply@...>
SXNzdWUgIzE4MjI4IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku
11 messages
2021/09/27
[ruby-core:105309] [Ruby master Feature#18159] Integrate functionality of dead_end gem into Ruby
From:
"mame (Yusuke Endoh)" <noreply@...>
Date:
2021-09-16 15:14:18 UTC
List:
ruby-core #105309
Issue #18159 has been updated by mame (Yusuke Endoh).
In today's dev meeting, we discussed this. Basically, no one was opposed to=
the concept. But some concerns were discussed.
@ko1 and @knu were concerned about whether the heuristic algorithm was matu=
re enough. If dead_end prints a misguided summary, it may rather confuse us=
ers. They wanted to take an experimental period after dead_end is integrate=
d to the ruby core. There are only three months until Ruby 3.1 release, so =
they suggested to try the integration towards Ruby 3.2.
@nobu and I briefly read the source code, and had some concerns about the i=
mplementation details:
* Currently, there are no good way to allow dead_end to hook a syntax error=
and extend its message. The redefinition of `Kernel#require` is never a pr=
eferable way. (discussed later)
* The implementation uses timeout, five seconds by default. The heuristic a=
lgorithm may take so long time?
* The gem includes "exe/dead_end" command. Should it be shipped with the ru=
by tarball, too?
* dead_end seems to extend NoMethodError to show a code snippet where the e=
rror occurs (if it is not running in production?). Does this conflict with =
error_highlight?
If dead_end is integrated to the core, we want to avoid the redefinition of=
`Kernel#require` and `require_relative`. It does not work well against an =
syntax error of an entrypoint file (a file passed the ruby interpreter). Bu=
t unfortunately, there is no good API for the feature. `did_you_mean` and `=
error_highlight` extend the error message of NameError by defining `NameErr=
or#message`. It would be good if dead_end can do the same (define `SyntaxEr=
ror#message`), but unfortunately it does not work because the current parse=
r outputs an error message directly to tty, not via `SyntaxError#message`. =
@nobu is now trying to sort it out to allow the following API design. @schn=
eems What do you think?
```
class SyntaxError
attr_reader :file_path # the file path that caused this syntax error
def message
dead_end_error_message =3D DeadEnd.call(source: File.read(file_path), .=
..)
"#{ super }\n\nDeadEnd: Unmatched `end` detected ..." + dead_end_error_=
message
end
end
```
----------------------------------------
Feature #18159: Integrate functionality of dead_end gem into Ruby
https://bugs.ruby-lang.org/issues/18159#change-93719
* Author: duerst (Martin D=FCrst)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.1
----------------------------------------
Missing 'end' errors are difficult to fix. We should integrate the function=
ality of the dead_end gem (https://github.com/zombocom/dead_end) into Ruby =
similar to how we integrated did_you_mean. It would greatly help programmin=
g Ruby, in particular for beginners.
See also Ruby Kaigi Takeout 2021 talk by Richard Schneeman https://rubykaig=
i.org/2021-takeout/presentations/schneems.html.
-- =
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>