return_bang 1.0

drbrain | Wed, 21 Dec 2011 00:52:48 GMT

return_bang version 1.0 has been released!

return_bang implements non-local exits from methods. Use return_bang to exit back to a processing loop from deeply nested code, or just to confound your enemies and your friends! What could possibly go wrong?

Features

  • Implements non-local exits for methods

  • Nestable

  • Named and stack-based exit points, go exactly where you need to be

  • Ignores pesky ensure blocks for when you really, really need to return

Synopsis

require 'return_bang/everywhere'

def some_method
  deeply_nested
  # never reached
end

def deeply_nested
  return!
end

return_here do
  some_method
end
# resumes here

Testimonials

“you’ll wind up with your cock in /dev/null somehow” – slyphon

“Haha! Right! This skips ensure… SO EVIL‼‼” – drbrain

“This is so evil that 6 def test_… have turned into: 16 tests, 65 assertions, 18 failures, 7 errors” – drbrain

Install

sudo gem install return_bang

Posted in  | 1 comment | no trackbacks

mechanize 2.1

drbrain | Tue, 20 Dec 2011 19:14:27 GMT

mechanize version 2.1 has been released!

The Mechanize library is used for automating interaction with websites. Mechanize automatically stores and sends cookies, follows redirects, can follow links, and submit forms. Form fields can be populated and submitted. Mechanize also keeps track of the sites that you have visited as a history.

2.1 / 2011-12-20

  • Deprecations

    • Mechanize#get no longer accepts an options hash.

    • Mechanize::Util::to_native_charset has been removed.

  • Minor enhancements

    • Mechanize now depends on net-http-persistent 2.3+. This new version brings idle timeouts to help with the dreaded “too many connection resets” issue when POSTing to a closed connection. Issue #123

    • SSL connections will be verified against the system certificate store by default.

    • Added Mechanize#retry_change_requests to allow mechanize to retry POST and other non-idempotent requests when you know it is safe to do so. Issue #123

    • Mechanize can now stream files directly to disk without loading them into memory first through Mechanize::Download, a pluggable parser for downloading files.

      All responses larger than Mechanize#max_file_buffer are downloaded to a Tempfile. For backwards compatibility Mechanize::File subclasses still load the response body into memory.

      To force all unknown content types to download to disk instead of memory set:

      agent.pluggable_parser.default = Mechanize::Download

    • Added Mechanize#content_encoding_hooks which allow handling of non-standard content encodings like “agzip”. Patch #125 by kitamomonga

    • Added dom_class to elements and the element matcher like dom_id. Patch #156 by Dan Hansen.

    • Added support for the HTML5 keygen form element. See dev.w3.org/html5/spec/Overview.html#the-keygen-element Patch #157 by Victor Costan.

    • Mechanize no longer follows meta refreshes that have no “url=” in the content attribute to avoid infinite loops. To follow a meta refresh to the same page set Mechanize#follow_meta_refresh_self to true. Issue #134 by Jo Hund.

    • Updated ‘Mac Safari’ User-Agent alias to Safari 5.1.1. ‘Mac Safari 4’ can be used for the old ‘Mac Safari’ alias.

    • When given multiple HTTP authentication options mechanize now picks the strongest method.

    • Improvements to HTTP authorization:

      • mechanize raises Mechanize::UnathorizedError for 401 responses which is a sublcass of Mechanize::ResponseCodeError.

      • Added support for NTLM authentication, but this has not been tested.

    • Mechanize::Cookie.new accepts attributes in a hash.

    • Mechanize::CookieJar#<<(cookie) (alias: add!) is added. Issue #139

    • Different mechanize instances may now have different loggers. Issue #122

    • Mechanize now accepts a proxy port as a service name or number string. Issue #167

  • Bug fixes

    • Mechanize now handles cookies just as most modern browsers do, roughly based on RFC 6265.

      • domain=.example.com (which is invalid) is considered identical to domain=example.com.

      • A cookie with domain=example.com is sent to host.sub.example.com as well as host.example.com and example.com.

      • A cookie with domain=TLD (no dots) is accepted and sent if the host name is TLD, and rejected otherwise. To retain compatibility and convention, host/domain names starting with “local” are exempt from this rule.

      • A cookie with no domain attribute is only sent to the original host.

      • A cookie with an Effective TLD is rejected based on the public suffix list. (cf. publicsuffix.org/)

      • “Secure” cookies are not sent via non-https connection.

      • Subdomain match is not performed against an IP address.

      • It is recommended that you clear out existing cookie jars for regeneration because previously saved cookies may not have been parsed correctly.

    • Mechanize takes more care to avoid saving files with certain unsafe names. You should still take care not to use mechanize to save files directly into your home directory ($HOME). Issue #163.

    • Mechanize#cookie_jar= works again. Issue #126

    • The original Referer value persists on redirection. Issue #150

    • Do not send a referer on a Refresh header based redirection.

    • Fixed encoding error in tests when LANG=C. Patch #142 by jinschoi.

    • The order of items in a form submission now match the DOM order. Patch #129 by kitamomonga

    • Fixed proxy example in EXAMPLE. Issue #146 by NielsKSchjoedt

