World: r3wp

Sorry, load/library %X11 - it's case-sensitive on Linux.

The code should be easily adjustable to the Imagemagick port for 
Windows though.

when I look in the script, there are load lines to uncomment depending 
on which version to load. it looks like this in my case:


imagemagicklib: %CORE_RL_magick_.dll          ; uncomment for windows 
version

imagemagickwandlib: %CORE_RL_wand_.dll          ; uncomment for windows 
version


; imagemagicklib: %/usr/lib/libMagick.so      ; uncomment for linux 
version, try to find where it is installed

; imagemagickwandlib: %/usr/lib/libWand.so      ; uncomment for linux 
version, try to find where it is installed

Is he using the cygwin version of Imagemagick or the native version?

it doesn't say anything about cygwin.

The cygwin version would try to load X11.dll. The native version 
wouldn't.

seems there are references to x11 in the DLLs. so that's the problem.

You should track down the native binaries then - they don't have 
X11 references.

Try this: http://www.imagemagick.org/script/binary-releases.php?ImageMagick=m148pm1far9d2bsj0b5tpb9ui2#windows

If they do have X11 references let us know.

trying to get the newest windows version now

amazing with so many different versions for a little bit of image 
processing...

Welcome to the wonders of cross-platform code. There isn't a native 
version for Mac either: It uses X11.

looks like the windows version is x11 free.

Cool :)

but the helper script states explicitly to use version 6.2.9, which 
is no longer available.

I assume Edgar doesn't have interest/time to update it?

That would be in keeping with the work load at Qtask, as I recall. 
He's a busy guy.

I think I'll just call the CLI version... don't need anything other 
than smooth downscaling and a few other bits.

a clean installation and call "convert" is enough to give access 
under windows, so that's good enough for me.

I use comlib for this .. but it probably doesn't do more than using 
covert as well

I use CONVERT quite a bit, and it works well for me.

The problem with ImageMagick was that the API was a moving target. 

So the script I submitted worked only for that specific version of 
ImageMagick.

Since Qtask is not currently using ImageMagick now, I don't know 
when I can get back to work on it again.

I suggest to do what Gregg is suggesting at this time.

I'm follow Gregg's suggestion.

following

I'm building a simple dialect around it. I'm not sure I can make 
it 1:1 capable with CONVERT, but at least you would then be able 
to pass a standard REBOL block directly to CONVERT.

Example:


process [path %/z load %image.jpg blur 3x6 negate resize 50x50 save 
%image2.jpg]

I've thought about doing that as well Henrik, but by needs ended 
up being very static. I have also considered a test app that you 
could use to preview the result and then copy the command line, life 
effect-lab and font-lab.

yes, Gregg, I agree. Mine is diverting now towards what I really 
need it for: namely for adding auto-generated images to docs, so 
only some very specific functionality is used. I'll be adding a few 
more features today and then I'll publish it, but I'm not sure how 
much value it has to others than me.

scratch that. text in imagemagick is crazy complex. going to figure 
out something else with DRAW.

Yes, a big part of my motivation to write a dialect is that the CLI 
format is nto very human friendly.

but its more stable than the API and quite fast in any case.

My goal of looking at the API was to avoid the startup overhead when 
using CALL. While I wouldn't mind things being faster, we call it 
*a lot* and it works great. The upside of using the CLI is that you 
don't have to worry about a single instance being your bottleneck, 
and it's scalable.

Does anyone have a second opinion on my last comment here? http://www.rebol.com/cgi-bin/blog.r?view=0466#comments

We're trying to decide what should go into /Base 2.7.8, at least 
as it relates to the R2/Forward functions.

I think the reflection functions are particularly good to have, and 
most of the others as well. The three I'll vote against are !, ++, 
and -- (still campaigning :-).

... I am trying to vote to finally really finish R3 and release a 
beta .... the wait is terrible .... ;-)

Ok...I try to vote to...where do we do this voting?  :)

Carl's cell phone? ;-)

Gregg, I would be OK with using NOT, INC and DEC instead, and said 
so in the original blog discussion where ++ and -- were proposed 
(but was outvoted).

yeaaaahh, I like much more INC and DEC.
Really Z80ish

I was thinking Pascal, but REBOL does appeal more to the assembler 
fan (Ratio notwithstanding) :)

We also have ADD but not SUB (SUBTRACT)

Add is a complete verb :)  That is why INC and DEC weren't chosen 
at first: REBOL naming standards for built-in functions abhor acronyms 
(ironic) and abbreviations, for the most part (FUNC and FUNCT are 
exceptions). That's why we break out the thesaurus when we want to 
come up with a shorter name, most of the time.

Still, I would appreciate abbreviations to ++ and --, which look 
like ops but aren't.

appreciate -> prefer

(Looks like your campaign has some legs, Gregg. Take it to CureCode!)

Carl, how possible is it to get UNBIND ported to R2 as a native for 
2.7.8? It's the only thing missing from R2/Forward so far.

And I really need it for the next bit.

UNBIND... should be easy to add.

Yeah. I can pie-in-the-sky and ask for ASSERT, APPLY and RESOLVE 
as well, but I've managed to clone those so they're not as pressing.