There is a description for a method that does not exist presented by
"ri":
Console Protocol >>>>>
C:\Dokumente und Einstellungen\wolfgang>ri Dir.empty?
------------------------------------------------------------ Dir::empty?
Dir::empty?(path)
···
------------------------------------------------------------------------
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?('./')
NoMethodError: undefined method `empty?' for Dir:Class
from (irb):1
irb(main):002:0>
EOCP >>>>>
Produced via OneClickInstaller 186-25 - ruby 1.8.6 (2007-03-13
patchlevel 0) [i386-mswin32]
You're picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first.
Regards,
Dan
···
On Aug 12, 3:01 pm, "Wolfgang Nádasi-donner" <ed.oda...@wonado.de> wrote:
Moin, moin!
There is a description for a method that does not exist presented by
"ri":
>>>>> Console Protocol >>>>>
C:\Dokumente und Einstellungen\wolfgang>ri Dir.empty?
------------------------------------------------------------ Dir::empty?
Dir::empty?(path)
------------------------------------------------------------------------
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?('./')
NoMethodError: undefined method `empty?' for Dir:Class
from (irb):1
irb(main):002:0>
def dir_empty?(path_to_dir)
Dir.chdir(path_to_dir)
if Dir.glob('*').length > 0
return false
else
return true
end
What's this?
1. 'end' is missing.
2. 'if ... then false else true end' is a lot of hot air
around 'not ...'.
3. As a side effect the method changes the current
directory.
Say
def dir_empty? path_to_dir
Dir.chdir path_to_dir do
not Dir.glob('*').length > 0
end
end
Then, you may consider hidden files ...
First think, then write. Sorry!
Bertram
···
Am Dienstag, 14. Aug 2007, 21:58:17 +0900 schrieb John Joyce:
------------------------------------------------------------------------
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?('./')
NoMethodError: undefined method `empty?' for Dir:Class
from (irb):1
irb(main):002:0>
You're picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first.
A little more thought and a review of Ruby-doc shows that it could be
as simple as:
Class Dir
def empty?(path=Dir.pwd)
Dir.entries(path).empty?
end
end
cheers
Chris
···
On Aug 14, 9:08 am, Bertram Scharpf <li...@bertram-scharpf.de> wrote:
def dir_empty?(path_to_dir)
Dir.chdir(path_to_dir)
if Dir.glob('*').length > 0
return false
else
return true
end
What's this?
1. 'end' is missing.
2. 'if ... then false else true end' is a lot of hot air
around 'not ...'.
3. As a side effect the method changes the current
directory.
Say
def dir_empty? path_to_dir
Dir.chdir path_to_dir do
not Dir.glob('*').length > 0
end
end
How about:
def dir_empty?(path_to_dir)
Dir.glob("#{path_to_dir}/*").empty?
end
Then, you may consider hidden files ...
First think, then write. Sorry!
Please leave the snideness and nastiness out of it. They add nothing
but snideness and nastiness.
David
···
On Tue, 14 Aug 2007, Bertram Scharpf wrote:
Am Dienstag, 14. Aug 2007, 21:58:17 +0900 schrieb John Joyce:
That's an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven't double checked the ri options, but I
don't think there's a way.
If not, we should probably discuss (here or on ruby-core) if it's
feasible and, if so, what the output should look like.
Or, we could collectively decide that, when modifying core classes, we
should stick a tag of some sort on the method doc itself, either so
that it shows up literally in the output, or something rdoc can latch
onto. For example, the actual comments look like this:
# Returns whether or not +path+ is empty. Returns false if +path+
# is not a directory, or contains any files other than '.' or '..'.
···
On Aug 14, 11:33 am, "Wolfgang Nádasi-donner" <ed.oda...@wonado.de> wrote:
Daniel Berger wrote:
> On Aug 12, 3:01 pm, "Wolfgang N?dasi-donner" <ed.oda...@wonado.de> > > wrote:
>> ------------------------------------------------------------------------
>> Returns whether or not +path+ is empty. Returns false if +path+ is
>> not a directory, or contains any files other than '.' or '..'.
>> C:\Dokumente und Einstellungen\wolfgang>irb
>> irb(main):001:0> Dir::empty?('./')
>> NoMethodError: undefined method `empty?' for Dir:Class
>> from (irb):1
>> irb(main):002:0>
> You're picking up Dir.empty? from win32-dir, which ships with the one-
> click installer. In order to use it, you have to require it first.
C:\Documents and Settings\Owner>irb
irb(main):001:0> require 'win32/dir'
=> true
irb(main):002:0> Dir::empty?('./')
NoMethodError: undefined method `empty?' for Dir:Class
from (irb):2
using win32-dir version 0.3.2
···
On Aug 14, 1:33 pm, "Wolfgang Nádasi-donner" <ed.oda...@wonado.de> wrote:
Daniel Berger wrote:
> On Aug 12, 3:01 pm, "Wolfgang N?dasi-donner" <ed.oda...@wonado.de> > > wrote:
>> ------------------------------------------------------------------------
>> Returns whether or not +path+ is empty. Returns false if +path+ is
>> not a directory, or contains any files other than '.' or '..'.
>> C:\Dokumente und Einstellungen\wolfgang>irb
>> irb(main):001:0> Dir::empty?('./')
>> NoMethodError: undefined method `empty?' for Dir:Class
>> from (irb):1
>> irb(main):002:0>
> You're picking up Dir.empty? from win32-dir, which ships with the one-
> click installer. In order to use it, you have to require it first.
That's an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven't double checked the ri options, but I
don't think there's a way.
If not, we should probably discuss (here or on ruby-core) if it's
feasible and, if so, what the output should look like.
I believe this is a known problem. (Known, at least, on the ruby-doc list, and I think discussed on ruby-talk before)
Assorted libraries that ship with Ruby and alter core classes (for example, Yaml) end up having their methods listed with the default methods of core classes (for example, look at the rdocs for Array; it lists 'to_yaml' as a method.)
Or, we could collectively decide that, when modifying core classes, we
should stick a tag of some sort on the method doc itself, either so
that it shows up literally in the output, or something rdoc can latch
onto. For example, the actual comments look like this:
# Returns whether or not +path+ is empty. Returns false if +path+
# is not a directory, or contains any files other than '.' or '..'.
#
def self.empty?(path)
...
end
Perhaps I should add this at the bottom of each comment?
# library: win32-dir
Dunno. What do people think?
It may be a reasonable quick fix, though long term ri and rdoc need to be re-written to stop producing broken docs.
···
--
James Britt
"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
- Edsger W. Dijkstra
I think that's a hack solution to the problem. It might be a good idea
since getting rdoc/ri fixed will take a lot of time, but the proper
solution is as you say: We need rdoc and ri to be fixed to properly
note what file/library a method was defined (and redefined) in.
I'm not (yet) volunteering to do any of the spec or implementation
work for this, but I'm on the verge. Proper documentation is a near
passion of mine, and although my latest solution (years old now - http://phrogz.net/ObjJob/\) doesn't address this particular concern, I
would love to see and/or do some serious work to make auto-generated
documentation:
* Include information on what file you need to add
* Optionally show/hide inherited methods
* Optionally list 'attributes' among methods
* Handle method redefinitions, including documentation from both.
I'm quite disturbed that (last time I checked) RDoc Documentation
includes classes modules and methods from stdlib. Clearly that
shouldn't be the case (right), and is related to this.
···
On Aug 14, 11:54 am, Daniel Berger <djber...@gmail.com> wrote:
On Aug 14, 11:33 am, "Wolfgang Nádasi-donner" <ed.oda...@wonado.de> > wrote:
> Unfortunately it is not visible in the ri output where the method comes
> from.
That's an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven't double checked the ri options, but I
don't think there's a way.
If not, we should probably discuss (here or on ruby-core) if it's
feasible and, if so, what the output should look like.
Or, we could collectively decide that, when modifying core classes, we
should stick a tag of some sort on the method doc itself, either so
that it shows up literally in the output, or something rdoc can latch
onto. For example, the actual comments look like this:
# Returns whether or not +path+ is empty. Returns false if +path+
# is not a directory, or contains any files other than '.' or '..'.
#
def self.empty?(path)
...
end
Perhaps I should add this at the bottom of each comment?
$ ri Rake::Task -f simple
Class: Rake::Task
[...]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task
···
On Aug 14, 2007, at 10:54, Daniel Berger wrote:
On Aug 14, 11:33 am, "Wolfgang Nádasi-donner" <ed.oda...@wonado.de> > wrote:
Daniel Berger wrote:
You're picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first.
Unfortunately it is not visible in the ri output where the method comes
from.
That's an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven't double checked the ri options, but I
don't think there's a way.
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
Then take your own advice about thinking first and then writing, friend.
No offense taken, I know I'm not the only one who writes something and posts quickly because there are other things to do.
I wasn't trying to give a 100% perfect solution, just a quick example idea of what could be done.
Lack of the end token would be caught by the interpreter and the OP would notice or learn from it anyway.
everybody forgets an end here and there.
As for hidden files, well that's somebody else's problem, isn't it?
Depending on point of view, a directory only containing hidden files could be considered empty!
So whether or not those files are important depends on the program's needs.
In that case, hidden or not should be an optional argument with a default.
That said, though we really have to ask what is meant by empty? Directories on many platforms contain hidden files or hidden symlinks. I think that calls for more than one method definition to handle those respective distinctions.
hidden_files_in_dir?(path_to_dir)
symlinks_in_dir?(path_to_dir)
As is often the case, d.a.b. has the most concise solution...
···
On Aug 14, 2007, at 9:24 AM, Bertram Scharpf wrote:
Hi,
Am Dienstag, 14. Aug 2007, 22:40:58 +0900 schrieb dblack@rubypal.com:
On Tue, 14 Aug 2007, Bertram Scharpf wrote:
First think, then write. Sorry!
Please leave the snideness and nastiness out of it. They add nothing
but snideness and nastiness.
I didn't mean it as harmful as it obviously sounds. Sorry,
again.
I'm quite disturbed that (last time I checked) RDoc Documentation
includes classes modules and methods from stdlib. Clearly that
shouldn't be the case (right), and is related to this.
Quite true. Every so often people write to me to complain/inquire about that; I don't have a good response other than, "That's how RDoc was written." And I don't know of a good, automated solution to fixing that on ruby-doc so that the generated docs make more sense.
I've wondered if custom .document files might help, but have not found time to experiment.
Another question I get is, "Why are there two places to look for API docs, instead of a single RDoc path where each class or lib page simply tells you what you need to use it?"
Ruby Central has in the past offered funding to people or groups for writing this or that cool or interesting code. I'd like to see that $$ offered to people (i.e. Ryan Davis et al) to fix RDoc and ri.
It's a non-trivial task but well worth community funding.
That's an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven't double checked the ri options, but I
don't think there's a way.
ri --system
$ ri Rake::Task -f simple
Class: Rake::Task
[...]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task
It helps in this case, but if some parts of the standard library change
core classes, the changes are still listed - example: "ri --system
Array" lists yaml stuff.
