World: r3wp

Basically the same as a year ago, but it includes RebDev now

Lots of core changes, many new mezzanines, some new bugs, some old 
(don't know which the DIR? bug is).

Janko;  It you are diving into Cheyenne RSP, make sure you give QuarterMaster 
a look see.  http://www.ross-gill.com/QM/

Chris, like Nenad, is counted among the unsung heroes of the world, 
in my humble opinion.

btiffin: thanks for letting me know, I was checking out QM a little 
and Chris has helped me few times here already... but about the frameworks.. 
I don't like to use (mvc) frameworks , in any language

I agree Brian, Chris is definately one of the REBOLers I most respect 
as well.  He has done great stuff with REBOL.

load %dev.jpg returns error load-jpeg has no value, must be defined 
by hand somevhere?

Pavel, jpeg loading is not supported yet. this will be available 
through media types, which are not yet done.

This means it is not possible to run old demos any way?

I better let BrianH respond to that one. I'm not sure how LOAD has 
changed since early R3 versions.

In early public Alpha the GOB demo has been running nicely

LOAD has gotten more compatible, but I left the reference to LOAD-JPEG 
alone. If there is no more LOAD-JPEG function that is good to know, 
since the whole reeason for that function was to give us something 
until the media loaders were done.

You're right, it's gone. The new GUI uses Draw for its elements, 
so the loss might not have been noticed. I'll check.

It's not entirely bliss yet, as there are problems with MAKE IMAGE!. 
Hence the strange blueish checkerboards in my screenshots of color 
sliders.

Are you using REBOL to make the screen shots?

No, this is internal to REBOL. RGB values are incorrect in the image 
data that is produced from MAKE IMAGE!.

it should be in curecode somewhere.

#504

Please check. I need help testing graphics bugs - I'm not that good 
at recreating them. I'm much better with core bugs.

it doesn't really need any graphics as you can study the problem 
in console :-)

Yup, the problem still exists in current builds. Reviewed.

also #505 and #503 should be reviewed

(also possible from console)

Just did, and they look related. I think MAKE IMAGE! is hosed - it's 
probably a good thing we don't have LOAD-JPEG at this point.

As an alternative to DIR-EXISTS? and FILE-EXISTS? we could change 
EXISTS? so it returns more information.

; R3 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    select attempt [query target] 'type
]

; R2 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    unless error? try [
        target: make port! target
        query target
    ] [

        either 'directory = target/status ['dir] [target/status] ; To work 
        around a current incompatibility
    ]
]


EXISTS? could still be used in conditional code, with the exception 
of AND and OR, but would have more info if you need it.

(And AND and OR could still be done with ALL and ANY, probably what 
I would use in preference anyway.)

I've almost never seen EXISTS? used with AND or OR, though I rarely 
see AND or OR anyways. You can always use FOUND? or TRUE? if you 
want to turn it into a logic value :)

There are a couple *? funcs that don't return logic!, but the trailing 
? nearly always indicates a simple predicate. I can see how this 
might be useful, but also how it could trip you up. I can't complain 
too much though, since I've written my own *? mezzanines that don't 
return logic!.

my logic for xxx? is that it either means is-xxx? or get-xxx

eg. length? instead of get-length

(you are "asking" the object in both cases. "are you xxx?" or "what 
is your xxx?")

I've always found AND and OR not very rebolish, maybe because they 
can be infix (operators), where ALL and ANY are prefix (like functions). 
And you often need parenthesis, when used infix:

>> or 1 = 2 2 * 2 = 4
== true
>> 1 = 2 or 2 * 2 = 4
** Script Error: Expected one of: logic! - not: integer!
** Where: halt-view
** Near: 1 = 2 or 2
>> 1 = 2 or (2 * 2 = 4)
== true

Somehow I feel better about ANY:

>> any [1 = 2 2 * 2 = 4]
== true

and ANY is faster!

Well, we really need the information returned by the EXISTS? function 
above, and my last attempt to get that information out in a R2-R3 
compatible way (the above *-EXISTS? functions) got a lot of complaints 
(mostly from Gregg, as I recall). This is hopefully a less annoying 
change, and is compatible now even without the 'dir tweak if you 
check against 'file instead.


My opinion of the *? functions that are meant to be predicates is 
that they should be usable as predicates, but don't necessarily need 
to be simple predicates. As long as you can use them in IF statements, 
they're fine. We have methods to convert from REBOL truth values 
to logic! if we need to.

I don't understand the problem with the functions we have regarding 
this in 2.7.6.  Can someone summarize the issue?

Sure. In REBOL 2 there are 2 functions, EXISTS? and DIR?, that check 
for whether a file! refers to an existing file and whether the existing 
file is a directory, respectively. Both of these functions wrap around 
QUERY, a low-level native that works very differently between R2 
and R3, mostly because of the port model change. In addition, DIR? 
has a design shortcoming in R2 (mentioned in CureCode ticket #602) 
and both DIR? and EXISTS? share the same bug in QUERY in R3 (#606, 
affects #602 and #604).

All of these combine into a few problems:

- People who want to write file and directory management code that 
is portable between R2 and R3 have trouble doing so.

- Bugs of the kind mentioned in #602 are not likely to be fixed in 
R2, so we have to consider DIR? broken for non-existing directories.

- Using both DIR? and EXISTS? means two QUERY calls, which has overhead, 
particularly for networked files.

- Attempts to get around this using QUERY require completely different 
code in R2 and R3, so wrappers would be nice.


As it specifically relates to 2.7.6, for people who don't care about 
forwards compatibility, there is only one problem:
>> DIR? %nonexistingdirectory/
== false  ; Should be true, unlikely to change

Also, R2 and R3 could use a standard function that does the opposite 
of DIRIZE. Current proposed names are UNDIRIZE or FILEIZE.

Why do we need an undirize when it is already so simply to do such?

>> a: %directory/
== %directory/
>> trim/with a "/"
== %directory

It is simple, as is DIRIZE (look at the source), but we still need 
it.

Sounds like bloat to me.

No bloat in R3. Modules get rid of the bloat. If you don't want it, 
don't include it.

Just seems there is better to focus on than that.

How about working on fixing it so we can modifiy the dates on directories. 
 That would be way more important.

Who says I'm focusing on it? It was less than 5 minutes of work.

Yeah but doesn't sound like your done to me.

With undirize? I am done.

I can't fix problems like modifying the date on directories - that 
is native code, and I just work on mezzanines.

I sure hope all these mezzanines don't get distributed with REBOL. 
 Because even if they are still distributed as a package with the 
main bin then it is still bloat.

Rather, there be a separate distribution for just the main bin and 
then the mezzaines.