AltME groups: search

Daniel;  Try http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=cgi.r
 for some code.

And http://www.rebol.net/cookbook/recipes/0026.htmlfor a REBOL sample 
solution  and then wait for the rest of the forum members to pipe 
up with 'bigger better' solutions, and they will.  :)

Thanks for the help. The recipe from the rebol cookbook show you 
how to upload a file provided the server runs a rebol script too. 
The server I'm uploading a file to doesn't. It expects multipart/form-data. 
Maybe the %cgi.r by Cal Dixon provides a solution. I'll investigate 
further. More hints will be appreciated, as well...

In that ML thread, the request was to handle a multipart upload on 
the server side (in rebol). I need to perform a multipart upload 
on the client side (in rebol). As for the seconde link, unfortunately 
I get "Article x60 is no longer available ". Any idea?

In other words, the rebol script has to send values to a form on 
the server issuing something like that in the header: Content-Type: 
multipart/form-data; boundary=----------6l5Xq9lJYPaaypknAH8Des etc. 
Surely someone has done this before (I hope)...

I don't know if it helps, but I did write a web server stress test 
that did a http upload of hundreds of images in Rebol that year.. 
but the scripts are long lost.

I used a variant of the http-tools.r script, composed the correct 
header, and then insert the headers, and then switched the port to 
binary before inserting the payload

Ok, I'll try to hack the http-tools.r, see if I can get anything 
done. I saw a script written in python claiming to do multipart uploads, 
but I hope I can get it working in Rebol, which for me is always 
first choice.

I played with Oldes script a bit, didn't get far. I think there's 
no other option than follow Graham's advice and delve in the http 
scheme. I had hoped to find something in the script archive, oh well... 
I saw that even in the Ruby and Python community there's some confusion 
on how to achieve multipart form submissions with CGI. (Python default 
http library also uses  "application/x-www-form-urlencoded" and not 
""multipart/form-data", but there's a library called HTTPFileUploader 
that does the job). Last time I tried to hack the http scheme I wasn't 
so succesful. This time, if I need help, I'll ask for help.

do you need to write binary, or a multipart?could be multipart can 
use base64. then its somewhat bigger, but has no problems with text-mode. 
could even be that multipart of email works the same. in that case 
there is 'build-attach-body.

The script should be able to post a multipart form as described in 
rfc1867. It should be able to post a number of fields, for example: 
Content-Disposition: form-data; name="userid", and finally it should 
be able to upload a file in binary data.

Graham described what needs to be done (I used a variant of the http-tools.r 
script, composed the correct header, and then insert the headers, 
and then switched the port to binary before inserting the payload). 
Only it's a little a bit above my capacities. In other words, I'll 
need two weeks to do it, if I ever manage it.

Graham, I'm a big fan of http-tools.r (I believe you wrote it,right?). 
I used it in my DYNdns client that I wrote in Rebol. I realized only 
recently that some of the functionality was built-in.(Basic authenticaion 
with read/custom). Grrrr... if only you hadn't thrown those upload 
scripts away :)

Daniel, I wrote http-tools.r before there was a read/custom .. that's 
how old the script is!

Undocumented .. but basically it took a directory of jpegs and zip 
files and uploaded them to a java based webserver that required custom 
headers

And the good news is: curl does it flawlessly. I just saved myself 
two weeks of headaches. I am a reboller, but not a purist, if I find 
a better tool to do something, that's cool with me.

Anyone know the answer to this one? 

I have a cgi script that sends an email out. The problem is that 
I want to send to an address that has the same domain name as the 
website but whose mail server is not located there (It's an Exchange 
Server). Any other address works fine as expected. I think it has 
to do with the mx records but, the weird thing is that if I generate 
an email via php, it goes through. Therefore I'm thinking Rebol can 
do it too. 

I've used set-net  for the smtp server and have set it a different 
server completely but still no go.
And I'm in the process of having the MX records changed.

I mentioned the possibility (to overcome REBOL web-hosting) to place 
rebol executable directly in the /cgi-bin/ directory. Someone on 
ML mentioned I should not do that, security wise, as calling http://www.my-domain/cgi-bin/rebol
will spawn a process, which will run endlessly or so ...

My understanding is the latter would be slower.  Also, QM (as an 
example) doesn't generally require a get query or post data (primarily 
uses path info).

making rebol accessible is a security risk. i don't know of anything 
bad that you can make it do, but i'm sure it would not be too hard 
to make any interpreter do something bad if you allow it to be launched 
by anyone :)

What I have found to be a problem is accessing MySQL accounts from 
client based rebol scripts. They seem to only allow server based 
access.

