AltME groups: search

Such as ?  I'd had to have an cgi script running and find that functions 
I need aren't included.

Max, I think that has been reported many times, eg. http://www.rebol.net/cgi-bin/rambo.r?id=4121&

Hello! I'm receiving the following error when processing a cgi form 
to send an e-mail of the response.  I correctly can send from my 
laptop, Rebol/Core -- command line, with my set-net settings in user.r 
but when I do the same thing on my hosting account I get the following 
error:

Hello!  I'm having trouble with my hosting account to send via e-mail 
a cgi form response.  I can get rebol to post the data to the page, 
I just can't get it to send the data to me via e-mail.   I'm able 
to send e-mails from my laptop but when I use the same set-net settings 
on my host account I get the following error: ** User Error: Server 
error: tcp connection failed
** Near: smtp-port: open [scheme: 'esmtp] 
either only

Hello!  I'm having trouble with my hosting account to send via e-mail 
a cgi form response.  I can get rebol to post the data to the page, 
I just can't get it to send the data to me via e-mail.   I'm able 
to send e-mails from my laptop but when I use the same set-net settings 
on my host account I get the following error: ** User Error: Server 
error: tcp connection failed
** Near: smtp-port: open [scheme: 'esmtp] 
either only

In the past I've always used /usr/sbin/sendmail to send e-mails via 
cgi but I'm lost on how to do it via Rebol.

make it a cgi script and see what is written to %log.txt

well, using a "mask" approach, allows more capabilities then just 
providing the number of decimals.

Like I've done here for R3: http://www.rebol.net/cgi-bin/r3blog.r?view=0302#comments
(see fnum)


It's true, it doesn't handle scientific notation as entry currently, 
but hey !, it should not take more than 2 or 3 more lines.

The blog comments here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments

Someone should point Carl to this, I'm pretty sure he wants to know: 
http://www.rebol.net/cgi-bin/rambo.r?id=4398&

http://www.rebol.net/cgi-bin/rambo.r

This is the bug database for R2 and before

http://www.rebol.net/cgi-bin/rambo.r?id=4018&

Only 4 years old.

http://www.rebol.net/cgi-bin/rambo.r?id=-4777&

Delete does not take a port spec

( Gabriele are you still reviewing Rambo submissions? )

this is my rebgui interface to the rebelBB.cgi script

Borrow the same hack from VID and hope http://www.rebol.net/cgi-bin/rambo.r?id=3867&
is fixed!

Graham - http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=disable-face.r


i have not thought about RebGUI integration yet, not sure it is applicable 
...

How about using Chris' script to support input-patterns: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=filtered-import.r

Daniel; Check out http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=layout-1.8.r
for a what you see is kinda what you get layout editor.   The tricks 
will be buried in the code, but it has to do with ordering the face/pane 
entries.  Also see http://rebol.com/docs/view-system.html#section-3
for a description of face/pane.

Support request on Mailing List:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlRHXC

Kinda ... maybe ... it might be a start; check out http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebdbgui.r


It's a sample I wrote for someone a long time ago.  It links the 
GUI fields to a RebDB database.  One way of doing it anyway.

I understand unset! values as an exception case where there's no 
value to work with. As such, IMHO, it should be treated as an error 
as much as possible. We should stick to the principle of least surprise. 
 

It wouldn't hurt if R3 unset! values were treated more consistently. 
But this is a deep topic, I remember that Ladislav had some interesting 
propositions about unset! (like, IIRC, removing it from user's eyes 
and keeping it internal only). While browsing about that, I've found 
a few interesting links :
http://www.rebol.net/cgi-bin/r3blog.r?view=0100
http://www.fm.tul.cz/~ladislav/rebol/rep.html#section-18

Can R3 be run in CGI mode? There seems to be -c command line switch, 
but no CGI helper functions, nor system/options/cgi path ....

I don't want to go the way of installing and configuring Apache, 
and using some scripts to test throughput in real CGI scenario, as 
R3 CGI mode is not properly implemented yet ...

At least not on non-posix platforms (Windows) from what I hear. REBOL 
CGI on posix systems (Linux, OS X) should work fine.

First docs appeared - http://rebol.com/cgi-bin/docs.r?do=sumlog

Call is pretty unusable with R3. I have to say, that some ppl could 
already move to R3, but we have few showstoppers:

- call - really bad situation ....
- missing networking protocol 
- missing CGI mode

- DB access ... now we can proceed with extensions for SQLite, but 
not sure. If call would work at least, we could at least call sqlite.exe 
;-)


Unless those issues are fixed, R3 will be in alpha stage, and my 
opinion is - absolutly unnecessarily ...

Speculating about set- and get- datatypes in relation to:
http://www.rebol.net/cgi-bin/r3blog.r?view=0229#comments


In R2, we have get-word!, set-word! and set-path!. R3 brought us 
get-path! too. Is it a good idea to have things like get-paren! and 
maybe even get-block! and set-block! ?

Carl's set-word! in a block problem could be solved with:

user: [name: "Steve" age: 38]
user/:(age:)


About get-block! and set-block!, today we can set many values with:

set [a b c] [1 2 3]

Why not just write:

[a b c]: [1 2 3]

And a get-block! like:

:[a b c]

should return a block with values like

reduce [a b c]

Just thoughts.

What do you mean by completness? IMO R3 is more advanced than R2 
already, and we are nearing beta stage =  system architecture is 
in-there, all slots in the right place. Now we need to finish few 
things, for user to be usable as R2 is:


- better console (not necessarily needed, but Windows one is total 
crap and makes experience 40% worse for me)
- fixed call
- network protocols (ftp, pop, smtp, proxy )
- ported DB drivers (done by community hopefully)

- improved parse (needed probably if we want to have DB drivers and 
network drivers done new way, but not necessarily)
- missing CGI mode
- GUI far from beta

Someone named Nick suggested having make/deep:
http://www.rebol.net/cgi-bin/r3blog.r?view=0239#comments

This could remove the need for copying contexts:

new-object: make/deep old-object [ ... ]

instead of what we have to do now:

new-object: make copy/types old-object any-type! [ ... ]

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

Because there has not been any discussion or proposals for what those 
mezzanines should be yet. There isn't even any CuureCode requests 
for such - only a request to get CGI working on Windows (it already 
does on Linux).

I have no idea what mezzanines you would want for CGI support. And 
can't really test them except in simulation, due to Windows CGI not 
working yet. What do you want?

help cgi ;-)

