World: r3wp

Software conforming to general open source and GNU conventions has, 
often standardised, options to appoint all these locations, at build 
time or at run time

Thanks for the detailed review. I think I will need to work on an 
abstraction layer for files location in all possible cases: sources/binary 
x platforms.

I'd hope it would be quite simple, but I don't how the encapper works

don't know

It is absolutely not simple:
- Cheyenne binaries use a memory-based virtual file system.

- When run from sources, files internal relative paths depends on 
where the REBOL binary is run from.

- REBOL on Windows has 2 different working folders (one for REBOL, 
one for the system), while on UNIX, it seems that there is only one 
(from the REBOL POV).


Make a cross product of items and you'll have all possible combinations 
to manage.

Bummer

I would like to take this opportunity to clean up things and hide 
the low-level mess under a unique abstraction layer.

I think I will make a new virtual filesystem for Cheyenne that will 
abstract all files accesses (including web sites). This would have 
the additional benefit of allowing to encap web sites files too (a 
feature I wanted to have since a long time).

This is quite a big change, so will need several steps to complete. 
I will first just patch the current way to allow relocating config 
and error files for UNIX users.

can we start out with a documentation / sample implementation 1st, 
please?

it sounds like a project which can be very well reused in other cases 
too.


i've outlined the mentioned directory areas here: http://piratepad.net/KkvkZ9AtME

Thanks for the summary. I need to study every cases first anyway 
and find a clean and simple way to implement it. My first idea would 
be to use a custom scheme for that, like vfs:// that would resolve 
all virtual paths transparently.

Does the encapper modify the file scheme? Couldn't that be extended?

No, the encapper has no effect on file scheme.

File scheme is native, so no, it can't be extended.

Is the VFS in the binary your own, then?

Yes, but it is a very basic one and you need to use custom function 
calls, like: do-cache, load-cache, read-cache....

Ah, that explains the differences between the binary and source versions. 
It would be good to neutralise those

It would also have been good if the file scheme in REBOL were hackable. 
Per-app namespaces are always useful

You'd basically get the framework Tamas wants

Any problem in computer science can be solved by adding another indirection.

Kaj: I have pushed a fix for the verbose mode making Cheyenne crash 
when running as none-root. It works well here on my Linux box. Let 
me know if you have other issues (locally generated files issue aside).

btw, http://equi4.com/starkit/index.htmlis an encapping solution 
for tcl.

i just accidentally saw it mentioned in a rebol blog entry: http://www.rebol.com/cgi-bin/blog.r?view=0375#comments
 :)

TCL has a capable VFS, similar to REBOL

Doc, it works, with -vvvvvv and even when I've run it as root first. 
It can't create all its logs then, but at least it doesn't crash. 
Thanks again!

Doc, trying to start cheyenne   on win7 with UAC enabled, I get this 
error message: 

You need administrator rights to switch to Windows Services mode 
!
   

thing is I've never tried to switch to windows Service mode!!!


a part from the warning popping up the rebol console, the app seems 
to work ok.

this is with all releases I've tried, including the v142 release.

the warning popping up the rebol console
 Are you running it from sources?

yes

Looking at the sources, I've found a code path leading to this error 
msg where the internal /quiet refinement is not honored. Fixing that.

stupid question, can the source version run as a service, or only 
the binary one?

IIRC, you can run it from sources too. Instead of putting cheyenne.exe 
as the service target, it will put rebol.exe.

But you might have issues with paths.

Max: fix released.

thks.

11/5-23:48:50.843304-[HTTPd] Trying phase url-to-filename ( mod-static 
)

11/5-23:48:50.843599-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [cfg/root-dir req/in/path req/in/target]
    where: 'rejoin
] !

any idea what can this be?
im not sure how to interpret the error message

(and why can't we see a line number for the error, btw?)

Is your configuration complete? Seems like it may be missing the 
root dir

hm... i thought i wrote a message before the previous one or rather 
together with it... :/  or i just imagined... possible. i was tired.

ah, i wrote it to my collegue then forgot to write here too

so the issue was:

i had no default vhost defined and i was accessing a non-defined 
vhost.


but kaj, how can u read what u've just said from this error message?

those args are completely fucked up too. there is a lit-word of a 
datatype's name but without an exclamation mark, then comes none! 
as lit-word, then comes none as ... i don't know for sure, as a value?

It says cannot use path near cfg/root-dir, so that seems to me to 
mean that the configuration lacks a root-dir :-)

>> cfg: none
== none
>> cfg/root-dir
** Script Error: Cannot use path on none! value
** Near: cfg/root-dir

like this?

Almost. cfg is probably defined, but not the root-dir in it

>> cfg: []                
== []
>> cfg/root-dir           
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir

it would be like this, wouldn't it?

Ah, maybe cfg is completely lacking, then

but why am i not getting such a nice and descriptive error?
btw, i was trying to catch this error, but no luck:
>> e: catch [cfg/root-dir]
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir
>> e: try [cfg/root-dir]  
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir

how can i get this as an error object, do i can explore?

I think you're focusing too much on the details. I never noticed 
all those ' and ! :-)

If you would FORM that error, it may be a bit more like English. 
Or at least in R3

:) i've been told im too meticulous or what

I notice that most programmers have a tendency to loose sight of 
the wood for the trees