[#3479] Missing .document files for ext/ libraries — Brian Candler <B.Candler@...>
The ri documentation for zlib, strscan and iconv doesn't get built by 'make
On Wednesday, October 6, 2004, 11:18:33 PM, Brian wrote:
Just been building CVS head and was surprised at how long it now takes
On Die, 2004-10-19 at 16:47, Dave Thomas wrote:
[#3484] compilation error — Wybo Dekker <wybo@...>
In the current cvs I get, on make:
On Mon, Oct 11, 2004 at 07:21:28AM +0900, Wybo Dekker wrote:
[#3486] Location of missing end — Markus <markus@...>
Over the past week or so there has been a thread on ruby-talk ("Quality
[#3492] Re: ANN: Free-form-operators patch — Markus <markus@...>
> In message "Re: ANN: Free-form-operators patch"
Hi,
On Mon, 2004-10-11 at 16:16, Yukihiro Matsumoto wrote:
On Monday 11 October 2004 08:09 pm, Markus wrote:
Hi,
On Monday 11 October 2004 09:38 pm, Yukihiro Matsumoto wrote:
[#3517] Kernighan & Richie ---> prototypes ? — Johan Holmberg <holmberg@...>
[#3523] segfault in ruby-1.8.2p2 — Brian Candler <B.Candler@...>
I can reliably get ruby-1.8.2p2 to segfault on my system, which is:
[#3538] TCPSocket.new(host, port).readline hangs on Windows — Jos Backus <jos@...>
With recent CVS versions (both ruby_1_8 branch and HEAD), the following
Hi,
On Wed, Oct 20, 2004 at 07:43:31AM +0900, Yukihiro Matsumoto wrote:
[#3551] ubygems missing? — "trans. (T. Onoma)" <transami@...>
I've never been one for compiling code, so I bet this is a simple fix, but
[#3561] 1.8.2 - what can we do to help? — Dave Thomas <dave@...>
Folks:
Hi,
On Oct 26, 2004, at 9:55 PM, Yukihiro Matsumoto wrote:
On Wed, 2004-10-27 at 06:11, Francis Hwang wrote:
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wednesday 27 October 2004 08:51 am, Yukihiro Matsumoto wrote:
[#3573] Small issues with Symbols — Florian Gro<florgro@...>
Moin!
[#3590] Re: Bug tracking project on RubyForge... — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
Sure...
Hi,
[#3596] Float and Bignum — "trans. (T. Onoma)" <transami@...>
Hi all,
Hi,
On Thursday 28 October 2004 02:00 am, Yukihiro Matsumoto wrote:
[#3600] Ruby Vs. ... might find comparison of interest. — "trans. (T. Onoma)" <transami@...>
trans. (T. Onoma) wrote:
[#3610] Tadayoshi Funaba's Date2 — "trans. (T. Onoma)" <transami@...>
Tadayoshi Funaba has a lib on RAA called Date2, the additions/improvements to
Hi --
On Friday 29 October 2004 07:03 am, David A. Black wrote:
[#3611] Memory leak in ruby_1_8 — David Ross <dross@...>
Hello,
[#3617] TEST BUG — noreply@...
Bugs item #1000, was opened at 2004-10-28 09:12
[#3638] Ruby, pthreads, and HPUX 11 — Jamis Buck <jgb3@...>
I'm finally trying to delve into the issue of Ruby not compiling
>>>>> "J" == Jamis Buck <jgb3@email.byu.edu> writes:
[#3655] autoload — Joel VanderWerf <vjoel@...>
Location of missing end
Over the past week or so there has been a thread on ruby-talk ("Quality
of error messages") about the fact that a missing end is generally not
detected until the whole file has been parsed. This makes it difficult
to find the location of the error.
I had suggested that it might be possible to make a good guess based on
a very liberal interpretation of common indentation styles. I have a
patch which implements this at
http://www.reality.com/roberts/markus/software/ruby/location_of_missing_end/missing_end_patch.0.1.diff
The basic strategy is very simple:
* Note the indentation of lines as they are read in
* Note the indentation of block opening tokens
(begin/case/class/def/if...) on a small stack
* If a new block is opened at the same indentation as or any
reserved word appears at a lesser indentation than the line
containing the starting token of the nearest enclosing block,
note the line number in a small (4 items) list.
* If (and only if) a parsing error occurs, print (in addition to
the normal "parse error" message) the locations of the first
four indentation anomalies of each type.
This should not in any way change the behavior of programs that compile
correctly; it does not impose or assume any particular indentation style
or generate any messages until and unless parsing fails, at which point
it produces something like:
mqr_mesh.rb:172: warning: Possible missing 'end' or '}' near line 125
mqr_mesh.rb:172: warning: Possible missing 'end' or '}' near line 143
mqr_mesh.rb:172: parse error
(in this particular case the missing end belonged on line 124). In
rather ad hoc testing (randomly deleting 'end's and '}' from sample
programs), at least one of the listed lines (up to a maximum of eight
are listed) was within two lines of the deleted token. In almost all
cases, it was the first of the listed lines.
It seems to me that this could be useful (at least, there seemed to
considerable interest on ruby-talk, and it would have saved me some head
scratching on more than one occasion) and I think this is the least
intrusive way of addressing the issue.
Testing with some debugging messages added showed that, in all of the
ruby code included with the ruby distribution, only seven lines of code
failed to follow the liberal interpretation of "normal indentation" used
in the patch. The worst case is that (rarely, it appears) the patch
might suggest "Possible missing ends" where there were none.
Thought? Comments? Aberrant test cases?
-- Markus