Hard coded newline characters

ruby-talk
1

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro that
outputs $\ (or perhaps $,) character. It seems to me that the most of
the places where ruby programs write directly to stdout are not places
where speed is of the essense (e.g., printing stack traces.)

Given that this is the case, it appears that setting $\ to '\r\n’
doesn’t changed the output of routines that utilize a c puts, fputs,
printf, or printf variant to write text to stdout. Specifically, I’d
like to control the printout of exception backtraces by changing $.
I’d like to do this because I am using ncurses, and the backtraces of
exceptions do not print correctly in ncurses windows (or pads); '\r\s’
is needed to do this in ncurses, since ‘\n’ simply causes the lines to
step down across the screen as follows

/libtest.rb:100:in puts': Interrupt from test.rb:11 from test.rb:10:intimes’

As a work around, I’ve dabbled a bit with doing traps in order to issue
an endwin before the exception gets printed, but I have not found good
documentation on how to do to traps, and it appears impossible to raise
or throw an exception within a trap proc block. Any quick workaround
that anyone could provide would be appreciated.

···

David King Landrith
(w) 617.227.4469x213
(h) 617.696.7133

One useless man is a disgrace, two
are called a law firm, and three or more
become a congress – John Adams

public key available upon request

2

Hi,

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character. It seems to me that the
most of the places where ruby programs write directly to stdout are
not places where speed is of the essense (e.g., printing stack traces.)

Interesting but I doubt its necessarity and worthfulness.

As a work around, I’ve dabbled a bit with doing traps in order to
issue an endwin before the exception gets printed, but I have not
found good documentation on how to do to traps, and it appears
impossible to raise or throw an exception within a trap proc block.

begin

codes with ncurses

ensure
Ncurses.endwin
end

···

At Mon, 31 Mar 2003 06:39:01 +0900, David King Landrith wrote:

–
Nobu Nakada

3

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character. It seems to me that the
most of the places where ruby programs write directly to stdout are
not places where speed is of the essense (e.g., printing stack
traces.)

Interesting but I doubt its necessarity and worthfulness.

Likewise with your reply.

As a work around, I’ve dabbled a bit with doing traps in order to
issue an endwin before the exception gets printed, but I have not
found good documentation on how to do to traps, and it appears
impossible to raise or throw an exception within a trap proc block.

begin

codes with ncurses

ensure
Ncurses.endwin
end

I should have been clear that I want to have a trap or something in a
file that can simply be required, so that I don’t have to repeat the
same begin/ensure/end stuff in every program. I thought this was
obvious because I mentioned that I have tried to use traps, but
evidently it wasn’t.

For example, requiring a file that contains the following trap ensures
that you don’t have to reset your terminal in the event of an untimely
exit:

trap 0, proc {
endwin
}

This, however, prints the staggered stack traces, which is what I’d
like to fix. Staggered stack traces are, to my mind, preferable to
having to do wrap every piece of code in a begin/ensure/end wrapper.

My goal is to make the use of ncurses completely transparent–even more
transparent than putting the begin/ensure/end blocker in a method that
yields the WINDOW object. It’s not difficult, for example, to redo (in
the same file that contains the trap code) the Kernel screen output
methods (e.g., puts, print, etc.) accommodate ncurses, and doing so
makes the fact that ncurses is being used transparent.

I am going to be gradually introducing ncurses based terminal
capabilities to series of large and quite complex programs that are
entirely readline/puts/printf based, and re-writing the UI layer all at
once from the top isn’t a viable alternative. Thus, the change will be
gradual, and the initial inclusion of ncurses must not require
modification of the existing code.

···

On Sunday, March 30, 2003, at 08:06 PM, nobu.nokada@softhome.net wrote:

David King Landrith
(w) 617.227.4469x213
(h) 617.696.7133

One useless man is a disgrace, two
are called a law firm, and three or more
become a congress – John Adams

public key available upon request

4

David King Landrith wrote:

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character. It seems to me that the
most of the places where ruby programs write directly to stdout are
not places where speed is of the essense (e.g., printing stack traces.)

Interesting but I doubt its necessarity and worthfulness.

Likewise with your reply.

Ouch.
I’m sure antagonizing people will really make them want to help you…