It won't work the same way in R3 - no system/options/cgi object.

system/options/cgi

BrianH: it is not about wasting. I just want we don't do fatal mistake 
- pretending we order users how they should use R3. R3 would be already 
used by many ppl, but is not, due of following reasons:

- missing network protocols, proxy
- call incompletness in comparison to R2
- weird console
- missing CGI mode
- missing DB protocols


No matter how your module system is usefull, if we don't provide 
users with R2 level completness, we are doing fatal mistake ...

CGI mode is only missing on Windows (and might be on OSX - noone 
has checked yet). CGI works just fine on Linux.

As for where the right place to put the CGI environment variables, 
R3 currently leaves them in the environment, and uses GET-ENV to 
get at them. When system/options/cgi was first created, REBOL didn't 
have a user-accessible GET-ENV function. You could easily write a 
REBOL function that could construct an object containing all of the 
information passed to a CGI process, but that function and that object 
would be web-server-specific.

However, you are missing the whole point of the module system: R3 
won't be as monolithic as R2, and will have fewer mezzanines, not 
more, on purpose. We are trying to make R3 cleaner than R2, and easier 
to customize for your specific use. That means less built in, and 
more added on, in some cases from a common library of modules that 
the community maintains. Non-CGI apps don't need CGI mezzanines.

I don't really know - I'd have to look up the CGI specs and write 
a script. I don't have Linux working here locally, so I can't experiment.

CGI mode runs on OS X. I ran the simple date & time test. I wouldn't 
say it works yet as the CGI environment variables (such as remote 
addr) don't seem to have been added yet.

system/options/cgi isn't likely to be added to R3 - use GET-ENV instead.

I tried the date/time cgi on Apache under Windows - 500 internal 
server error.

Peter - have you checked, that e.g. R2 works? I mean - that generally 
CGI is working for you? Just asking :-)

Some requirements:


1. It would have to be a real console, so we can't simply send CGI 
jobs and close REBOL again.
2. There would have to be a way to spawn and kill consoles.

3. REBOL 3 will have to live up to its ability to limit itself memory 
wise. CPU hogging, we can't do much about. My Linode only has 384 
MB RAM right now.

4. The Ruby console can respond to various input and display help 
text related to what you are typing. This can be used to create tutorials.

5. I have a Cheyenne on my Linode. It either has to use it or not 
collide with it, if we don't use it. Can Cheyenne use a special R3 
process?

6. Managing the console output will obviously need to be done with 
AJAX.

7. Syntax highlighting seems a little superfluous right now, so the 
target right now would be a basic console.

I am trying to do simple CGI tests, using Cheyenne, and in reference 
to following blog: http://www.rebol.net/r3blogs/0182.html

