World: r3wp

first convertion does not work...

negative version is correct too, no? Mine form-decimal returns the 
same ...

sorry, Pekr's version...

should it not be 0.00417?

ah, yes, it is buggy. "4" somehow disappeared :-)

amacleod - the fix is easy - just replace "insert tail tmp rest" 
by "insert tail tmp join main rest"

Thanks Pekr...I did not have time to look at it but I''m working 
on an app that need this function. Thanks.

What's the easiest way to convert from money! back to decimal or 
integer?

In r2:
>> second $12.33
== 12.33

Ok, I see...its a combo of string and decimal..

I think I asked this before or figured it out but now the mind has 
lost the answer. I build strings (via a join) that reference existing 
objects.  Obviously the joining part is easy but of course I end 
up with a string.

>> to-path "a/b/c"
== a/b/c

Graham, here's the issue: I have some vid objects such as ua-fname: 
field. They follow a pattern in that the "ua" stands for "User Add" 
and the rest corresponds to the actual field name in the DB. The 
function I am writing is created in a way to be very generic and 
knows how to handle an insert into the DB based on a few parameters. 
What I am looking for is a way to "create" a name by joining "ua-" 
and field name which refers to the actual vid gadget.

fldname: do join "ua-" db-field-name

Graham, you are the man. That works perfectly. Thanks for the info 
and saving me a ton of time.  That's one of those "How in the world 
did you know that?" things to me.  I guess that "do" says "What does 
this mean to me?" - the "me" being Rebol . I appreciate your help 
(once again).

James it works because data is code

Has anyone extended the FOR* funcs to have special handling options 
for the first and last elements?  Gab's power-mezz, and an idea from 
another template generator made me think of how I do that today. 
Here's the basic idea:

forskip+: func [
        "Like FORSKIP, but with local FIRST? and LAST? support."
        [throw catch]

        'word [word!] {Word set to each position in series and changed as 
        a result}
        skip-num [integer!] "Number of values to skip each time"
        body [block!] "Block to evaluate each time"
        /local orig result
    ][

        if not positive? skip-num [throw make error! join [script invalid-arg] 
        skip-num]
        if not any [
            series? get word
            port? get word
        ] [

            throw make error! {forskip/forall expected word argument to refer 
            to a series or port!}
        ]
        orig: get word
        use [first? last?] [
            first?: true
            last?:  false
            body: bind/copy body 'first?

            while [any [not tail? get word (set word orig false)]] [
                if tail? skip get word skip-num [last?: true]
                set/any 'result do body
                set word skip get word skip-num
                first?: false
                get/any 'result
            ]
        ]
    ]

b: [a b c d e]

forskip+ b 1 [
    if first? [print 'first] 
    print b/1 
    if last? [print 'last]
]

FIRST? seems like HEAD? with an assumed parameter, and LAST? seems 
like SINGLE? with an assumed parameter.

SINGLE? is in R3 and will be in 2.7.8.

The idea is that it could apply to all the interator funcs, so you 
don't have different types of checks for FOR/LOOP/REPEAT, FORSKIP, 
or FOREACH.

And LAST? wouldn't be like SINGLE? in the context of FORSKIP with 
a bump value other than 1.

Ah, good point. Too bad we can't write mezzanine loop functions in 
R3 yet :(

Can the R2/forward stuff be used with 2.7.6 or does it require 2.7.7 
?

I think you said you were aiming for 2.7.5

I'm aiming at 2.5.0, but I've only hit 2.7.5 so far.

Much of the R2/Forward stuff has been incorporated into 2.7.7 already, 
and most of the rest (except maybe 3 functions) will be in 2.7.8.

It's a good thing the Power Mezz package is license compatible too, 
since some of those seem like good, non-disruptive adds.

Ok I'll see if I can use them inside the sdk...

I've been writing stuff using R3 functions ... and it seems a waste 
of my time to rewrite for R2

That's why I wrote R2/Forward in the first place :)

The R2/Forward functions that are unlikely to be incorporated in 
R2 directly are APPEND, REMOLD and LIST-DIR; the first two because 
they demonstrate the problem with adding too many options to a function, 
and the latter because it isn't good enough yet, even in the R3 version.

Watch out for native functions that already existed in R2 and which 
were changed in R3: Those changes haven't been backported.

oh .... nothing straight forward

There aren't many native changes in R3 except architectural: R3's 
main changes:

- Fixes the off-by-one error for PICK and POKE (and path indexes) 
of non-positive indexes

- Ordinal functions now return #[none] on out-of-bounds rather than 
throwing an error
- Expansion of capabilities of FOREACH, subjects of SELECT

- Datatype conversion changes, mostly minor except to/from binaries

- Removed "features" that were more trouble than they were worth, 
and have been replaced by new features (backported)

- Removed features that haven't been replaced yet (like [throw] function 
attributes)
- Major changes in the port and GUI models and PARSE

Note that the off-by-one error of AT with non-positive indexes probably 
won't be fixed.

CureCode dismissed tickets are a good place to start - most of those 
were requests for R2 compatibility where inappropriate.

I apologize - most of the CureCode dismissed tickets are requests 
by meijeru for consistency. Only some are compatibility requests.

is there a listing of changed natives?  I rarely find that they make 
things better, if they change the api of a function.

There hasn't yet been a final list, but someone (probably me) should 
go through CureCode and make a draft list in DocBase. And there's 
the change list for the releases too, though that is mostly CureCode 
references.

Almost all of the changes have been for the better, though some were 
mostly for greater consistency. Changing the API is OK if the old 
one was really bad, and if there is a rationale for having any change 
be OK. For instance, changes are much more restricted in new R2 releases 
since the continuing existence and development of R2 is the justification 
for allowing the more radical changes in R3.

if it means I have to revise 5 MB of code, any change isn't welcome 
 ;-)

unless I have a  precise list of changes so I can quickly detect 
side-effects.

In theory, the combined test suite and combined docs should tell 
you the differences. When I get the time I can compile a list of 
relevant CureCode tickets.

We really need a simple list of changes compiled in a single file, 
I have no clue how and when the process of 2.7.7 occured, and really, 
I've got A LOT of other "cats to whip".


FYI, this not a negative comment, just stating that unless someone 
builds a (similar to prior versions) simple list of all changes, 
I won't be able to use 2.7.7... as previous versions have bitten 
me, I can't risk running code in an untrusted environment... I feel 
others with serious tools and services might feel the same..  a single 
little change change cause havoc like data destruction which is only 
apparent, once the process is done.

(same for 2.7.8) 


the point being that all the effort going into it ends up being wasted 
on the most serious users.

There were no changes in 2.7.7 that would cause semantic blowups, 
unless your code would fail when any of the new words are defined. 
The same will be the case with 2.7.8 (except the LATIN1? and ASCII? 
functions will no longer work poorly). I was just waiting for Carl 
to get done with the web site changes so there would be a place to 
put the release notes - they're already in the blog comments.

ok, perfect.

The blog comments here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments