AltME groups: search

Any idea how to start a rebol script via ssh (I have a VPS) .. and 
detach it from my console so when I close it it won't stop running?


cheyene executable file does this automagically (I have no idea how) 
.. if I run cheyenne through .r script it exits with me .. but my 
problem now is not with cheyenne but I have a custom script that 
should run in the background. After googling yesterday I found out 
about >> nohup script-to-run & which seemed to still work if I closed 
ssh and started another one but now I see for the second time that 
after a while it exited as it isn't running any more ...

Anyone know of any issues getting the time and date under Wine?

I've got a user reporting that my app under puppylinux is reporting 
the wrong time when compared vs NIST time.

in my example, you have your own port using your own scheme, and 
its sub-port which is the original system/ports/input. this sub-port 
need not be the original, you can open console:// yourself with your 
own flags (eg. binary). then you can process one char at a time, 
figure out line ending yourself, and send the entire line to the 
other side.

Anyway, so it seems like you suggest to replace the default port 
at system/ports/input with an equivalent one which the system is 
expecting (ie. a direct/read/lines port), and then the subport can 
be a custom console port with binary, one char at a time stuff.

Cyphre is not sure, if there is support for fonts in AGG under OS-X, 
he did it together with Carl, but long time ago ...

(it takes some time to configure, but iptables takes some time to 
configure as well)

I think I am no willing to spend my time talking some wifi related 
issues with someone, who apparently does not know, what he is talking 
about ... talking about at all.

Also, PLEASE, I beg you, do *read* what I write. I never said my 
problems are due to mikotik. I said my problems are due to my ISP 
not knowing what they are doing. You said that mikrotik allows "normal" 
people to set up a WISP. Right, they do, and the result is that they 
waste MY time *because* they know nothing about this job. This was 
*your* claim, and it seems to be consistent with what I am seeing.

Yeah I started looking at the code. It's a bit hard to debug for 
me though. The error doesn't give any line number, it just says "near 
show main". I searched for "show main" and found three occurances 
in the source. I'm completely new to REBOL so going through everything 
in the code would take me quite some time without being able to narrow 
it down first because everything looks alien to me and I have to 
look it up to see if something in the script looks wrong. Is there 
some good tutorial available on debugging REBOL code? Or is there 
some trick to find out the last line that was executed? I do have 
access to the terminal at that point, the view is frozen but the 
terminal still accepts commands.

I guess a demonstration of its stretch is rebcode, which I had no 
idea was possible. It won't be in R3, but the fact that it's even 
possible to do in a scripting language and was implemented in as 
short time as it was is a great demonstration of how generic REBOL 
is.

Budzinski: REBOL's shortcomings wrt to "multiplatformness" are mainly 
due to Carl not having the time/resources to really keep all platforms 
up to date. Design wise, I think that we don't have the problems 
Java had/has; they do, though, have enough manpower to fix all of 
them, no matter how awful things end up being. ;)

I've read the explanation multiple times, but BrianH knows it better 
than me. It has something to do with how functions are implemented 
in R3, which would make rebcode work slower in R3. Therefore it's 
better to spend time perfecting extensions, so you can write time 
critical code in C and use that instead. Rebcode is not for beginners 
anyway (but it did bring up that oldschool feeling for a while :-)).

Ok. I found a how-to for changing the distro on a live system via 
SSH. I think I will give it a try over the "clam x-mas days". Than 
I have enough time to fix it if I screw things up.

Kaj - I want to know, if 'call command is part of the core, or the 
host. Because its current implementation sucks big time and I want 
/wait and /output refinements back :-)

Call has nasty bugs, which are in CC for quite some time. It is just 
general disagreement, on how Call should be implemented. BrianH stated, 
that it is now more low-level, and I objected, that I don't care, 
or it is not usefull for most use cases ...

heh, it's running in 856x600, I see such resolution for the first 
time

