World: r3wp

OK, the right path for the Libc is: %/usr/lib/libc.dylib

why do we need it at all?

rebol/core can't use libs anyway, can it?

No, it can't on OS X.

but pro can no?

Pro: yes

/Library component is needed on UNIX (including OS X) to map: set-uid, 
set-gid, chown, kill and get-pid

aha... so i need /view. it would be great to insert this line on 
the download page.

or into the source code at least

but isn't it required only if i use the mod-userdir?

(which i would like to see an example about too. any urls about it?)

Carl has introduced 'access-os native in 2.7.8 to map internally 
all those external dependencies, I haven't tested if it was available 
on OS X too, doing it now...

kill( ) and get-pid( ) are needed in all cases

(running rebview -qws cheyenne.r even with -w 0 is really ugly under 
osx, because of the 2 black app icons which doesn't even have a window 
associated.... :/)

but it works with rebview. would be nice to still have a /core only 
version

there was no need for changing the %libc.dylib

The OS most probably uses its search paths to find it

Right, library loading works OK with rebpro too without any change.

It seems that 'access-os is active under OS X too. I'm adding the 
support for it right now, so that Cheyenne can run on /Core too.

so, i can't run it from source on a headless linux server, right?

that would be awesome

i will test it immediately

Dockimbel: did u get my email too?

Yes, it can since 0.9.20, thanks to 'access-os native, and it will 
in a few minutes on OS X too (requires /Core 2.7.8)

onetom: yes, I will look into it right after fixing this issue.

doc, having issues with a handler I am building.  


my mod is using send-msg (taken from the RSP mod) in the make-response().


the handler actually pops-up and it runs the proper code, I can see 
the printing in the console.

when my god gets its task-done called, it has the proper code in 
the result....
 all seems good..   :-)

except:

   the browser doesn't get the response and it hangs (telling me that 
   its waiting for the server).

any clues?

god = mod   hehehe

Maxim: r u returning true at the end of make-response?

Max: have you copied the calls to service/* in mod-rsp/task-done? 
(Will check that after fixing this issue)

I think I have found an issue with /Core 2.7.8 on OS X, the READ-CGI 
mezz is missing! That's making Cheyenne (rev 127) crash on any CGI 
script request.

I need to patch Cheyenne to workaround that.

This CGI issue on OS X crashes Cheyenne in source mode and the PRO 
binary (the CMD binary is unaffected).

sounds weired because i thought i was using it in cgi mode

bind-extern CGI to [.r .cgi]
        bind-extern RSP to [.j .rsp]

my config is like this

It crashes only if you call READ-CGI.

and u only call it when there is a POST request?

ah, ok, i see it in source read-cgi

You can call it whenever you want, but it is useful only if there's 
some input data.

I have included the READ-CGI mezz in CGI.r to make CGI work on /Core 
2.7.8 on OS X. Testing, will push it in a couple of minutes.

Changes commited to revision 128:

FEAT: added support for 'access-os native. Now Cheyenne can work 
with /Core on MacOS X.

FIX: READ-CGI mezzanine is missing in /Core 2.7.8 on MacOS X, Cheyenne 
is now supplying it in such case.

onetom: can you test the changes on your Mac? It should now work 
with /Core too.

Script: "Encap virtual filesystem" (21-Sep-2009)
REBOL - Security Check:

Script requests permission to execute a system shell command: netstat 
-f inet -p tcp -na
Yes, allow all, no, or quit? (Y/A/N/Q)

Answer: A

hmm  is it the implementation of the access-os?

cheyenne specific thing?

it starts otherwise

how can i test the read-cgi issue?

It is a Cheyenne thing to check for available TCP ports for listening.

onetome: use the default test site from the source archive.