r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Oldes
4-Jan-2011
[9446]
This tools is maybe better http://technet.microsoft.com/en-us/sysinternals/bb897437
as it has gui as well
Cyphre
4-Jan-2011
[9447]
You don't need any special tool for port checking in winXP...just 
use the console NETSTAT command.
MikeL
4-Jan-2011
[9448]
Thanks. I am run Windows 7 and ran NetStat as Admin.  Some 9799 and 
other ports in use but no 9801 and 9802.  Trying  TcpView.
Oldes
4-Jan-2011
[9449]
Netstat does not display which process is using the port, does it?
Cyphre
4-Jan-2011
[9450]
Oldes, use netstat /? to get all the options...I guess -o is what 
you need.
Oldes
4-Jan-2011
[9451]
I don't need it:) btw... it's -b
MikeL
4-Jan-2011
[9452]
Thanks for the help.  R2 is listening on 9801 and 9802 now.   Next 
step is to get it to server a page.
Dockimbel
4-Jan-2011
[9453]
Since many of the 2.7.8 native fixes were done for Doc...

 Brian, where can I see this list of fixes? I guess on RAMBO, but 
 it's down since yesterday...
GrahamC
4-Jan-2011
[9454]
It says you collaborated with Carl :)
BrianH
4-Jan-2011
[9455]
I don't know what he did to make Cheyenne better, except ACCESS-OS. 
There were other native fixes to Linux builds mentioned, but I can't 
test on anything other than XP at the moment so I didn't ask for 
a full list. Given the "coordinated with DocKimbel" comment I figured 
you knew better, but that might just be the ACCESS-OS thing, which 
currently does nothing on Windows, and doesn't require an SDK. We'll 
know when the changes doc is updated.
Kaj
4-Jan-2011
[9456]
The fixes that I expect would be Library Component included in Core, 
and View being able to start without X11 running
BrianH
4-Jan-2011
[9457]
I wouldn't expect the latter, as most of what makes View different 
from Core depends on X11. Some image support might be possible in 
Core though. Agreed on the former: If /Library is free, /Pro should 
be free too.
Kaj
4-Jan-2011
[9458]
It was in the planning since a year
BrianH
4-Jan-2011
[9459]
Well, if Carl says it's possible then it is.
Dockimbel
4-Jan-2011
[9460]
I collaborated with Carl on ACCESS-OS only.
Kaj
4-Jan-2011
[9461]
What does that do?
Andreas
4-Jan-2011
[9462]
Allowing calls to getuid/setuid/getpid/kill.
Dockimbel
4-Jan-2011
[9463]
The goal was to be able to run Cheyenne with /Core on Linux without 
the need for /Library/
BrianH
4-Jan-2011
[9464]
OK. Do you have ideas for stuff it might do on Windows?
Kaj
4-Jan-2011
[9465]
Sigh... why not just include Library?
Dockimbel
4-Jan-2011
[9466x2]
/Library: I don't know.
Windows: nothing more than you.
Kaj
4-Jan-2011
[9468]
Some weird business customer consideration, I would guess. But then 
Library shouldn't have been promised for 2.7.7
Dockimbel
4-Jan-2011
[9469]
I was also a bit surprize by the inclusion of those OS natives instead 
of just freeing /Library on Linux, but I guess it's business related.
Andreas
4-Jan-2011
[9470]
I'm also surprised by the bad design. ACCESS-OS is extremly ugly. 
To kill a process:

access-os/set 'pid 29110
BrianH
4-Jan-2011
[9471]
Library wasn't in Core at all. It was in View, so that was just a 
matter of tweaking the licensing code. For Core it would mean either 
adding the licensing and library code, or just renaming Pro as Core. 
View did get Library in 2.7.7. It's not just a business thing, it's 
also a matter of time and effort.
Dockimbel
4-Jan-2011
[9472]
About the possible "fixes" that Cheyenne could benefit from, Carl 
added the helper task (for async DNS) deferred boot to workaround 
setuid issues (security improvement when running Cheyenne as not 
root user).
BrianH
4-Jan-2011
[9473]
Cool, those sound useful.
Kaj
4-Jan-2011
[9474]
There's nothing complex about keeping promises
Dockimbel
4-Jan-2011
[9475]
Andreas: I share your feeling. I guess that it's easier and safer 
to add a new native in R2 than integrate all that stuff into system:// 
port (using set-modes/get-modes as interfaces).
BrianH
4-Jan-2011
[9476]
I am in favor of releasing Pro as Core and just disabling the licensing 
code; that would give us Library on Core a lot quicker than trying 
to retrofit things into Core. R2 is quite an old codebase, so a lot 
of changes would require a huge amount of work - R3 was rewritten 
for good reasons.
Andreas
4-Jan-2011
[9477]
Probably time to move this discussion to !REBOL2 Releases.
amacleod
6-Jan-2011
[9478x2]
I can't get cheyenne to serve to an ajax json request.