I am going to be gradually introducing ncurses based terminal
capabilities to series of large and quite complex programs that are
entirely readline/puts/printf based, and re-writing the UI layer all at
once from the top isn’t a viable alternative. Thus, the change will be
gradual, and the initial inclusion of ncurses must not require
modification of the existing code.

And what is so hard about having a stub file that contains

begin
load ‘real-main-program-file.rb’
rescue

…

ensure
endwin
end

If that doesn’t work, you could continue insulting people until they
spontaneously decide to change their code just for you… (most likely
by using \n wherever possible) :stuck_out_tongue:

···

On Sunday, March 30, 2003, at 08:06 PM, nobu.nokada@softhome.net wrote:

5

begin
   load 'real-main-program-file.rb'
rescue
   # ...
ensure
   endwin
end

or perhaps

   at_exit { endwin }

Guy Decoux

6

I’m afraid I’m on David’s side with this one. If I post here saying, “I
need to do bla bla bla,” I’m not helped by someone who posts back saying,
“That’s interesting, but I don’t think it’s necessary or worthwhile.” If
they don’t understand why I need to do something and they want to know,
they can ask rather than casting aspersions.

Certainly it is often the case that there is a better way to do what
someone thinks they want to do, especially if they are a beginner, as I
still am with Ruby. But the way to handle that is to ask the question I’ve
seen asked innumerable times in this and similar groups: “What is it
you’re trying to do, ultimately?”

-rest snipped-

···

On Mon, 31 Mar 2003 15:03:40 +0000, Julian Snitow wrote:

David King Landrith wrote:

On Sunday, March 30, 2003, at 08:06 PM, nobu.nokada@softhome.net wrote:

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character. It seems to me that the
most of the places where ruby programs write directly to stdout are
not places where speed is of the essense (e.g., printing stack
traces.)

Interesting but I doubt its necessarity and worthfulness.

Likewise with your reply.

Ouch.
I’m sure antagonizing people will really make them want to help you…

–
Tim Kynerd Sundbyberg (småstan i storstan), Sweden tkynerd@spamcop.net
Sunrise in Stockholm today: 6:22
Sunset in Stockholm today: 19:22
My rail transit photos at http://www.kynerd.nu

7

or perhaps

at_exit { endwin }

This is exactly the type of elegant solution that I’m looking for.
Unfortunately, this behaves exactly the same as trap 0, proc { endwin
}. (What is the difference between at_exit and trap 0?)

Interesting but I doubt its necessarity and worthfulness.
Likewise with your reply.
Ouch.
I’m sure antagonizing people will really make them want to help
you…

Fair enough. I didn’t intend to be antagonistic, but rather to answer
a flip response in kind. This mailing list is sometimes frustrating
because of the preponderance of know-it-all types offering solutions
that (a) imply you know nothing about the Ruby and (b) --here’s the
rub-- don’t even work.

I am going to be gradually introducing ncurses based terminal
capabilities to series of large and quite complex programs that are
entirely readline/puts/printf based, and re-writing the UI layer all
at once from the top isn’t a viable alternative. Thus, the change
will be gradual, and the initial inclusion of ncurses must not
require modification of the existing code.

And what is so hard about having a stub file that contains

begin
load ‘real-main-program-file.rb’
rescue

…

ensure
endwin
end

If that doesn’t work, you could continue insulting people until they
spontaneously decide to change their code just for you… (most likely
by using \n wherever possible) :stuck_out_tongue:

Clever, but I must decline to answer your question about “what makes it
some hard,” because its entirely beside the point. The issue isn’t
whether it’s so hard. I would prefer to use some kind of trap if its
available. My question is whether something like this is, in fact,
available? If not, then a simple “NO” will do.

···

On Monday, March 31, 2003, at 10:27 AM, ts wrote:
On Monday, March 31, 2003, at 10:15 AM, Julian Snitow wrote:

David King Landrith
(w) 617.227.4469x213
(h) 617.696.7133

One useless man is a disgrace, two
are called a law firm, and three or more
become a congress – John Adams

public key available upon request

8

This is exactly the type of elegant solution that I'm looking for.
Unfortunately, this behaves exactly the same as trap 0, proc { endwin
}. (What is the difference between at_exit and trap 0?)

You can have different at_exit

