World: r3wp

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
At revision 127.

I'll boot my Mac 10.6 image (takes some time) and test it from source.

Will probably do that in a couple of hours (after lunch).

good apetite, im having lunch-dinner too. tom yam kung soup. i'd 
be happy to invite u to have some :)

I would be pleased, but unfortunately, Phuket is a bit far from Paris. 
:-)

half a day... think about it ;)

Dockimbel: i sent u an email with some background story which can 
help to think about a good solution

feature request :  I would loke to have some configs (in httpd.cfg) 
for controling things like the verbosity and logging.

i would help making these patches but i can't run cheyenne (on a 
mac) from source. can u, maxim?

I'm just doing windows these days.

Cheyenne source & OS X: I can reproduce the error. Looking for the 
cause...

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.