For: http://localhost/show.cgi?test- I do get:

Content-type GE te 127.0 


Why always only 2 bytes? Is that actually two bytes? I would say 
- two "elements"

The code is:

#!c:\!rebol\altme\worlds\r3-gui\files\rebdev\view.exe -q

REBOL [
    Title:      "show"
    File:       %show.cgi
]

print "Content-type: text/html^/"
print get-env "REQUEST_METHOD"
print get-env "QUERY_STRING"
print get-env "REMOTE_ADDR"
print newline

Is that R3 problem, or Cheyenne problem?

First thing I wonder about is - when you use function 'usage, it 
reports --cgi is available. Is it internally utilised at all?

You should start your kernel with --cgi in order to activate CGI 
related processing. I don't know if it is supported by R3 alphas 
yet.

I think --cgi option won't be needed in R3 since the I/O seems to 
be much closer to the shell and get-env actually is available, removing 
the need for the cgi handling by the script on launch.

I don't want to encode anything for simple CGI purposes, gee ;-)

I tested you show.cgi with Apache on OS X. It runs fine and displays 
the expected output

GET 10.0.1.198

probably why people say that cgi isn't working on windows.

Pekr: One difference when I ran the cgi was that I used the -c option 
not the -q option. Perhaps you could try with the -c option in case 
Carl has done something under the surface about character encoding.

When last I heard, CGI wasn't working on Windows yet. Thanks for 
the info - now I know why.

maybe a cgi-specific version of print could be added as a mezz which 
handles the proper encoding issues to make sure that console and 
cgi printing are both functional on all distros without needing to 
change the source.

Maybe there's a trick that --cgi could do with I/O ports.

ah yess.. --cgi could just tell the core to prevent the UTF-16 encoding 
being done on stdout...

but if we need to output latin-1 afterwards (while dumping the html 
content, for example), the output encoding  should be selectable 
as a "current default", and all the --cgi would do is set that default 
to UTF-8 for example.

I think it will depend on the OS. Use ports on Windows and CGI on 
Linux/Mac.

http://www.rebol.net/cgi-bin/r3blog.r?view=0148#comments

Carl asks about the change of insert/remove/change semantics, upon 
Steeve's comments - http://www.rebol.net/cgi-bin/r3blog.r?view=0254#comments

I think, that everybody is waiting for your go. I think that most 
ppl here prefer you working on Core. Most of devs here will prefer 
complete Core, along with parse, extensions, host code released, 
networking protocols, cgi, console and especially some FIRST words 
on concurrency ...

In one blog thread I pretty much outlined, what really is important 
for ppl. Features at least on pair with R2. Some of them more than 
others:


- CGI - not working under Windows (unicode problem with print -the 
header has to be in ASCII?)
- fixed 'call
- networking (BrianH plans to revamp Schemes)

- console (well, maybe we can live with the current one for a while)


- Some guys are screaming for first words of concurrency. E.g. Doc 
could start with port of Cheyenne - premium REBOL product. Not so 
with missing protocols an concurrency not in place ...

My summary for what defines the beta is in my 3 posts here: http://www.rebol.com/cgi-bin/blog.r?view=0424#comments
... and even Concurrency is missing ...

R3 will run as a CGI under OSX though, it doesn't yet do so on Windows.

i don't understand the "it will work as cgi ..." does it means outside 
an apache server and through a html page rebol won't work ? then 
rebol would be something like a custom php ?

REBOL3 cgi scripts don't work on Windows (under Apache or IIS) but 
do run on OSX (under Apache).

Henrik is referring to this blog entry:
  http://www.rebol.net/cgi-bin/r3blog.r?view=0258

I like that effect - it's what makes CGI work on Linux.

And the lack of that effect is what makes CGI not work on Windows 
(in addition to Unicode issues).

Make the shift in response to the --cgi option.

CGI output should be binary, and the headers output in 7bit ASCII 
(not UTF-8) through that binary output.

--cgi option is not working now, or is it?

Any encoding is none of the business of the CGI channel - it is a 
matter between the script and the cliennt.

The --cgi option is not working on Windows. It works on Linux.

That should be fixed, no? :-) I want to start to do some tests with 
CGI, and no will to mess with Linux here :-)

I mean that there should be a header output function that is loaded 
in the CGI module. HTTP header format is cross-platform, even down 
to the line endings. The header output function could be mezzanine.

What do you think about CGI module or any such special modules - 
would you make some of them default part of the distro, just modularised? 
Or you want them to be external? I think that CGI is basic functionality, 
which should be included in default distro, just with better support 
for sessions, not just decode-cgi, read-cgi ...