I have a rebol view app that I use to acces a MySQL database. I had 
it working  and then ,y ISP decided to add security and no longer 
allow MySQL access unless its a script on the server. Ofcourse they 
did not inform me and it took some time to track down the problem..

www root - well, you can put in www but outside cgi-bin, so it can 
be downloaded but not executed. or, worst case, hopefully they allow 
you to put a .htaccess to deny access to rebol itself.

OK, I feel I miss knowledge on Unix permissions. So if cgi-bin dir 
as a whole has execute bit, everything in there can be executed? 
Hmm, and don't I need execute bit for rebol itself, even if put into 
other directory?

yes, it will be downloadable unless you deny it with htaccess, but 
that's usually not a big problem.

Petr;  DON'T  :)  Suggesting that people try and sneak REBOL past 
sysadmins is a really really really bad idea.  If they can't be convinced 
to try it, then change ISP, or try to convinvce them again.  Don't 
be making REBOL look all cracky.   That is the kind of maneuver that 
could sink the ship.  The rest of us like the ship, and we fly the 
flag of peace and truth, not the Jolly Roger.  :)

My uplink speed kinda (no, it pretty much completely) sucks but I 
offer free hosting to any rebol that wants it at peoplecards.ca. 
 I just ask for patience if a new service needs to be installed while 
I work out kinks and the user needs to know that it's home based 
with a not-so-speedy delivery pipe and I offer little in the way 
of frills; meaning it's sftp or ssh cli, not cPanel or other gui.

Is that the tune that  sounds like "God Save The King?"'   If there's 
a sugar maple blight, 'The Maple Leaf Forever' will sound lame ... 
and they'll never see the Eastern Townships annexed by Vermont.  
'CGI'  does stand for 'Chat Gateway Interfarce' doesn't it ?

Anybody noticed CGI is back as a programming model?

1) Think multicore
2) think memory is cheap (2Gb per core)
3) Typically,  /Core  consumes 8 mb of memory

4) do not encap, use  amodule management system like my 'require 
or Ladislav's 'include

5) wrt 3 and 4: the OS starts using its disk cache etc. After a few 
hits these operations will be cheap

6) do all session mgt etc in a database => sales up as well, no state, 
share nothing

Now, what happens? The OS will start distributing the CGI processes 
over the multiple cores. Using the disk cache etc to speed loading 
times, enough memory per core on the processor. A 8Gb RAM quadcore 
should be able to run +- 1000 procs/sec (rough estimate). That's 
just one box, with that load it should be profitable. And as you 
obey rule 6, you can scale up and load balance pretty easily.

not virtualising OS this days is imo a mistake, no? :-)

Threads are much lighter, but not as separate. I don't know details 
though. On a dual core with hyper-threading on, spawning multiple 
processes, I can see the load is spread.

Maarten, I agree with your observation and you can even scale it 
more.


If you see a web-server as just a request dispatcher to CGIs and 
a fast-answering-machine for user-feedback (pages, forms etc.) you 
just need a small and "simple" one like Cheyenne. The CGIs can be 
distributed to different cores (through the OS) or even to different 
machines (via TCP/IP).

As dispatching requests is most likely much faster than processing 
a request, a single web-server should serve a lot of users and a 
bunch of machines do the processing.

This is the coarse grained multi-process approach.

I am also adding a routing scheme (dialect) so basically you redirect 
all traffic except static stuff to a fastcgi process, it comes in 
the router and then it checks on extension or path (REST) what to 
do.

The generating part will be asking you a few questions and the generate 
matchhing config files and binaries that you can copy to an empty 
Linux box with only lighttpd installed (or enginx)

With the avereage memory use fo Rebol < 10Mb you can coompute how 
many users I can concurrently server for complex operations (100-200 
minimum), so every machine I hire can host 500 customers. That means 
that I should earn e0.50 customer to get  a decent margin (roughly).