I don't want to steal your time any more.. I will try this again 
.. sometimes when you return to the problem after a whike you solve 
it imediatelly

hmm, it might be the scrolling problem of putty console. I should 
not use CZ server installation next time, the language chars are 
malformed anyway.

Yes, I was thinking I'd try filming it with my camera next.  (--> 
Dinner time)

(though it's strange it's not in /var/log/messages. maybe it was 
just a fsck message? for some reason the fs was not unmounted correctly 
last time so fsck told you.)

or, you can do this

>> trace/net on
>> print read ftp://ftp.rebol.com/
URL Parse: none none ftp.rebol.com none none none
Net-log: ["Opening" "tcp" "for" "FTP"]
connecting to: ftp.rebol.com
Net-log: [none ["220" "230"]]

Net-log: {220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------}
Net-log: "220-You are user number 3 of 150 allowed."
Net-log: "220-Local time is now 20:15. Server port: 21."
Net-log: "220-This is a private system - No anonymous login"
Net-log: {220-IPv6 connections are also welcome on this server.}

Net-log: {220 You will be disconnected after 30 minutes of inactivity.}
Net-log: [["USER" port/user] "331"]
Net-log: "331 User anonymous OK. Password required"
Net-log: [["PASS" port/pass] "230"]
** User Error: Server error: tcp 530 Login authentication failed
** Near: print read ftp://ftp.rebol.com/

I'm not using View for a very long time, but I guess you must first 
make the font object!

my example allows you to insert just a few bytes at a time and update 
a progress bar, if you replace the 'INSERT line by a loop which only 
copies 2000 bytes at a time until the copy returns none

I'm a Brit living in WA state USA. My sister lives in the midlands. 
I'll visit Sunanda next time I visit the UK.

I will certainly take a look at Cheyenne before I start doing complex 
stuff, and before I spend time designing this project on paper, which 
I have yet to do. ATM I'm playing around to discover what can be 
done with Rebol.

Graham, the problem with url-encoding is not at the protocol level, 
it's at the URL! type parsing level. REBOL decodes characters at 
the wrong time.

>> read ftp://gchiu%2540compkarori.co.nz:[password-:-ftp-:-rebol-:-com]

URL Parse: gchiu%40compkarori.co.nz password ftp.rebol.com none none 
none
Net-log: ["Opening" "tcp" "for" "FTP"]
connecting to: ftp.rebol.com
Net-log: [none ["220" "230"]]

Net-log: {220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------}
Net-log: "220-You are user number 3 of 150 allowed."
Net-log: "220-Local time is now 03:37. Server port: 21."
Net-log: "220-This is a private system - No anonymous login"
Net-log: {220-IPv6 connections are also welcome on this server.}

Net-log: {220 You will be disconnected after 30 minutes of inactivity.}
Net-log: [["USER" dehex port/user] "331"]
Net-log: {331 User [gchiu-:-compkarori-:-co-:-nz] OK. Password required}
Net-log: [["PASS" port/pass] "230"]
** User Error: Server error: tcp 530 Login authentication failed

** Near: read ftp://gchiu%40compkarori.co.nz:[password-:-ftp-:-rebol-:-com]

Thanks Maxim. I use Putty to access the server though I use it so 
infrequently that each time is like a new experience. I appreciate 
your help.

It's just one partition. The problem is that I can't mount it, as 
the file-structure is damaged. I tried to extract meaningful file 
parts but no luck. I already spent to much time on it. We throw it 
away as we have the data locally and now need to find a way how to 
restore our AltMe content.

Just redid my netbook with Ubuntu Netbook 10.10, and it works much 
better than in did with WinXP. Had to partition manually as the tweak 
to make the installer SSD friendly is still a proposal. R2 and R3 
work, though (as someone used to the Windows versions) I am having 
trouble with the console not opening a terminal when prompted to. 
I guess the button in the R2 View desktop doesn't work. Time to figure 
out the application shortcut creation method for this distro.