I can get it to read the array as a local file but it does not seem 
to work through url request.


I played with content-type: application/json which I read was needed 
but I don't know if I'm on the right track.
For example: 
json data: 
{
  "foo": "The quick brown fox jumps over the lazy dog.",
  "bar": "ABCDEFG",
  "baz": [52, 97]
}

and the js script to fetch the data:

<script>$.getJSON('http://localhost.jsontest.cgi', function(data) 
{
      alert("JSON Data: " + data.foo);
});</script>
GrahamC
6-Jan-2011
[9480]
It works fine for me
I have in my RSP pages

Print json-data
Dockimbel
7-Jan-2011
[9481]
This doesn't look like a valid URL: 'http://localhost.jsontest.cgi'
shadwolf
7-Jan-2011
[9482]
should be http://localhost/jsontest.cgino ?
amacleod
7-Jan-2011
[9483x2]
yes...i just typed it here wrong....thanks
my local script: 
<!DOCTYPE html>
<html>
<head>
  <style>img{ height: 100px; float: left; }</style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
	

<script>$.getJSON("http://localhost/jsontest.cgi”, function(data) 
{
      alert("JSON Data: " + data.foo);
});</script>
</body>
</html>

my rebol cgi script:
#!/cgi-bin/rebol.exe -cs %s %s
REBOL [Title: "json test"]
Print {
<html>
<head>
<title></title>

<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">

</head>
<body>
{
  "foo": "The quick brown fox jumps over the lazy dog.",
  "bar": "ABCDEFG",
  "baz": [52, 97]
}
</body>
</html>
}
PeterWood
7-Jan-2011
[9485]
Alan, I'm logged in to AltME from Ubuntu - so many non-ascii characters 
get displayed incorrectly. In your script the closing double-quote 
after /jsontest.cgi doesn't display properly. Perhaps you could check 
that it really is a double-quote and not a "smart-quote" in the actual 
source.
Dockimbel
7-Jan-2011
[9486]
Amacleod: Your CGI script headers looks very wrong:
- What are those "%s" on the shebang line?

- /cgi-bin/rebol.exe: this doesn't look like a valid filesystem path

- Why the Content-Type header isn't emitted as required by CGI specification?


Maybe you should read again documentation about REBOL CGI usage on 
rebol.com site and also have a look at CGI sample scripts provided 
with Cheyenne source package. Understanding what a shebang line is 
might also help: http://en.wikipedia.org/wiki/Shebang_(Unix)
amacleod
7-Jan-2011
[9487x2]
When i go to the cgi script directly in the browser I get my json 
data displayed. the cgi seems to be working.
- Why the Content-Type header isn't emitted as required by CGI specification?

not sure what this means..
Dockimbel
7-Jan-2011
[9489]
Amacleod: 

while [not understood?][read http://www.rebol.com/docs/core23/rebolcore-13.html#section-13]
GrahamC
7-Jan-2011
[9490]
alan, if you use getJson, you expect to see an application/json header. 
 So, try just $.get instead ....
amacleod
7-Jan-2011
[9491]
That worked. I get the alert but there is an error that  "data"  
(my variable) is undefined.


Can I use use the application/json header and if so what is the syntax...do 
I just replace the the "text/html" string?
Oldes
7-Jan-2011
[9492]
I guess you should print only the JSON data, not html page!
amacleod
7-Jan-2011
[9493x2]
that works, Olds! thanks alot.
only works local though...does not seem to read from remote server
Oldes
7-Jan-2011
[9495]
what kind of server?