RMagick, a Ruby extension for the ImageMagick (www.imagemagick.org) image
processing library, is now production.
The last two beta releases contained mostly cosmetic changes, and feedback
from users has been positive, so after more than a year of work I’ve
finally decided that it’s golden.
As a tiny concession to those with slow net connections I
did not put an example of an animated GIF in the portfolio. The
documentation that comes with RMagick contains several examples.
Thanks to all the guys who tried beta RMagick. Thanks to Christy, Bob, and
all the ImageMagick developers for their continuing support. Thanks to
the members of the comp.lang.ruby community for answering questions.
And thanks especially to matz for making such a fun language.
You’re right. Some of RMagick’s methods have “bang” twins, including
the resizing methods resize, scale, sample, minify, magnify, and
thumbnail, and a few others like crop, chop, flip, and flop. I added
these because I was writing a lot of scripts that read an image,
immediately resized it or cropped it and then discarded the original.
OTOH, bang versions are probably not justified for some methods. (Does
RMagick really need an adaptive_threshold! method?) This leaves a
whole bunch that might be useful to add - raise! and border! come to
mind.
In the end which bang methods get added is mostly going to be decided
by user input. Which ones do you think would be useful?
···
On Thu, 27 Feb 2003 19:31:16 +0900, Michael Shigorin mike@osdn.org.ua wrote:
On Thu, Feb 27, 2003 at 09:57:36AM +0900, Tim Hunter wrote:
So that “clown = clown.raise” would be just “clown.raise!”?
[skip]
OTOH, bang versions are probably not justified for some
methods. (Does RMagick really need an adaptive_threshold!
method?) This leaves a whole bunch that might be useful to
add - raise! and border! come to mind.
In the end which bang methods get added is mostly going to be
decided by user input. Which ones do you think would be useful?
The ones that seem to yield image modified in a “flow-thru” way,
so that original data will more likely be abandoned.
That’s crap explanation on my side, of course – but I just
start using Ruby for daily jobs and last applications of
ImageMagick during last days were stupid shell scripts.
Want to approah it better though.
PS: yes, I didn’t answer
···
On Thu, Feb 27, 2003 at 11:19:46PM +0900, Tim Hunter wrote:
Could you catch them using method_missing? Or if you wrote them all as bang
methods, you could wrap the non-bang methods as:
def foo
dup.foo!
end
(Array#sort is implemented like this, using Array#sort!). But maybe 'dup'
isn't good enough in this case, as it's not a deep copy. Just a thought
anyway.
Regards,
Brian.
···
On Thu, Feb 27, 2003 at 11:19:46PM +0900, Tim Hunter wrote:
In the end which bang methods get added is mostly going to be decided
by user input. Which ones do you think would be useful?
I thought about trying to automatically generate some or all of the “bang”
methods from the non-bang methods but ultimately gave it up as a bad job.
It may be that I’m just not smart enough, though
My reasoning, such as it is, is that in general images are big, so it
benefits you to minimize the number of duplicates. Some ImageMagick
methods modify the input image. Some return a modified copy of the input
image. It seems to me that there’s some benefit in tailoring each bang
method such that it takes advantage, if it can, of IM’s implementation.
That is, if IM’s method modifies the input image, then the Ruby bang
version should call it directly instead of making a copy, modifying the
copy, and discarding the original. This tells me that I should write each
bang method individually, after examining the underlying ImageMagick
implementation.
I also have a mild aethestic aversion to cluttering up the API with a lot
of methods that would rarely if ever be used.
And, as a last resort, if you’re writing an application and could use a
bang version of a particular RMagick method, you can always add it to the
Image class yourself using the code you show here.
···
On Thu, 27 Feb 2003 23:33:13 +0900, Brian Candler wrote:
On Thu, Feb 27, 2003 at 11:19:46PM +0900, Tim Hunter wrote:
In the end which bang methods get added is mostly going to be decided
by user input. Which ones do you think would be useful?
Could you catch them using method_missing? Or if you wrote them all as
bang methods, you could wrap the non-bang methods as:
def foo
dup.foo!
end
(Array#sort is implemented like this, using Array#sort!). But maybe
‘dup’ isn’t good enough in this case, as it’s not a deep copy. Just a
thought anyway.
And, as a last resort, if you're writing an application and could use a
bang version of a particular RMagick method, you can always add it to the
Image class yourself using the code you show here.
Errm, actually I think it's quite difficult to turn a non-bang method into a
bang method. You can't change 'self' to point to be a different object, so I
think you end up having to unpick the underlying class and modify all the
instance variables explicitly.
What I showed was how to turn a bang-method into a non-bang method (which is
easy)
Regards,
Brian.
···
On Fri, Feb 28, 2003 at 09:42:17AM +0900, Tim Hunter wrote:
On Thu, 27 Feb 2003 23:33:13 +0900, Brian Candler wrote:
> On Thu, Feb 27, 2003 at 11:19:46PM +0900, Tim Hunter wrote:
>> In the end which bang methods get added is mostly going to be decided
>> by user input. Which ones do you think would be useful?
>
> Could you catch them using method_missing? Or if you wrote them all as
> bang methods, you could wrap the non-bang methods as:
>
> def foo
> dup.foo!
> end
>
> (Array#sort is implemented like this, using Array#sort!). But maybe
> 'dup' isn't good enough in this case, as it's not a deep copy. Just a
> thought anyway.
>
> Regards,
>
> Brian.
Urp. You’re right, of course. Had my stupid hat on.
···
On Fri, 28 Feb 2003 21:49:41 +0900, Brian Candler B.Candler@pobox.com wrote:
On Fri, Feb 28, 2003 at 09:42:17AM +0900, Tim Hunter wrote:
And, as a last resort, if you’re writing an application and could use a
bang version of a particular RMagick method, you can always add it to the
Image class yourself using the code you show here.
Errm, actually I think it’s quite difficult to turn a non-bang method into a
bang method. You can’t change ‘self’ to point to be a different object, so I
think you end up having to unpick the underlying class and modify all the
instance variables explicitly.
What I showed was how to turn a bang-method into a non-bang method (which is
easy)
– but I just