Better to choose a font which works on Linux... last time I used 
Rebol/View on linux, the default font look was very bad.

MaxV: the problem on Linux is that there is no easy way how to get 
font path just by giving the font name + font type.( Windows does 
that automatically)

If you know how to do it in Linux so it works on all distributions 
that would be helpful.

(Maybe it would be enough to write some parser in rebol to get the 
font information from some place in the system, but I have no time 
to investigate this as I'm not using Linux for desktop stuff.)

As I said I have neither time nor personal need to become 'linux 
font master' so in fact I'm not 'pressed' by anything ;) I'll left 
this part to others.

Thanks James. I heard someone had done it before. I have pretty much 
decided to scrap the idea for the time being. I seem to be stuck 
on the x86 platform for the time being, and x86 routers are expensive.

One of the details I left out in the above overview is how clients 
actually render under wayland. By removing the X server from the 
picture we also removed the mechanism by which X clients typically 
render. But there's another mechanism that we're already using with 
DRI2 under X: direct rendering. With direct rendering, the client 
and the server share a video memory buffer. The client links to a 
rendering library such as OpenGL that knows how to program the hardware 
and renders directly into the buffer. The compositor in turn can 
take the buffer and use it as a texture when it composites the desktop. 
After the initial setup, the client only needs to tell the compositor 
which buffer to use and when and where it has rendered new content 
into it.


This leaves an application with two ways to update its window contents:


   1. Render the new content into a new buffer and tell the compositor 
   to use that instead of the old buffer. The application can allocate 
   a new buffer every time it needs to update the window contents or 
   it can keep two (or more) buffers around and cycle between them. 
   The buffer management is entirely under application control.

   2. Render the new content into the buffer that it previously told 
   the compositor to to use. While it's possible to just render directly 
   into the buffer shared with the compositor, this might race with 
   the compositor. What can happen is that repainting the window contents 
   could be interrupted by the compositor repainting the desktop. If 
   the application gets interrupted just after clearing the window but 
   before rendering the contents, the compositor will texture from a 
   blank buffer. The result is that the application window will flicker 
   between a blank window or half-rendered content. The traditional 
   way to avoid this is to render the new content into a back buffer 
   and then copy from there into the compositor surface. The back buffer 
   can be allocated on the fly and just big enough to hold the new content, 
   or the application can keep a buffer around. Again, this is under 
   application control.


In either case, the application must tell the compositor which area 
of the surface holds new contents. When the application renders directly 
the to shared buffer, the compositor needs to be noticed that there 
is new content. But also when exchanging buffers, the compositor 
doesn't assume anything changed, and needs a request from the application 
before it will repaint the desktop. The idea that even if an application 
passes a new buffer to the compositor, only a small part of the buffer 
may be different, like a blinking cursor or a spinner.

I don't like phpBB as I don't line other such a php apps... they 
seems to be too bloated to me... I think it should not be dificult 
to do it in Rebol. But I don't have time as well.

Re acronyms.  Yep, must remember to mention the full text at least 
once per post cycle from now on.  


More on the namespace issue in user.r chat; but I'd like Cheyenne 
to be given a pride of place status for word usage, equivalent to 
what we'll be following with our rules for dealing with RT's word 
usage.  i.e they win, we deal with it.  Go Doc Go!


Re BBS for Cheyenne.  I'd almost like to extend RBBS out to something 
more grandious, and at the same time extend the tutorial Carl and 
Gregg and Volker and Tom built up, but along with the CGI (or instead 
of) document the RSP side of it.

We don't want this tutorial to get too large, so we decided not to 
include certain features at this time. Some of them may be added 
as part of a future CGI tutorial.

        * User accounts (including user registration)
        * Browser cookies
        * Fancy message formatting
        * Message searching
        * File locking methods


so straight away we don't need file locking methods, browser cookies

