Ruby-Nuby forum

[ts]

Z> Please ignore...i realized I was passing in a nonexistent directory.

I hope that you have seen that ruby will call the method #d in Dir.new()
if `d' was not previously seen as a local variable


Guy Decoux

 

[Zach Dennis]

Z> Zach Dennis wrote:




Z> Please ignore...i realized I was passing in a nonexistent directory.

I hope that you have seen that ruby will call the method #d in Dir.new()
if `d' was not previously seen as a local variable


Guy Decoux

Yeah, I learned that the hard way , I am initializing d to nil just
above it....but while we're on this topic I have another order of
operations question.....It involves the && in a conditional statement

d = nil
dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) )

I cannot get this statement to work either, and I have tried flip
flopping the conditions around, but it always complains when I don't
pass in a command line argument. If $* is an empty array shouldn't Ruby
test the first condition and see that it is false, then quit and do not
test the second condition?

Thanks,

Zach

 

[gabriele renzi]

gabriele renzi ha scritto:

I agree on the 'so it they will come', not on the 'you won't get valid

^^
should be 'do'

 

[ts]

Z> d = nil
Z> dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) )

I don't have this problem


svg% ruby -e 'd=nil; dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) ); p dir'
nil
svg%

svg% ruby -e 'd=nil; dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) ); p dir' ruby
#<Dir:0x4009a13c>
svg%



Guy Decoux

 

[Zach Dennis]

Z> d = nil
Z> dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) )

I don't have this problem


svg% ruby -e 'd=nil; dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) ); p dir'
nil
svg%

svg% ruby -e 'd=nil; dir = Dir.new( d ) if( $*.length > 0 && File.directory?( d=$*.shift ) ); p dir' ruby
#<Dir:0x4009a13c>
svg%



Guy Decoux

You're right...I must have had a typo when i was trying earlier...but it
does work when everything is typed in correctly Thanks Guy,

Zach

 

[James Edward Gray II]

your second accessment is what I meant.

Not quite. See below...

ex.

- I sent email to ruby.newprogrammers, it goes to that
list only

The majority here has expressed a strong desire to see what goes on in
any Nuby forum, so this doesn't seem like the way to go.

My suggestion was that ALL Nuby messages be moved to Ruby Talk and gain
a [NUBY] if needed. That seems to keep Ruby Talk in the loop, as many
have requested. Plus, if anyone isn't interested in the Nuby list
traffic it's trivial to filter out.

- I send another one with "[RT] help me" to
ruby.newprogrammers, it goes to the Ruby-talk list as
well

This seems wrong to me, simply because it requires intimate knowledge
of how the messages are handled. The people of this list have asked to
stay informed and Nubies want help from those in the know, so it seems
this should be the default behavior.

- I send emails all day to ruby-talk, they stay there,
if I post a reply to one which is prefixed by [RT], it
goes to the ruby.newprogrammers list

This really confuses me. Posting to Ruby Talk with [RT] (presumably
short for "Ruby Talk") sends the message to Ruby Nuby? That doesn't
make sense to me.

It seems like 90% of the messages that are sent to Ruby Talk and need
to be forwarded are going to be replies to posts that came from there
with answers to their questions. With the above procedures in place,
those replies should have a [NUBY] in their subject, so the default
behavior should be to move those messages across.

The special cases are that a Ruby Talk response may not need to go back
(I expect this would be pretty rare) or a Ruby Talk post should also
appear on the Nuby list. Adding and removing the [NUBY] handles both
of these, as needed.

This keeps all the tricky cases handled on the Ruby Talk side, which
seems best. Well, those are my thoughts, at any rate.

James Edward Gray II

 

[James Britt]

The majority here has expressed a strong desire to see what goes on in
any Nuby forum, so this doesn't seem like the way to go.

Well, I not so sure a majority of people on this list have voiced *any*
opinion, let alone "expressed a strong desire to see what goes on in
any Nuby forum."

My suggestion was that ALL Nuby messages be moved to Ruby Talk and gain
a [NUBY] if needed. That seems to keep Ruby Talk in the loop, as many
have requested. Plus, if anyone isn't interested in the Nuby list
traffic it's trivial to filter out.

Some comments:

* It's trivial to filter out [NUBY], but as I'll be doing the filtering
after messages are downloaded, it's still traffic. Might be small,
probably won't matter to me, but might be an issue for some.

* Essentially, doing this means that everyone subscribed to ruby-talk
becomes subscribed to nuby-talk. So, why not just post to ruby-talk with
[NUBY] in the subject, and tell nubies to filter out anything that
doesn't have that string?

* If one of the motivations for a separate forum is to protect nubies
from the hordes on ruby-talk (i.e., to avoid overly technical responses
or derisive comments or whatever is the imagined behavior), then having
Nuby messages on ruby-talk breaks that barrier.

I suggest just starting a separate forum, whatever it may be, then see
if in fact anyone has a problem keeping up or staying in touch. And, if
and when there seems to be a problem, then go look for a solution.

But, for now, I'm going to wave the buzz-word wand and declare YAGNI.

Go grab PHPNuke or something, start a web site, and tell newbies that
they are invited to help build a pure-Ruby bulletin board package. Eat
your own dog food. Learn by doing, make mistakes together, track what
issues newcomers have, document the learning process. Archive old code
so that people can better understand how the thinking process evolves.

And in any event, have fun.

James

 

[Bill Kelly]

- I sent email to ruby.newprogrammers, it goes to that
list only

The majority here has expressed a strong desire to see what goes on in
any Nuby forum, so this doesn't seem like the way to go.

My suggestion was that ALL Nuby messages be moved to Ruby Talk and gain
a [NUBY] if needed. That seems to keep Ruby Talk in the loop, as many
have requested. Plus, if anyone isn't interested in the Nuby list
traffic it's trivial to filter out.

That's what I was trying to suggest too.



Regards,

Bill

 

[Bill Kelly]

My suggestion was that ALL Nuby messages be moved to Ruby Talk and gain
a [NUBY] if needed. That seems to keep Ruby Talk in the loop, as many
have requested. Plus, if anyone isn't interested in the Nuby list
traffic it's trivial to filter out.

Some comments:

* It's trivial to filter out [NUBY], but as I'll be doing the filtering
after messages are downloaded, it's still traffic. Might be small,
probably won't matter to me, but might be an issue for some.

* Essentially, doing this means that everyone subscribed to ruby-talk
becomes subscribed to nuby-talk. So, why not just post to ruby-talk with
[NUBY] in the subject, and tell nubies to filter out anything that
doesn't have that string? [...]
But, for now, I'm going to wave the buzz-word wand and declare YAGNI.

I would be inclined toward the YAGNI razor myself, except for
all the recent assertions that there are newbies who are
too shy to post here. So I wondered if there might be a way
to address both "no need to split ruby-talk" and "less intimidating
forum for beginners" at the same time.

So the motivation was to provide a (presumably) more comfortable
place for beginners to post, while in actuality bridging the
Nuby list with ruby-talk--because *we* know no-one here in
ruby-talk would be anything but kind and helpful replying to
a message that originated from the Nuby list.

Eventually beginners could transition to ruby-talk when they
felt comfortable - and, surprise! All these familiar faces
(as it were) here in ruby-talk who have been helping to answer
questions on the beginner list all the while.

Go grab PHPNuke or something, start a web site, and tell newbies that
they are invited to help build a pure-Ruby bulletin board package. Eat
your own dog food. Learn by doing, make mistakes together, track what
issues newcomers have, document the learning process. Archive old code
so that people can better understand how the thinking process evolves.

Interesting . . . .


Regards,

Bill