pigeon% ruby -e 'at_exit { p 1 }; at_exit { p 2 }'
2
1
pigeon%

Guy Decoux

9

Tim Kynerd wrote:

David King Landrith wrote:

[snip]

Interesting but I doubt its necessarity and worthfulness.

Likewise with your reply.

Ouch.
I’m sure antagonizing people will really make them want to help you…

I’m afraid I’m on David’s side with this one. If I post here saying, “I
need to do bla bla bla,” I’m not helped by someone who posts back saying,
“That’s interesting, but I don’t think it’s necessary or worthwhile.” If
they don’t understand why I need to do something and they want to know,
they can ask rather than casting aspersions.

Certainly it is often the case that there is a better way to do what
someone thinks they want to do, especially if they are a beginner, as I
still am with Ruby. But the way to handle that is to ask the question I’ve
seen asked innumerable times in this and similar groups: “What is it
you’re trying to do, ultimately?”

-rest snipped-

I can agree with that. The difference is that this was a request for
changes in the way ruby itself does things, in which case it is
incumbent upon the requestor to justify the proposed changes.

Whether or not one is “in the right” is immaterial; belligerence rarely
inspires others to write code on one’s behalf.

···

On Mon, 31 Mar 2003 15:03:40 +0000, Julian Snitow wrote:

On Sunday, March 30, 2003, at 08:06 PM, nobu.nokada@softhome.net wrote:

10