Umm, yes and no.  Spam.  I delete one or two a day and neglect it 
the rest of the time.

I tell you all the time, just insert the form using javascript. I 
do it this way and I had no problems with a spam yet.

Motivated to add counter-measures.  Activated the PoL (Proof of Life) 
code.  I'll watch the logs for a while but I think the rbbs.r on 
peoplecards should now be closer to immune from the robot spammer 
that tagged me a few months back.


Terry; Might be a good idea.  Promoting Cheyenne, promoting Semantic 
Database and building something rebols can use for a forum all at 
the same time.  Many birds, few stones.

Developers stopping their work on R2 waiting for R3 are just loosing 
time. I bet that R2 will still be the stable REBOL in 6 months (maybe 
even more). For professional work, stick to R2, until R3 reaches 
a stable level.

Bugfixes and new features. Control panel is not ready for prime time.

Worked out the other issue.. Flash requires crossdomain.xml file 
to be delivered up by Cheyenne when running Flash that uses xml.Socket 
(like RASH).
Butt it's working well now.. and very cool. 

Works like this.. I run my local copy of Framewerks with embedded 
Cheyenne server, and park the GUI on any server (always accessible, 
single point of bug fixing etc.) for all to use.. currently it's 
here  http://kommonwealth.com/exper/gui.html


Now, it wont work for you 'cuz you're not running framewerks.. but 
if you were..  you could type into the box "codes" and it would open 
the RASH code file, on your desktop, using your favorite text editor. 
  

But wait.. there's more... 

In my local code.txt file i have the following line

PnG "testing" ][bout: {<pre>ok this works</pre>} makeXML ['DISPLAY 
'MSG "testing works here"]]


So when I open another browser, and point it to http://localhost/
testing  that line is fired (more on all this later).. 

Which does two things.. it outputs "ok this woks" to this second 
localhost page .. BUT (and this is the cool part)

it sends the "testing works here" into the panel on the first kommonwealth 
page. 

In other words, Im able to PUSH data to the remote page at ANY TIME.. 
  this will make for the ultimate in portal pages. 

And.. if that's not enough, Im able to pass messages to the DOM via 
javascript to the kommonwealth page as well. 

Allowing things like sliding in panels.. fading div elements moving 
images.. whatever.


So.. remote page can manipulate my computer.. run apps, do any Rebol, 
reboot .. whatever.. and the local desktop can manipulate a remote 
web page.

Finally.

Re service.dll : it could be used to add NT-Service support for any 
REBOL app. But currently, there's a few hardcoded parameters in the 
C source, so it would need at least a recompilation to work for another 
app. I was thinking about packaging this into a simple library...I'll 
see if can find some time to do that. But, in all cases, it requires 
at least /Library component.

Doc, you may want to say system/options/quiet: true


I found this in /var/log/system.log on my Mac, when starting Cheyenne 
using Launchd:

Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:43: --- last message repeated 1 time ---
Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: -
Jan  1 11:01:43: --- last message repeated 1 time ---
Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: \

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: \
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:44: --- last message repeated 1 time ---

Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: \
Jan  1 11:01:45: --- last message repeated 1 time ---

Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: |

Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: /

:-)

but that is mostly ajax, and load is put on the flickr api.. now 
for something that really use Cheyenne rsp power, check this http://beta.arounder.com/amsterdam/city_tour/van_gogh_museum_01.html
click on the "read" tab, there is a little number in gray, that is 
page generation time, then reload the same page and check again, 
it use a uniserve/service memcache, also conside that it's on a multilanguage 
framework 8)

I've tried to get it up and running (Magic!) but have never got it 
to work. Apachi always gives me a hard time. Since its CGI based 
I tried with Cheyenne but again unsuccessful.

Brian, nothing specific, it just looked "too big" last time I've 
checked the source code which was a year ago. I should have a look 
in Devbase for the latest version of LNS.