CGI is a part of the default distro for R3 when used to run CGI apps, 
but completely useless for other apps.

Session support is specific to the web server - the CGI standard 
doesn't handle them at all.

Per Twitter message, Carl seems to be working on interesting topic 
- Improving standard I/O to allow R3 to be used with redirections, 
CGI and other purposes.

S: I'm not sure what you mean. Here's the story:


There are some modules, like CGI, that do not need to be initialized 
unless needed. Those would be "bundled" into the exe, but would not 
init unless they are required.  That way, no extra space (or boot 
time) is needed for them when not used.

Anyone with C-level knowledge being able to help here? If we don't 
resolve it, then it will stay like it is ... http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments

the /utc time is VERY usefull... I've had to deal with this in cgi 
and its not fun at all to have to manage it manually... but the discrepancy 
between /hour and /time  and the fact that the window where /hour 
and /day don't match makes this a non-trivial problem, and actually 
makes the date! type inconsitent.

Hmm, according to Carl's comment in following blog comment section, 
it seems we are not going to get SSL in an easy way, unless someone 
from community does it :-( .... that is bad, as it might never come 
.... http://www.rebol.net/cgi-bin/r3blog.r?view=0290#comments

I plan to use R3. I defined what makes R3 beta a good release, and 
adressing 'call is one of those points. CGI/IO was already adressed.

Ok, got it. More info here:
http://www.rebol.net/cgi-bin/r3blog.r?view=0297#comments

no help on decode-cgi either ... 
is anyone using R3 for CGI ?

Q: "is anyone using R3 for CGI ?" 
A: The new REBOL.com website is based on R3 CGI.

SVN update to revision 8 :

	o RSP: response/redirect improve (see above)
		  
	o RSP/CGI: default no caching headers changed to:
	
		Pragma: no-cache

     Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Doc - does Cheyenne already enable setting handlers for particular 
filetypes? I mean - equivalence to:

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi


For Cheyenne only users, it is not important, they can use RSP, but 
for those who want to have chance to migrate between Apache and Cheyenne 
in CGI mode, it might be usefull. I expect it not being a priority 
for you though ...

Currently there's only URL=>script aliasing available, but looking 
at the ALIAS code, I think that : 
	alias ".html" /cgi-bin/rebol-cgi-dispatch.cgi

might work (need to be tested). Do you really think that there's 
much users waiting for that feature?

Doc - I don't know. But how I got myself to such a solution? Simply 
put - I never got past CGI usage. It is quite comfort and OK for 
small to middle sites. But I wanted to have also index.html being 
a dynamic site, not just some /cgi-bin/my-subpage.cgi?here ....

The scheduler doesn't spawn any new process by itself. When you specify 
an action, you can use CALL or LAUNCH in the action code to run your 
task in background. You can also use a URL pointing to a local CGI 
or RSP script (making it run in the background using one of the task-master 
worker processes).

Phpmydamin: yes I'm using it sometimes, since PHP support has been 
added. Mostly on Windows. I don't remember seeing the DOS window 
popping up for PHP scripts. Maybe you've used PHP in CGI mode with 
Cheyenne?

I want to try to plug R3 into Cheyenne to test CGI under Windows. 
I can't understand, how Cheyenne handles CGI though. I can find handlers/CGI, 
where it does some strange stuff. First and foremost - the shebang 
line is ignored, yet CGU it works - you can entirely delete it. I 
can get shebang section evaluated only if I delete REBOL header. 
This is confusing for me ...

Does Cheyenne call somehow internally default installed REBOL interpreter 
on your machine? Or is CGI handled by one of spawned processes by 
the interpreted instance, running the CGI? I simply want it to order 
to use my own interpreter :-) OK, will try with Apache, that will 
be clearer ...

Do you use any specific dialect for IPC, or just some basic parsing 
methods? Those questions are just theoretical. Now I am more interested 
into how do I let Cheyenne use R3 for CGI process, instead of R2, 
just to do some testing?

CGI handling: two different strategies are applied :


- if the target script is a REBOL script, the process is already 
a REBOL session, so no need to start a new one (and avoid the startup 
cost, so you get FastCGI speed). Shebang line is ignored in that 
case.


- if the target script is not a REBOL script (no REBOL header), classic 
approach is used: setting of environnemental variables, CALLing executable 
from shebang line, sending input, catching output,...

Hacking CGI.r seems easier. Just patch it to avoid REBOL header detection 
like this: 

script: none		; <= add this line to force classic CGI 
either all [
	string? script
	not empty? script
][