I finally learned the trick: 1) create a good interface (but w eknew 
that) 2) use back-end technology that lowers the cost per user (i.e. 
enlarges the # users per box)

Maarten, this sounds very cool. So the goal is to have a scalable 
web-service framwork based on fastCGI and simple tools?

FastCGI is a rebol process with core enhancements, session mgt, RSP 
etc. I am also integrating autodoc from Gabriele so the files will 
be more "literate" and I have a module management system in place 
thathandles from interactive to encap.

As a rebol process is only 10 Mb.... I can serve lots of users on 
cheap VPS's, load balance them, data backup in S3.  No others invited 
until I get things stable enough. eed to ge things going

I don't understand it a bit. I can understand webserver, fastcgi, 
mysql part, but what is that load-balancer part? Client side?

What are the best ways to protect source code from view in a cgi 
script?  When a script is made world-viewable, isn't that compromising 
the source pretty badly?

One of my clients updates his site via some tool, which always seem 
to add some space between the lines. After some time, the page is 
instead of 400 rows something like 13K rows - the size goes from 
cca 25KB to 100KB. So I wrote a cgi script, which reads index.html 
and removes blank lines. Everything is OK, when I run the script 
from the console. But when I run it via a browser as a CGI script 
call, it can't write the file. Dunno why - cgi-script is being run 
using -cs switch, I even put secure none in there, cgi-script has 
the same own, grp set as index.html, but I can't write it ....

no, it is a different directory .... the script is being run in /cgi-bin/, 
while index.htm is at the root of the web ...

is there a ways to know if a rebol script is being run as cgi or 
as a stand-alone?

ahhh yes, I can use the cgi headers to see if they are set... that 
was obvious... seems, I'm still not fully recuperated from the virus 
which I've been "nurturing" for a few days now.

I'll have a static ip by next week so I hope that solves this issue 
for me..

I want to access a mysql db via a cgi interface directly with a rebol 
client.


I have a cgi script  that accesses the db and prints the results 
which I can read with the client but is this the best method? Is 
there a way to send the data directly to the client as rebol blocks 
or do I need to essestialy parse a cgi built web page as I am doing?

I am looking a simple games like puzzles and kid games... and well 
rebol seems like the perfect tool for such games... much more than 
flash anyways.

on my list there is better keyboard support, but a part from that, 
have any of you trying to do games ever gotten to a point where you 
give up for this or that?

I made a prototype for a mobile game 2 years ago. It went well! As 
you mentioned, key-up events were the biggest problem for me. I didn't 
add sound, but that shouldn't be too much a problem, I think. I even 
made a level editor, so that's a game dev tool.

so far I see a lot of demo, but little actual working titles.

I rememeber the little puzzle Volker did I think  where you move 
boxes around... There is also Dirk Wayland which seems to have a 
few games...  but that's pretty much it.

humm. well how much of REBOL would we really be using in an OGL game 
with proper key support... none of view... so basically core with 
a huge stub over OpenGL and native event handling.

I've assumed a lot of that too... but with the current next wave 
of computers and their min 1GB ram...  it seems to me that REBOL's 
RAM hungry-ness is becoming less and less of an issue.

I've been thinking about a game dialect in REBOL for a few years 
now. An abstraction layer, that is perfect for the programming problems, 
you're faced with in game development. Maybe it could even output 
C++ source, if more speed is needed.

A dialect could also produce rebcode, and that would be fast enough 
in most cases.

whatever is buggy can be left out... whatever is stable will already 
be enough.  IIRC brian was part of the whole process and was confident 
that very little needs to be done to make the current cut a viable 
part of REBOL.

and what a power feature that would be... I am almost certain that 
a fair amount of mezz code will be ported to rebcode by a few of 
us.

not in R3  in 2.7 we can play with this NOW... no need to wait a 
year.

I did an engine to play NIM:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=nim-engine.r
It plays the game at the console prompt.

But I never got around to adding a View front end --- feel free any 
one.

Carl is affraid of a few bugs and seems stressed about stability... 
 a part from closing any security issues rebcode might be an evening's 
work (maybe two ?)

I don't know where I put it, but I once built a detailed checklist 
of functions we would build for each game platform we worked on. 
 I designed the game interface for WebTV, which also did not have 
Key Up.

The basics are:


Input: Key up, and at least 3 simultaneous key overlap.  This is 
needed because during actual game place, people will press directional 
and fire buttons at the same time.


Video: Double buffer - triple buffer is better.  Without this, one 
needs to know where the beam is (called beam tracing) so that rendering 
happens on the sync.


Threading:  It is very difficult to write a game in a single thread. 
 At the very least it needs to be able to trigger functions.


Sound: Sounds need to be started, stopped, and volume changed on 
the fly.  Multiple channels (4 minimum) for a full experience.

large images like what size?  I had a 10000x800 image a while back 
which scrolled nicely and seemed to behave... but maybe I didn't 
check the RAM.

just looking at my kid... playing a scrolling plane game... in 2 
minutes he figured out the random generator... so banked his plane 
at the far top of the screen and multiplied his high-score by 10 
 :-)  hehe

This is why Rebol is not a possible game platform for us.  It is 
fine for games roughly like those written for the Apple II.

Rebol is however a GREAT scripting system for games.

Probably, the best thing is to write a C library to provide the bse, 
then write the game in Rebol.

yeah, just using a vast amount of stubs.

hmm, when I look into R3 diagram - there are various modules mentioned, 
but no sound :-) the best sound system probably is fmod, but this 
one is commercial. They have fmod mini IIRC, which could be good 
fit for Rebol, but investors would have to buy a license for RT ....