This will be the new official web site for Cheyenne. I still needs 
some time to migrate all the old stuff, including the blog.

How much time will you be spending on Cheyenne Doc?

Erlang has a lot going for it, but it has its own set of issues as 
well. Maarten recently spent some time evaluating it quite deeply 
for me. At this point, we're sticking with REBOL.

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

AFAIK, every client or server connections are taking a port number 
in the 64K range. Each time a server receives a new connection it 
assigns a local port number to the client connection. That local 
port number is in the 64K range because TCP (or UDP) header storage 
space for source or destination ports are only 16bits each.

DocKimbel, small request: Would it be possible to post the rsp guide, 
cheatsheet and docs as separate pages directly on the site? It's 
unpractical to have to download Cheyenne every time I switch machine, 
just to read the docs. Thanks.

Is there anything that would cause Cheyenne to crash? I've not yet 
tracked down the bug, but every time I click a specific link on one 
of my .rsp pages, it just dies and needs to be restarted. Unfortunately 
it's now gone so far that it seems not to want to serve pages anymore 
even though it's running. Under OSX, I get this log output:


Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68212 PPID 68210 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68211 PPID 68209 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68210 PPID 1 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68209 PPID 1 
rebol


Are there any file permissions, that if set wrong, would cause cheyenne 
to stop serving pages?

The %httpd.cfg config file is in the source archive. If you have 
the Cheyenne binary only, it is wrote down in the same folder the 
first time Cheyenne is started. If you started Cheyenne from Window's 
desktop, Cheyenne will use C:\Documents and Settings\All Users\Application 
Data\Cheyenne\ to store its files.

Will, OSX Leopard. I think I'll wait with external testing until 
I can open my new website a few bits at a time.

probably past his bed time now ....

It's not a concurrency issue, READ is blocking, so just one connection 
at a time. I run the same test here (XP-SP3) several times, no problem. 
AFAIR, the same test was running just fine on SP2.

please check next time ... well, if you have some static pages!

Guess what, clients started getting timeouts because it seems that 
Cheyenne wasn't fast enough to process all events and find enough 
time to accept new incoming connections (this also had the bad consequence 
of halting Cheyenne due to an uncatched timeout error).

I take it this is fixed in next version?


Also, what are the mechanics around the connections.. at 1000 it 
just maxed out CPU or rejected connections? or ?

So with the old code, Cheyenne was hanging on each time ? (I guess 
after a few requests ?)

trapped in a time loop ?

Doc.. Im just thinking scalability / benchmarking.  I plan on spending 
my spare time over the next number of months building a next gen 
webserver using Cheyenne as the core, and I want to make sure I don't 
hit a game killer 3 months in.


i posted earlier in the Rockstar group how superior Cheyenne is compared 
to vhosts and .htaccess.. night and day.

Suppose I implement the rest-mod, I want it be stateless so no cookies. 
 I want to pass the userid and password each time.  So, with no cookies, 
the user won't have access to the webapp.  So, does this mean I can't 
use a webapp with rest-mod?

I'll have to check it again some time.

That's why I was calling since the beginning of R3, for a focus on 
R3 Core features first, to be able to port our R2 code to R3 and 
benefit from modules (and other vital features like plugins). We 
reached PITS limits a long time ago.

I think I could improve such issues with a timeout on RSP script 
execution in the main process (and returning an error message if 
a time limit is reached).

I downloaded the Cheyenne source. Started the Cheyenne.r. Should 
I be able to connect via a web browser and localhost? I get Internet 
Explorer cannot display the webpage. I looked on the website for 
setup/config documents, but the document section just seems to time 
out. Is there any other service I need to start or should it be straight 
forward? I am on winxp, internet explorer.

And I'm unable to see the documentation on the Cheyenne website (wiki). 
I only have a neverending "wait for cheyenne-server.org" that finnaly 
ends long time after with a blank page.

IIRC, that's the second time you correct me on that same mistake 
;-)

