On Tue, Oct 6, 2009 at 12:33 PM, 7stud – [email protected]
wrote:
+str+ is a String holding a date representation. +fmt+ is the
(no description...)specified format.
–
Posted via http://www.ruby-forum.com/.
With the above approach one might benefit by starting with:
ri strftime
Then looking at “all” the strftime methods.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
-Greg Graffin (Bad Religion)
On Oct 6, 2009, at 1:59 PM, 7stud – wrote:
I have suggested a better solution in the past, and I’ll suggest it
again: open up the ruby docs to user comments like php does. If the
ruby community wants to continue with the worst docs I’ve ever seen,
then so be it.
Well, they Ruby Core team does take patches.
James Edward G. II
James Edward G. II wrote:
On Oct 6, 2009, at 1:33 PM, 7stud – wrote:
That last one is a real doozy–and quite typical of ruby Standard
Library documentation.You’ve been shown the format option from the documentation. I’m not
sure how much more proof you require.
I already knew the format specifiers were described in the Time class.
The question is whether someone new to ruby could figure out how to
format Date objects. I think not. The reason: ruby has poor
documentation.
You’ve obviously gone into the source to find them once, to bad you
didn’t create a documentation patch while you were there.James Edward G. II
I have suggested a better solution in the past, and I’ll suggest it
again: open up the ruby docs to user comments like php does. If the
ruby community wants to continue with the worst docs I’ve ever seen,
then so be it.
7stud – wrote:
Not at all:
format that the date is in. See date/format.rb for details on
strftime(fmt=’%F’)
[Source]
That last one is a real doozy–and quite typical of ruby Standard
Library documentation.
Or you could just use the Standard C Library documentation. I don’t
know if anyone wants to try and include the entire document into the
documentation for Ruby, or if its even legal to do so.
2009/10/6 James Edward G. II [email protected]:
On Oct 6, 2009, at 1:59 PM, 7stud – wrote:
I have suggested a better solution in the past, and I’ll suggest it
again: open up the ruby docs to user comments like php does. Â If the
ruby community wants to continue with the worst docs I’ve ever seen,
then so be it.Well, they Ruby Core team does take patches.
It’s not the same thing.
You can comment on the PHP documentation even if you don’t know how to
make a patch and don’t understand whatever format the docs are in.
Still people visiting the documentation site can read the comment.
It has its downsides, too. There are some meaningless comments or
multiple refinements of the same sample code.
Thanks
Michal
On 10/06/2009 08:59 PM, Michal S. wrote:
Not at all:
format that the date is in. See date/format.rb for details onIn this case I use the strftime(3) man page but windows users are at a
disadvantage here.The man pages can be found on the web, though.
And while there are things that could use better documentation there
is no need to replicate documentation of ancient function which is
standardized in POSIX and wherever else.
That approach has its downsides as well: you won’t be aware of %p in
Ruby’s printf which is often helpful for logging and debugging.
Kind regards
robert
On 6 Okt., 23:15, Michal S. [email protected] wrote:
It’s not the same thing.
You can comment on the PHP documentation even if you don’t know how to
make a patch and don’t understand whatever format the docs are in.
Still people visiting the documentation site can read the comment.It has its downsides, too. There are some meaningless comments or
multiple refinements of the same sample code.
And lots of really bad/wrong/dangerous code (that is often c&p). I
dont think that comments are a good idea, but may be some kind of wiki
would be productive, because I also think, that the documentation
needs improvement.
Stefan
On 10/06/2009 08:16 AM, 7stud – wrote:
flebber wrote:
Secondly I found capturing the date input from a console in python to
be a little long winded, below is the script I wrote in python would
this be significantly easier in Ruby.No. I think in ruby the code would be almost exactly the same–except
it’s significantly harder to figure out in ruby because there is no
documentation about the format specifiers you can use with strftime()
and strptime(). Amazing, huh?
It’s not very good to find but what about this?
side by side(in python it would be 2.6.x and 3.x). They probably use
1.8.6 for their serious programs, and then they play around with 1.9.x
to learn the new stuff.
I have both installed but use only 1.9 simply because it is
significantly faster and also because the new feature set seems better
to me. Since I am not using too many non standard libraries (and gems)
the library lag is not an issue for me.
Kind regards
robert
2009/10/7 Stefan P. [email protected]:
then so be it.
multiple refinements of the same sample code.And lots of really bad/wrong/dangerous code (that is often c&p). I
Of course, the quality of the code posted as part of the comments
varies but if there is a common pitfall that is posted it is more
likely that somebody finds out and posts a correction before you look
than that you would not hit the same problem if you put together the
code yourself. It seems to me that in PHP language-specific pitfalls
are notoriously created by language misfeatures.
The weakness of PHP is it does not have irb so clarifying the
description for yourself is quite expensive.
Still a missing reference like the one with strftime format may not be
easy to find and could be added as a comment.
One of the other problems is that as any public forum you not only
need an infrastructure for collecting a and storing posts but also a
human moderator(s) to watch over the system.
dont think that comments are a good idea, but may be some kind of wiki
would be productive, because I also think, that the documentation
needs improvement.
The strength of the comments is that they are right below the
description.
A separate wiki would likely die a quiet (or spammy) death.
I would guess it’s even less likely to succeed than posting a doc patch.
Thanks
Michal
Zachary C. wrote:
And to think, this whole dilemma could have been avoided if you named
her Python.
lol.
2009/10/7 Robert K. [email protected]:
documentation about the format specifiers you can use with strftime()
strptime(str=‘-4712-01-01’, fmt=‘%F’, sg=ITALY)
is no need to replicate documentation of ancient function which is
standardized in POSIX and wherever else.That approach has its downsides as well: you won’t be aware of %p in Ruby’s
printf which is often helpful for logging and debugging.
Ruby even has that?
Never needed it. It may be perhaps somewhat faster than string
interpolation and string addition but I prefer code readability over
speed, especially for debug prints. Logging may need any speed you can
get, though.
Also there is no need to resort to unix manpages there because
IO#printf refers to the method that has the format specifiers listed.
In general ruby documentation needs something that was introduced for
Oniguruma regex format: a format specification that is not a part of
method documentation but the relevant method/class descriptions refer
to it.
Thanks
Michal
Stefan P. wrote:
On 6 Okt., 23:15, Michal S. [email protected] wrote:
It’s not the same thing.
You can comment on the PHP documentation even if you don’t know how to
make a patch and don’t understand whatever format the docs are in.
Still people visiting the documentation site can read the comment.It has its downsides, too. There are some meaningless comments or
multiple refinements of the same sample code.And lots of really bad/wrong/dangerous code (that is often c&p).
That’s not the point of the comments in the php docs. The comments are
not supposed to serve as a model on how to write code. The comments
serve to point out the nuances and pitfalls of the various functions in
the docs. In that regard, they are invaluable. You can choose to do
what you want with the issues brought up in the comments–ignore it,
dismiss issues that are not important to your code, follow the advice in
other comments–and even post a better solution to an issue highlighted
in the comments.
In essence, php is self documenting–which is a heck of a lot better
than “not documented at all”, which happens to be the state of affairs
with a lot of the ruby standard library. It’s hard for me to believe
that a library is even admitted into the ruby standard library without
some minimum level of documentation.
In my opinion, if libraries aren’t documented, then they really doesn’t
even exist in any kind of useful sense, and therefore they should be
stricken from the language.
7stud – wrote:
In essence, php is self documenting–which is a heck of a lot better
than “not documented at all”, which happens to be the state of affairs
with a lot of the ruby standard library. It’s hard for me to believe
that a library is even admitted into the ruby standard library without
some minimum level of documentation.In my opinion, if libraries aren’t documented, then they really doesn’t
even exist in any kind of useful sense, and therefore they should be
stricken from the language.
How much of the Ruby standard library is a port of the C standard
library? This has been documented since at least 1992 and is readily
available.
From: Michael W. Ryder [mailto:[email protected]]
How much of the Ruby standard library is a port of the C standard
library? This has been documented since at least 1992 and is readily
available.
This is at least the second person to say this, and I find it a little
scary. Just because C has these functions documented does NOT mean that
it is OK for Ruby not to. Just because C has a function named sprintf
does NOT mean that a Ruby/Python/PHP/any other langauges’ sprintf will
work the same way.
Imagine this for a minute: there is a new browser in town. Everyone
loves it. So you decide to give it a shot. You find a really cool page
and you want to bookmark it. You look around, find the bookmark menu
and click add. It provides two empty textboxes with no labels. So you
look up adding a bookmark in the docs, and there is nothing there. So
you head for the mailing list and ask for help. Everyone says “No need
to document it, it’s thoroughly documented in Firefox’s documentation”
Is that good documentation pratice?
Bottom line: When I go to look up a function and I find no notation
whatsoever (not even “see ‘x’ function in c”) it is not good
documentation, and it does not make for a good user expierience.
(This from a newbie who is loving the language, yet constantly,
hating the lack of documentation)
Walton H. wrote:
From: Michael W. Ryder [mailto:[email protected]]
How much of the Ruby standard library is a port of the C standard
library? This has been documented since at least 1992 and is readily
available.This is at least the second person to say this, and I find it a little
scary. Just because C has these functions documented does NOT mean that
it is OK for Ruby not to.
I think it is more a matter of priorities. While you may find that the
lack of documentation of a function that is copied from C upsetting, I
would rather the developers use their limited time for more important,
to me at least, things. I prefer hard copy documentation and having a
copy of the C Standard Library on my desktop gives me this ability. I
have never been able to get the Ruby documentation to work, probably
because it was faster to grab the book.
Just because C has a function named sprintf
does NOT mean that a Ruby/Python/PHP/any other langauges’ sprintf will
work the same way.
I would expect anyone making a new version of sprintf to rename the
function to forestall the inevitable tarring and feathering. It would
be like changing the meaning of black to mean light purple. People
expect words, and function names are words, to not change.
Imagine this for a minute: there is a new browser in town. Everyone
loves it. So you decide to give it a shot. You find a really cool page
and you want to bookmark it. You look around, find the bookmark menu
and click add. It provides two empty textboxes with no labels. So you
look up adding a bookmark in the docs, and there is nothing there. So
you head for the mailing list and ask for help. Everyone says “No need
to document it, it’s thoroughly documented in Firefox’s documentation”
Is that good documentation pratice?
I am not saying that it is good practice but there is some logic in
this. If your new browser used Firefox as a base if a change was made
to Firefox the change may percolate up into the new browser. So there
will be changes made to the documentation. Which do you think will
happen first, the well supported Firefox browser, or the small team
using the Firefox code?
Bottom line: When I go to look up a function and I find no notation
whatsoever (not even “see ‘x’ function in c”) it is not good
documentation, and it does not make for a good user expierience.
The documentation for the language does not bother me anywhere near as
much as the changes breaking old code and no way to find out what is
broken without experience. Different documentation faults.
On 2009-10-07, David M. [email protected] wrote:
On Tuesday 06 October 2009 01:00:05 pm Seebs wrote:
As of sometime recently, there were reports of some Rails stuff not working
on it, which might be a good reason.
Which Rails stuff?
Especially considering Rails officially supports 1.9, I thought.
Don’t remember now. Ahh!
There’s a use of a[i] ^ b[i] broken by the change from a[i] being the
integer char value to a string.
May be specific to 2.3.4.
-s
On Tuesday 06 October 2009 01:00:05 pm Seebs wrote:
On 2009-10-06, David M. [email protected] wrote:
And all other things equal, 1.9.1 is twice as fast as 1.8.6, so there
isn’t a good reason not to use it.As of sometime recently, there were reports of some Rails stuff not working
on it, which might be a good reason.
Which Rails stuff?
Especially considering Rails officially supports 1.9, I thought.
On Wednesday 07 October 2009 06:45:15 pm Seebs wrote:
#3144 undefined method `^' for String - RoR 2.3.4 - Ruby on Rails - rails
defined-method-for-string-ror-234
Ah, I see. And it’s resolved.
So, probably fewer bugs on 1.8, probably some undiscovered 1.9-related
bugs.
Wouldn’t stop me from using 1.9 – it’s stable enough that I’m as likely
to
find a 1.9-specific bug as a general bug in Rails.
David M.:
On Monday 05 October 2009 10:45:08 pm flebber wrote:
Which version of Ruby should I use 1.8.6,
1.9.1 or a preview version of 1.9.2?
If it’s a brand-new project, use 1.9.1.
I fully agree. I write all of my new stuff in Ruby 1.9.
Unless you do something strange, it should be portable backwards
to 1.8.7, and with a few (very small) patches, to 1.8.6.
And you might find the backports gem very useful
(as I have): GitHub - marcandre/backports: The latest features of Ruby backported to older versions.
As others say, not all libraries will be available
on 1.9.1, but the vast, VAST majority are.
Also, you might find http://isitruby19.com/ useful.
If you have a choice between two libraries, one which works on 1.9.1,
and one which doesn’t, that’s a strong hint about which is more
actively maintained.
+1 
And all other things equal, 1.9.1 is twice as fast
as 1.8.6, so there isn’t a good reason not to use it.
I do a lot number crunching in my PhD code and 1.9 is
almost exactly three times faster than 1.8 for me.
— Shot
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs