No description provided.
Guys. I am hungry for ~/.pry_historys.
What I want to do is run a big scan on them and figure out which commands and what Ruby we're running in them. I can do this for my own, but it'd be better balanced if I got yours. The man page would be one thing that would benefit from this knowledge.
mail -s $USER email@example.com < ~/.pry_history
Github trynna not let me tag errbody.
Sent mine as well.
I heard @rondale-sc can help us with this issue (it was his idea to add the man page).
@rking @kyrylo I'd love to help. Have you compiled a list of top commands from the .pry_history's that you've collected? If you'd like me to do that I can, just hit me with the info. ^_^
Updated the man page with a list of all Pry.commands. Parsed result of Pry.commands using https://gist.github.com/4315706. Not sure if that's what we're after, but maybe a place to start.
I also wrote a blog on creating man-pages back when I originally created the man page for pry: http://jonathan-jackson.net/man-and-ruby.html.
I'm not sure if the pry commands belong in man(1). But I'm not sure where else they'd go.
Sections are broken down like so (http://en.wikipedia.org/wiki/Man_page):
@rondale-sc - Looks like a nice start!
1) Some of the formatting has some extra blank lines, it seems.
2) Can you rig up a process to autogenerate this? E.g. IMO it should be a dependency of the 'gemspec' Rake task, so we don't forget to update it.
3) There are some other things I want to do, one is analyze the ~/.pry_historys and write an intro section for the most-common use patterns.
Thanks! (Or am I just saying that because I'm intimidated by your Gravatar pointing at me menacingly?)
And the picture isn't really that menacing, ^_~
Here's a start: https://github.com/rondale-sc/generate_pry_man
If any of you have suggestions for other things that might fit into the man page, be sure to take a look at the template file with the .erb extension. Now is a good time to add some stuff.
@rondale-sc no need for those accessors ;-) Implement "close" on your class, and get rid of obj.ronn_file.close.
@rondale-sc oops, just get rid of the accessors, you close in generate_all.
@robgleeson I'm using the accessors as readers. I could change them, but if I remove them I'll need to reference the variables themselves.
I'll take a look again later, and probably add a few unit tests.
@rondale-sc generally, it is better to keep state private and provide an interface that operates upon that state. For this, though, I don't think it really matters.
@robgleeson That's a good point. Unfortunately, I didn't test drive this so I was kinda willy-nilly with state. I'm going to add a test or two and refactor later.
We decided to remove the man page completely.