This is exactly the type of elegant solution that I'm looking for.
Unfortunately, this behaves exactly the same as trap 0, proc { endwin

And with

   $stderr = File.new("/dev/null", "w") # or the windows equivalent
   at_exit do
      if $!
         # do what you want with the error message
      end
      endwin
   end

Guy Decoux

11

I’m sure antagonizing people will really make them want to help
you…

Fair enough. I didn’t intend to be antagonistic, but rather to answer
a flip response in kind. This mailing list is sometimes frustrating
because of the preponderance of know-it-all types offering solutions
that (a) imply you know nothing about the Ruby and (b) --here’s the
rub-- don’t even work.

Wow. I have to disagree. Time no longer allows me to read every message on
every topic, but it’s rare that I see any arrogance, or “know-it-all types”
offering wrong information.

More typically I read messages from newcomers saying how friendly and helpful
they find the list.

Still, I’ve had people E-mail me off-list concerning perceived slights,
and largely it was due to cultural differences (e.g., English as a second
language), not intent.

James Britt

12

David King Landrith wrote:

or perhaps

at_exit { endwin }

This is exactly the type of elegant solution that I’m looking for.
Unfortunately, this behaves exactly the same as trap 0, proc { endwin
}. (What is the difference between at_exit and trap 0?)

Interesting but I doubt its necessarity and worthfulness.

Likewise with your reply.

Ouch.
I’m sure antagonizing people will really make them want to help you…

Fair enough. I didn’t intend to be antagonistic, but rather to answer a
flip response in kind.

Always a temptation; rarely worth it in practice… :wink:

I’d personally have given the benefit of the doubt by assuming that the
original poster meant to question the necessity of changing ruby itself
rather than finding an alternative solution.

This mailing list is sometimes frustrating
because of the preponderance of know-it-all types offering solutions
that (a) imply you know nothing about the Ruby and (b) --here’s the
rub-- don’t even work.

grin

Here’s my rule of thumb: when I’m posting something that I believe will
work, but haven’t tested, I’ll say something to the effect of “why not
try something like…”, to imply that the following snippet should be
read and adapted, or taken as an idea, not necessarily applied verbatim.

When I promise to eat my hat, however… ;-D

···

On Monday, March 31, 2003, at 10:27 AM, ts wrote:
On Monday, March 31, 2003, at 10:15 AM, Julian Snitow wrote:

13

Interesting but I doubt its necessarity and worthfulness.
Likewise with your reply.
Ouch. I’m sure antagonizing people will really make them want
to help you…
Fair enough. I didn’t intend to be antagonistic, but rather to
answer a flip response in kind.

David,

I seriously doubt that Nobu was being flip. English isn’t his native
language, and in my ~9 months of reading ruby-talk, I haven’t really
noticed him being “flip” toward anyone. I think that he was being
honest with his opinion regarding the effort vs. payoff.

-austin
– Austin Ziegler, austin@halostatue.ca on 2003.03.31 at 13:05:53

14

Works perfectly! Thanks.

···

On Monday, March 31, 2003, at 11:21 AM, ts wrote:

This is exactly the type of elegant solution that I’m looking for.
Unfortunately, this behaves exactly the same as trap 0, proc {
endwin

And with

$stderr = File.new(“/dev/null”, “w”) # or the windows equivalent
at_exit do
if $!
# do what you want with the error message
end
endwin
end

Guy Decoux

David King Landrith
(w) 617.227.4469x213
(h) 617.696.7133

One useless man is a disgrace, two
are called a law firm, and three or more
become a congress – John Adams

public key available upon request

15

Tim Kynerd wrote:

-snip-

Ouch.
I’m sure antagonizing people will really make them want to help
you…

I’m afraid I’m on David’s side with this one. If I post here saying, “I
need to do bla bla bla,” I’m not helped by someone who posts back
saying, “That’s interesting, but I don’t think it’s necessary or
worthwhile.” If they don’t understand why I need to do something and
they want to know, they can ask rather than casting aspersions.

Certainly it is often the case that there is a better way to do what
someone thinks they want to do, especially if they are a beginner, as I
still am with Ruby. But the way to handle that is to ask the question
I’ve seen asked innumerable times in this and similar groups: “What is
it you’re trying to do, ultimately?”

-rest snipped-

I can agree with that. The difference is that this was a request for
changes in the way ruby itself does things, in which case it is
incumbent upon the requestor to justify the proposed changes.

Whether or not one is “in the right” is immaterial; belligerence rarely
inspires others to write code on one’s behalf.

I reread the original post and I cannot honestly see that the original
poster was asking for this.

The last sentence of that post is:
“Any quick workaround that anyone can provide would be appreciated.”

That certainly isn’t asking for changes in the way Ruby works. Nor can I
find anything in the rest of the post that asks for that. There’s a big
difference between saying “I don’t like the way Ruby works in this regard;
is there a workaround?” and “I don’t like the way Ruby works in this
regard; [please] change it.”

Nor do I see anything wrong with responding to belligerence with
belligerence. Given that initial response, I didn’t see much reason to
expect help from that particular quarter.

···

On Mon, 31 Mar 2003 16:00:29 +0000, Julian Snitow wrote:

On Mon, 31 Mar 2003 15:03:40 +0000, Julian Snitow wrote:

–
Tim Kynerd Sundbyberg (småstan i storstan), Sweden tkynerd@spamcop.net
Sunrise in Stockholm today: 6:22
Sunset in Stockholm today: 19:22
My rail transit photos at http://www.kynerd.nu

16

Tim Kynerd wrote:

Tim Kynerd wrote:

[snip]

Whether or not one is “in the right” is immaterial; belligerence rarely
inspires others to write code on one’s behalf.

I reread the original post and I cannot honestly see that the original
poster was asking for this.

The last sentence of that post is:
“Any quick workaround that anyone can provide would be appreciated.”

Hmm… must’ve missed that one…

That certainly isn’t asking for changes in the way Ruby works. Nor can I
find anything in the rest of the post that asks for that. There’s a big
difference between saying “I don’t like the way Ruby works in this regard;
is there a workaround?” and “I don’t like the way Ruby works in this
regard; [please] change it.”

Nor do I see anything wrong with responding to belligerence with
belligerence. Given that initial response, I didn’t see much reason to
expect help from that particular quarter.

shrug I guess it depends on how you interpreted the initial response.

···

On Mon, 31 Mar 2003 16:00:29 +0000, Julian Snitow wrote:

On Mon, 31 Mar 2003 15:03:40 +0000, Julian Snitow wrote:

17

Tim Kynerd wrote:

Tim Kynerd wrote:

[snip]

Whether or not one is “in the right” is immaterial; belligerence rarely
inspires others to write code on one’s behalf.

I reread the original post and I cannot honestly see that the original
poster was asking for this.

The last sentence of that post is:
“Any quick workaround that anyone can provide would be appreciated.”

Hmm… must’ve missed that one…

:slight_smile:

That certainly isn’t asking for changes in the way Ruby works. Nor can I
find anything in the rest of the post that asks for that. There’s a big
difference between saying “I don’t like the way Ruby works in this
regard; is there a workaround?” and “I don’t like the way Ruby works in
this regard; [please] change it.”

Nor do I see anything wrong with responding to belligerence with
belligerence. Given that initial response, I didn’t see much reason to
expect help from that particular quarter.

shrug I guess it depends on how you interpreted the initial response.

I guess so. I found it very rude and felt a rude response was entirely in
order.

Best regards,

···

On Mon, 31 Mar 2003 17:30:00 +0000, Julian Snitow wrote:

On Mon, 31 Mar 2003 16:00:29 +0000, Julian Snitow wrote:

On Mon, 31 Mar 2003 15:03:40 +0000, Julian Snitow wrote:

–
Tim Kynerd Sundbyberg (småstan i storstan), Sweden tkynerd@spamcop.net
Sunrise in Stockholm today: 6:22
Sunset in Stockholm today: 19:22
My rail transit photos at http://www.kynerd.nu

18

Whether or not one is “in the right” is immaterial; belligerence rarely
inspires others to write code on one’s behalf.

I reread the original post and I cannot honestly see that the original
poster was asking for this.

The last sentence of that post is:
“Any quick workaround that anyone can provide would be appreciated.”

Hmm… must’ve missed that one…

To be fair, Nobu answered the question in two parts. I didn’t
take his first part answer–the one regarded by some as flip–
as anything more than his concise appraisal of going through
all the ruby modules to accommodate the change implied by:

David King Landrith wrote:

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character.

Nobu’s reply, to me, read like he was saying it was an interesting
observation, but didn’t seem beneficial enough to undertake.

shrug I guess it depends on how you interpreted the initial response.

I guess so. I found it very rude and felt a rude response was entirely in
order.

I’m with Austin on this. I think it was a misperception…
Nobu is one of the few posters on ruby-talk whose messages I
read specifically because he posted - regardless of whether I’m
following the thread - because usually his messages are extremely
authoritative and informative… If that didn’t happen this time
around, I’m sure we can chalk it up as some kind of rare
exception, and certainly not deliberate… :slight_smile:

Regards,

Bill

19

Hi,

···

At Tue, 1 Apr 2003 04:46:47 +0900, Bill Kelly wrote:

To be fair, Nobu answered the question in two parts. I didn’t
take his first part answer–the one regarded by some as flip–
as anything more than his concise appraisal of going through
all the ruby modules to accommodate the change implied by:
David King Landrith wrote:

There are a surprising number of ruby source files that have newline
(\n) characters hardcoded as the line terminator–it appears that way
more than half of the files do. Shouldn’t these be set to a macro
that outputs $\ (or perhaps $,) character.

Nobu’s reply, to me, read like he was saying it was an interesting
observation, but didn’t seem beneficial enough to undertake.

Thank you for better explanation of my intention than me, and
apologize the rudeness of the first reply. I’ll write more
carefully.

–
Nobu Nakada

20

Wow, things almost got intense here. I’d like to add my two bits here
because I think it’s worth pointing out that Ruby has a community with a
rather peculiar synthesis.
Most of the open source projects I’ve looked in from time to time tend
to have a more or less homogeneous community. To be honest it’s the
first time I have had any contact with japanese people (even if it’s
only reading stuff they wrote). There’s one thing that I noticed though:
They’re language is clipped, concise, abrupt to the point where an
english native speaker would consider it rude. Most non-native english
speakers would be used to the american (or - even worse - british way)
of speaking which tends to add a bit more sauce to friendly (or
authoritative) explanations.
And without being rude I have to say some posts in this list have to be
read twice - I guess most of us non-native speakers tend to think in our
own languages and translate literaly - japanese just does not translate
directly into english. Neither does arab, greek or hindi by the way.
Keeping that in mind helped me a lot.
Sorry for the OT, but it’s such a great thing to be able to peek into
another culture and way of thinking and find common ground and share
ideas, code and knowledge, that I hate seeing misunderstanding like this
spoil the mood. Especially at this point in time…
Keep on coding.
V.-

···

nobu.nokada@softhome.net wrote:

Thank you for better explanation of my intention than me, and
apologize the rudeness of the first reply. I’ll write more
carefully.

The mind is like a parachute. If it doesn’t open, you’re meat.

–
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.