do you query mysql with mysql-protocol.r at the same time ?

That was one of the options, the other is me writing a good READ-IO 
emulation for CGI (that won't happen soon...lack of time).

don't have anything specific at this time - just thinking ahead

I have used both. Linode offers you much more flexibility in controlling 
your VPS. For example, you can have multiple disk images at the same 
time (although only one can be active).

In general, every time you have to glue different technologies together 
you have an impedance mismatch, so if it can be avoided it's worth 
it

This is interesting.   I'm launching cheyenne on startup each time 
my app starts.  But to see if it is already running, I check by opening 
a port.
p: open/direct tcp://127.0.0.1:8002 close p


but this causes Cheyenne ( latest encapped version ) to shut down!

Doc, do you have a time planned for the public release of 0.9.19?

I always thought that because cheyenne is pure rebol it will be quite 
slow but http_load got me 250 req/sec on a RSP page which is unusually 
good. I rememeber when I was playing with Lua a while ago (which 
is one of few the fastest dynamic languages) and Kepler(it's default 
webapp thing at the time) and I tested lua based webserver it was 
quite slow, same is known for webrick from ruby etc.. and also my 
php with all the needed includes were well below 50 r/s. So awesome 
job Dockimbel !

yes, the different profiles is really cool feature , especially at 
developement experiment time

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

Cheyenne new test release delayed until tomorrow. Almost a dozen 
of fixes and useful improvements were added, mostly by Will (many 
thanks to him). So a little more time is required to run non-regression 
tests.

The compression overhead is small compared to the time gained on 
the network transfert. Here's a study from intel on that question 
: http://software.intel.com/en-us/articles/http-compression-for-web-applications/

Sounds like a quirk that took some time to find and fix...

Robert - dunno Cheyenne, but generally there is several types of 
cookies. Time limited, session limited (deleted by browser closure), 
and infinite ... IIRC (long time I last looked at the topic)

well, for few days, at least ... untill Carl is back - then it is 
time to bug him to post DevCon slides somewhere :-)

DaveC:  For devcon 2005 Carl had a script called... show.r.  The 
script he was using this time seems to be slightly different from 
the last Devcon as the last devcon the show.r had a clock displaying 
the time remaining using a very fancy clock.

I can imagine complete cute app for DevCons. Not video and sound 
till Rebol 3 and proper plug-ins, but imagine this - kind of server 
(Cheyenne), accepting outer connections. Each presenter would have 
to send his slides to conference organisers, who would put it into 
structure - Schedule, with time slots. I know that schedules are 
missed, or skipped, but once connected, you could see what session 
is actually broadcasted, you could see progress bar of the estimated 
time left till the end of the session, and as presenter would go 
via slides, it would be "broadcasted" to outer world ...

Well, if we can actually get enough interest in Maui, then I will 
get real about when is the best time.  Prob, plan it for when prices 
are cheapest for everyone.

I can't wait until I have time to watch every single Devcon video 
and absorb what all was presented.  Italy was fantastic last year. 
 One dose lasts me for a whole year.

Im realy proud actualy to see Rebol grow the way it has (sounds silly 
but it is), there are susch a load of people doing so many intesting 
things with Rebol its realy refreshing to see the time and science 
they put it their projects..fantastic...

Graham I wanted to write something, but I'm not sure when I'll get 
some time to do it.

rebin may be delayed after july... but it depends on the time carl 
will have during june

my first goal is....... i don't want to spend time writing guis for 
simple apps.

Can we just move them all to Rebol.org (for example)?
Throw them on a page in a simple clean table


[Date and time of talk | Name of speaker | subject | link to movie 
]

it does not run in my quick-time :-) Probably needs some filter for 
H.264? Sound runs though ...

90% of the time i just use MPlayer. the remaining 10% VLC.

Thr Red is supposed to be awsome .....  they talk about it all time 
on Twim (this week in media).