your cube pushing game is A LOT of fun.

i did  a mahjong once, but  forgot  where it is

With a little library, many of the arcade grames from the 80'ies 
will be easy to do in REBOL.

it has a  chat, meet  me and  i translate^^

But mainly  it shows  that  rebol can do some kind of adventure-graphic 
 and fast enough networking.

if there is interest, it needs a rewrite (homegrown spagetti), if 
someone is interest to team up. Alone its to boring^^

I've started on a hex-grid generator. Handles grain, background image, 
terrain and grid size so far.

i  use positions and an immage for background-collision. less performant 
than grids but the map can be a big image without much work.

Just a quick rebirth of the R-Box2 script:

make-dir %rbox2/ change-dir %rbox2/ do http://box.lebeda.ws/~hmm/rbox2/r-box2_latest.r

maybe I could come back and finish a multiplayer version one day:-)

I always wanted to create a RTS game where each god starts off with 
nothing  really ... nothing... all he has are a few basic physic 
rules to work with, a selection of pictures to use for this or that 
(supply your own if you want  :-)  and basically, mix and purchase 
direct statistics and give them names... so that one person might 
create a civilisation which is centered on a religion called lets 
say... "Flying spaghetti monster"  an another which goes with long 
rang ballistics... really it would be a lot of fun, since you'd have 
NO bearing on your opponent's strategies, and since each one really 
is only purchassing raw statistics which are weighted full using 
sampling and probabilistic curves and such... the game would be utterly 
fair.

yet  when you are attacked by a "mighty whoopy cushion warrior" you 
might not know in the begining what they can do  :-)  so you actually 
have to learn to cope with the other's raw tactical might.

I guess a few oddball capabilities might be to purchase some game 
effects like motion speed, range, terrain type for your world, for 
which being need to have a specific means to cross... like noode 
forests and acid baths  :-)

I must say, that the original Rebol version of the re-box is from 
Dockimbel (http://softinnov.org/rebol/rebox.shtml) I just took his 
level data and made a little bit more complicated graphics. And the 
avatar and some of the ferniture used is from one of my favorite 
Amiga games - DreamWeb - http://www.adventureclassicgaming.com/index.php/site/reviews/221/

Anyway, why somoone would like to do remakes of an old games? We 
have emulators and the old games are available for download without 
problems now, like from this place: http://eager.back2roots.org/A-Z.HTML
If someone want to do a game in Rebol, it should be a new game which 
will use all the features of the network - it should be multiplayer 
online game - imagine Altme, but with avatars going around:-) I'm 
just waiting for R3 where I will be able to use custom fonts, better 
sound and modules  (for example). The problem I see is, that most 
of us here are coders, not graphic artists:(

a 3d planet defender with multiplayer attackers and defenders would 
be a total rush!

that game with statistics, do you have an idea about implementation? 
something  for a small prototype? maybe with 1 or 2 d-physics for 
a start.

I haven't had a lot to time to put on the development side of that 
concept.  so I never really tried to go into such detail.  I have 
to much to do these days, but as part of the time I put on "fun" 
coding, I eventually will get to it... especially since most of my 
low-level apis are comming to fruition  :-)

imagine that with liquid, you could actually share an in game avatar's 
data right on your desktop and plug that within a little app so you 
can let your game play until the avatar has something strange to 
report...    :-)

something which is a result of your agent's processing identified 
as strange... basically, his inputs serve as senses or nerves and 
their processing create reactions.  the term "strange" can be relativised 
within your agent's logic but is not a term within the application 
itself.

it is you the god which defines a meaning to the term "strange" by 
causing some state or event to occur based on your agent's perception.

obviously within each successive game session or "world" there needs 
to be consistency, so that your agents can aquire a sense of meaning 
base on how they perceive your agents.

When changes have cost, that  consistency wouldcome. you take 50 
rules  from the last  game and can only afford 1  a day.

or each victory allows you a point count (like xp) where you can 
add it more agent macro code bytes  :-)

I even tought of allowing individual agenst to be editable.  and 
then allowsing classes to be copied... obviously... cloning from 
a class is less costly when generating a new agent...

now that is the concept.  implementation is obviously a question 
of many micro-evolutions of the engine's  capabilities... each little 
step adding a multitude of options.

for combat this is easy...   % of chance to hit... and number of 
hp damage, with probability of higher damage costing more.  so a 
one in six damage costs less than a 4 in 6 damage.

and then a map? or  something like: your chances to be near a subrabwor 
are 1:5?

you have a chnace to be somewhere, or something.

How about a game where people must optimize search? but  the ranking 
is based on the statistics  both own. then you need good statistics 
and must optimize your avatars(pages) to match them