World: r4wp

Hmm, I do (I once submitted it to Carl, but he never used it). Nevertheless, 
in my code I prefer a general loop called CFOR (the name is unfortunate, 
I must admit). That is what I propose instead since it is both faster 
and more flexible at the same time. Do you think it makes sense to 
propose it in the CC?

Any good idea of a Rebol-compatible name for it?

The trouble with FOR is not only that it has bugs. Another problem 
is that it is incompatible with REPEAT, while assumed to be a generalization 
of it...

I remember CFOR, it was interesting. It's not FOR compatible though. 
What I was hoping to put in rebol-patches was a function with the 
same API as FOR, but without the bugs. Additional functions are great 
too, but out of scope for the rebol-patches project.

Hmm, I actually do not propose to use my patched FOR since it is 
extremely slow like the original, I think it would make more sense 
to use a more REPEAT-compatible version of it, which I do not have 
now.

I don't recommend using FOR in R2, patched or not, but I would rather 
have a patched version than a non-patched version. That's the whole 
point to rebol-patches. I don't judge the functions in some philosophical 
or practical way, I just make sure they at least work.

Better functions are more the purview of other projects.

Is 'for used much at all?

or, to tell it differently: I prefer to have a version of FOR which 
would be more R3 FOR compatible...

(instead of patching the R2 FOR, which I do have patches for, but 
which is extremely slow)

FOR is not used in R2 (at least I never recommended its usage) because:

* it is buggy
* it is extremely slow

Can that be done without breaking too much code? Because if so, that 
would definitely be in the project scope. A native FOR replacement 
would be ideal, but we can't change existing R2 versions to have 
always had such a function in the past. The rebol-patches project 
is for bringing up the compatibility and fixing known bugs when run 
on existing R2 versions. I hope to push its compatibility all the 
way back to 2.5.0. Replacing FOR with a non-buggy native version 
in some future R2 release would just mean that for that version going 
forward rebol-patches wouldn't need to patch that particular function.

So unless you have a way for rebol-patches to perform a retrofit 
of an existing R2 version with a new native function using cross-platform 
code, we're going to need not only the mezz patch for the past and 
the native for future R2 releases (if any).

I did not mean native. I just meant mezzanine FOR but implemented 
differently.

(to behave more like the native FOR in R3 or REPEAT in R2)

OK, cool. Will it have the same external API, so that if it is used 
in the same way (without obscure hacks) it will do the same thing? 
I'm OK with changing its behavior when you change the variable in 
mid loop, as long as that isn't commonly done in R2. If it's too 
incompatible that would be more something to put in R2/Forward (I'm 
spliting the fixes from the major changes).

How would it be different? Do you have a link to one of those articles 
you write about this kind of thing? :)

OK, I will try to write it as I think it should be both faster and 
less buggy.

Apache license OK, same as R3? I know it's for R2, but it makes the 
contributor rights more clear.

Sure

Before you ask, the MAP-EACH fix is going in there too :)

I will help to make the new REBOL !

Until then I need your help:

I whish to re-learn REBOL from scratch starting from REBOL3

I have understood that until now I have looked to REBOL with the 
eye of the "old-style-programmer"

I apologize for avery stupid question I'll make in the following 
weeks/months.

no stupid questions exist. Mostly more stupid not to ask them, as 
only then they can help you to understand.

SKIP's offset arg can take a pair!  -- Can someone show me an example 
of doing that?

that's for moving across a bitmap isn't it?

That's what I'd like to know :)

let me scan my source code

Also interested in usage example for TAKE/DEEP where the /deep can 
be a pair!

auto-crop-bitmap-text: func ["Returns a cropped image, or none if 
the input image was blank"
	image [image!] 
	/local region
][
	if region: find-bitmap-text-crop-region image [ 

  copy/part skip image region/1 region/2  ; return a cropped image
	]
]

not sure if that's what you're after

Thanks......I can see now how SKIP can work on an image bitmap
    img: to-image #{....plausible hex stream....}
    skip img 2x2


However, TAKE does not work on image bitmaps.....Are there other 
types of bitmap?

The bitset type could be thought of as a one-dimensional bitmap of 
depth 1, but that's stretching the defitnition a little :)

:)
Is TAKE intended one day to work on image bitmaps?
Or is there another use for:
     TAKE/DEEP word 10x10

No, because TAKE removes from the original, and that would change 
the dimensions of the original in the case on an image, assuming 
it's possible (you can't take a hole from the middle, for instance). 
So you mean COPY/part here.

My confusion is due to the help for TAKE saying the /DEEP arg can 
take a pair! -- So I was looking for a usage case.

Well, maybe it was intended to work on image (if so, sorry). I'd 
have to review the R2/Forward code to be sure, since its version 
of TAKE would have replicated that. It's a really weird thing to 
do to an image though.

The R2/Forward TAKE makes reference to an image in its code, but 
not in its typespec. Weird. A bug?

BrianH: If I wanted to take a subsection of an image, why wouldn't 
it create a new image with just that subsection, and then replace 
the "taken" part in the old image with 0.0.0?  Or am I understanding 
the purpose of 'take incorrectly?

First question about REBOL(£):

Is there an article which explains how REBOL3 loads words in memory 
and how their are organized, stored, evaluated ?

Here's a starting point for such an article.....
   http://www.rebol.com/docs/expert-intro.html

Bo, TAKE physically removes stuff, it doesn't leave a hole.

Has anyone worked with the Amazon aws services?  I'm not sure how 
to "Calculate an RFC 2104-compliant HMAC with the SHA256 hash algorithm" 
as described in step 8 on page 62 here:  http://awsdocs.s3.amazonaws.com/Associates/latest/prod-adv-api-dg.pdf

Just trying to look up prices based on SKU.  This is the string I 
have so far:


http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=[mykey]&Operation=ItemLookup&ItemId=041554286915&IdType=SKU&Timestamp=2013-03-19T10:04:31Z&Signature=[this-is-what-I-need]

Graham has, but hit github repo for it seems to be empty. Not sure 
where he has it posted now.

Thanks Gregg - I'll see what he knows :)