Posted in  | 1 comment | no trackbacks

rdoc 3.12

drbrain | Thu, 15 Dec 2011 21:58:05 GMT

home

github.com/rdoc/rdoc

rdoc

docs.seattlerb.org/rdoc

bugs

github.com/rdoc/rdoc/issues

RDoc produces HTML and command-line documentation for Ruby projects. RDoc includes the rdoc and ri tools for generating and displaying online documentation.

See RDoc for a description of RDoc’s markup and basic use.

3.12 / 2011-12-15

  • Minor enhancements

    • Added DEVELOPERS document which contains an overview of how RDoc works and how to add new features to RDoc.

    • Improved title for HTML output to include --title in the title element.

    • rdoc --pipe now understands --markup.

    • RDoc now supports irc-scheme hyperlinks. Issue #83 by trans.

  • Bug fixes

    • Fix title on HTML output for pages.

    • Fixed parsing of non-indented HEREDOC.

    • Fixed parsing of %w[] and other % literals. Issue #84 by Erik Hollensbe

    • Fixed arrow replacement in HTML output munging the spaceship operator. Issue #85 by eclectic923.

    • Verbatim sections with ERB that match the ruby code whitelist are no longer syntax-highlighted. Issue #86 by eclectic923

    • Line endings on windows are normalized immediately after reading with binmode. Issue #87 by Usa Nakamura

    • RDoc better understands directives for comments. Comment directives can now be found anywhere in multi-line comments. Issue #90 by Ryan Davis

    • Tidy links to methods show the label again. Issue #88 by Simon Chiang

    • RDoc::Parser::C can now find comments directly above rb_define_class_under. Issue #89 by Enrico

    • In rdoc, backspace and ansi formatters, labels and notes without bodies are now shown.

    • In rdoc, backspace and ansi formatters, whitespace between label or note and the colon is now stripped.

Posted in ,  | no comments | no trackbacks

Packaging from a gemspec is not the Best Way

drbrain | Fri, 09 Dec 2011 22:57:06 GMT

Or, why you should use Hoe (or a tool like it) to package your gems.

A while back Yehuda wrote Using .gemspecs as Intended and asserted that packaging directly from a .gemspec file was both the way you were supposed to build gems and the best way to build gems.

This is not true.

Rake::GemPackageTask (now Gem::PackageTask) was added to rake less than two weeks after the first commit on RubyGems. Which points to the recognition of a need to have a better way to describe and build a gem than just a file.

Using rake allows you to do more than just package a static list of files in a clean and reusable manner. You can write tasks to generate files that are then packaged in your gem at build time. Hoe builds atop Rake to support many types of generated files easily through task dependencies.

For example, generating a .gemtest file to work with GemTesters, integrating with rake-compiler for pre-compiled gems or generating parsers.

I can hear you thinking "you might have a point there, but I don't generate any files, so how does this apply to me?" Well, what if you wanted to include generated man pages in your gem using binman?

In the world of packaging directly from a gemspec the way to automatically generate files is to violate RubyGems' internals by overriding Gem::Specification#initialize. I can't blame Suraj Kurapati for this, he's working within the framework of the popular thing to do and this is the only way he could implement it.

(Hoe, on the other hand, handles such pre-package dependencies through a set of pre-defined rake tasks that you can add dependencies too. If you need to generate a file you make the package task dependent on it. See the examples above.)

How can we make this better?

First of all, stop using gemspecs as the One True Description of your gem. Let rake generate it. While Hoe is obviously the best way to do this, it doesn't support generating the gemspec by default. You can use one of the gemspec plugins for that. I'm sure there are other build tools have the equivalent built right in.

Second, if you've writing a tool that generates files that will be packaged into a gem, provide a rake task like the one that ships with binman that build tool authors can hook to make packaging seamless.

(Also, please, don't use system when you can use API.)

Posted in ,  | 6 comments | no trackbacks