World: r4wp

you get that vid error because you are referring to it before the 
layout function has run.

GrahamC, It was simpler than that. The program I am working on has 
over 1300 lines of code, and I mis-typed a variable name! So it turns 
out I was trying to access a word that did not exist, was not defined. 
I'll remember that for next time. (Yes, there will be a next time). 
Thanks for all the help. I am beginning to feel competent programming 
in Rebol2.

Caelem, D'oh moments are possible in any language.
I once wrote
    return: true
rather than
    return true

The protracted debug session that followed taught me the value of 
protect-system.

Hi I am trying to replicate this in Rebol: http://www.alistapart.com/articles/succeed/
I have the redirect setup but I want to know what url the user entered. 
Where can I get $DOCUMENT_ROOT.$REQUEST_URI ??

If you are using REBOL in CGI mode:

    get-env "DOCUMENT_ROOT"
    get-env  "REQUEST_URI"

Thank you, this works! I found and old conversation on ALTME this 
afternoon but that could not convince me being the answer, this answer 
will replace the old one. (I even typed get_env the first time). 
And for completeness I will write how to use it (cut and paste code) 
requestedurl: get-env "REQUEST_URI"

And the next step get-env "SCRIPT_FILENAME" 
guess I will have to post the complete script when I finish it.

These values are already processed by REBOL when it is started in 
CGI mode. I'm using
	cgi: system/options/cgi
The request URI is then in cgi/path-info

The script name is in cgi/script-name or something like that

Hi Kaj, wish it was that simple. I have put some strings into action 
and you can view the result here http://arnoldvanhofwegen.com/rebol/doesnotexist.html
Well as you can see path-info is none.

The script name is the script name of the script that is being executed, 
I knew that one already I redirected to it, not the requested page.

Ah, so REBOL does follow the major rule of other software: it does 
everything except the thing you need

Found some code/documentation about playing a sound (wav) on www.rebol.com/docs/sound.html 
 

but although rebol/view 2.7.8 (Win XP) has Sound 1.4.0 on board it 
seems using the sound:// port is reserved for use by the SDK version? 
** Access Error: Cannot open sound
** Where: halt-view
** Near: sound-port: open sound://
on MacOSX I get
** Access Error: Invalid port spec: sound://
** Where: halt-view
** Near: sound-port: open sound://

But that is less surprising since there is no Sound module available 
there.
So what is Sound (1.4.0) about?

Kaj is right again

Sound in REBOL is primitive, but I thought it had been in the free 
versions for many years

Did you initialise events like the doc says?

could be a rights issue? That the port may not be freely accessible.

That was a long time ago, and it should say "Feature not available 
in this REBOL"

Arnold, I've been using sound in a recent app with 2.7.8.3.1 with 
no issues (on XP too). I use a version of Nick's code http://musiclessonz.com/rebol_tutorial.html.
Look for "play-sound"

this works for me on free version of View: (XP)

sound-port: open sound://
play: func [file] [
 wait sound-port
 clear sound-port
 insert sound-port file
 wait sound-port
]

yes enabled in View. not core (like all /pro features) .

Ah, is that the problem again. Sigh

An answer in a not web public group -> Chit chat

Somehow indeed I managed to mix up core and view console so sound 
did work afterall. Sorry for the noise :( 
But still a wish for sound in REBOL on other platforms.

in R3 we can add sound support via the host-kit, but its not as good 
as it could be because we cannot add devices and/or any new type 
of event to easily (asynchronously) signal audio-related events.

Devices cannot be added?

Not at the moment, as far as we know. At least if there's a workaround 
noone has figured it out yet. You can signal asynchronous events 
with callbacks though, afaik.

I never realised, because I only looked at them in the C code. I 
suppose devices can be added there, but not yet afterwards from REBOL

They can't necessarily be added in the C code either. IIRC the devices 
table is fixed-sixe and allocated in the core code. I welcome evidence 
to the contrary.

even the event list is a hard-coded list.  which is part of the problem.

there is no device code in the host-kit (which is the C api to rebol)

callbacks do have issues which make them unusable in the real-world 
IIRC (its been a while)

wasn't there a bug wrt errors and stuff like that?

There was a plan to make device extensions, but Carl didn't know 
what API to use. He did a callout for advice, but that didn't get 
much response.

There are bugs and design flaws in R2's callbacks, but I'm not sure 
there still are in R3's. Robert's group uses them IIRC, and might 
have fixed the bug. They'd have to chime in here.

people who where able to help did respond and he liked a few of the 
ideas, he just never acted on it or actualy start a real discussion.

I thought devices were always built on top of extensions. Anyway, 
the devices are in the host kit, about six of them

you can only implement the devices which are built-in, you cannot 
add your own.

OK, but the implementations are in the host kit

All of the implementations of the current devices are built into 
the host portion of the C code, but are not made with extensions.

As far as I know, Saphirion hasn't been able to solve the threading 
and callback problems

yes, cause they are platform dependent.    

The latest host-kits merged two projects... the command! interface 
(extensions) and the platform abstraction (host)

IIRC they had some success with the pattern of using a callback to 
signal R3 to grab data using a synchronous call.

to allow full (run-time) extensibility of R3 as it is, it needs two 
other apis:
-a decent event registration mechanism (add new types and specs)

-a device registration system (so we can link schemes and protocols 
to them).

Hm, my Atari 8-bit already had that. I guess that's progress these 
days

I must admit that if you can receive events in the host, you can 
just execute a code string within the root ( just like if one enters 
a command in the prompt).   It worked very well for interfacing with 
GLUT ... I had just built a little pseudo event system which I called 
from within the glut callback and it was fast enough to handle all 
events in real-time.

How can I convert an integer! that is a pointer to a C struct returned 
by a library function to a binary! ?

With more C code that copies the binary to a REBOL-allocated buffer. 
You can't deallocate a pointer in REBOL.

I mean dereference.

Will this work?

    LPINT-def: [value [integer!]] none
    LPINT: make struct! LPINT-def none

    make-LPINT: does [make struct! LPINT-def none]

    get-dereferenced-data: func [

        {Given a pointer to memory, copy the target data into a REBOL struct.}
        pointer [struct!]   "LPINT structure"

        struct-def [block!] "Contains a sub-struct that is the real struct 
        you want."
        /local struct data orig-pointer result
    ] [

        struct: make struct! compose/deep/only [ ; make wrapper struct
            sub [struct! (struct-def)]
        ] none

        orig-pointer: third struct              ; store original inner pointer

        change third struct third pointer       ; change inner pointer to 
        ref'd data

        data: copy third struct/sub             ; copy data from the inner 
        struct
        ;print mold data

        change third struct orig-pointer        ; restore inner pointer

        result: make struct! struct-def none    ; make result struct

        change third result data                ; change data in result struct
        ;probe result
        struct: data: orig-pointer: none
        ;recycle
        result
    ]

It's from some old code, so no guarantees.