World: r3wp

doh... it's even written in a comment. :-)

:)

I suggest that the wait is done in a different way in the example, 
otherwise the example is not very useful, I think.

removed the wait, and it transfers perfectly.

Where you removed wait Henrik?

oops, not the wait, just the 10 near the bottom of both scripts.

Sorry to say that but still the same in my machine 4'300'000. But 
when you are happy it must not be generall bug.

well, we still need to figure out what goes wrong. do you start the 
client or the server first?

We know what's going wrong.

The write function (in the send-chunk function) triger a WROTE action 
immediatly without returning in the waiting process before.
To me it's a system bug, probably linked with the OS used (XP).

check the version of R3 u use too

A96

not you, Pavel

Pavel use XP, i guess only XP has this bug

I guess my version would be important too, if I don't experience 
the bug :-)

and I use XP as well and I don't have the bug.

you got VISTA, me too, and we don't have this bug

Oh ! really ?

strange

yes... :-)

so we have to check the version Pavel uses at least

Pavel, there is ablsolutly nothing else in the scripts you use than 
the code we are testing, right ?

i have to go, i pass...

Henrik, I started server first, originally I've set the wait to 60 
in server to be able to start client without hassle. Only what I've 
changed else in server was make-dir to not to create temp directory 
each time the server is started. But give me some time to try it 
in other machine.

Carl's Twitter message: "And yes, we will open the R3 Host Kit to 
all developers before the end of Dec. We did it this way to avoid 
a possible flood of dev feedback."

Henrik 1399 tested on different machine without problem (infinite 
wait) 200MB transfered, definitely the problem is in my machine. 
Apology for hoax.

Pavel, it's still a bug. It should work on your machine.

FYI when ran on Win2008 server only first lookup, read, write, happened 
but not repeating cycle sending data.

does R3 Chat work on win2008 server?

Trying to understand how the Port model works WRT sequences of calls, 
events etc.

For this I try to create a sequence diagram. You can take a look 
at:


http://www.websequencediagrams.com/?lz=U2NyaXB0LT4AAgY6IE1ha2UgUE9SVAoAChBTZXQgQVdBS0UgRnVuY3Rpb24AGglQb3J0OiBPUEVOClBvcnQtPkFjdG9yAAsHAAcFLT5UQ1BfRGV2aWNlOiBMT09LVVAKbm90ZSByaWdodCBvZiAAFQxPcHRpb25hbCBjYWxsIGlmIGhvc3RuYW1lIGdpdmVuCgBDCi0-QXdhawA8GAAVB0NhbiBkbyBJUCBmaWx0ZXJpbmcgZXRjLgoANwUAgQ4OUmV0dXJucyBUUlVFAFoOAIFOBj8_AFQQAIFmBjJuZCB0aW1lAIICBQCBMwUAgWYUAIIfBQCBKxNDT05ORUNUCg&s=napkin

This is a very cool

Nice ...

Cool Robert.

Nice .. can this dialect be written for View ?

/mode noob ON

I just realized that creating tasks works well since a while with 
R3.

And I already should have used it for some stuff, it would simplify 
my code.
What a fool !
/mode noob OFF

We developed a TCP server program using R3-a96, trying to make it 
run in Linux as a daemon program (i.e. running in background), however, 
we failed. It just couldn't run in background.

We've tried the following 4 methods:

1) ./rebol my-server.r -s 8000
The process status is "T"

2) nohup ./rebol my-server.r -s 8000
The same as (1)

3) setsid ./rebol my-server.r -s 8000

This one worked, but it refused to return the session, which is not 
acceptable for us. If we do this in a shell script, anything after 
it won't be executed.

4) echo ./rebol.bin | at now

It shows "Can't open /var/run/atd.pid to signal atd. No atd running?" 
Our shell script didn't have the privilege.

Please help me. Thanks.

Previously, I also haven't been able to separate "launched" versions 
of Rebol from the same terminal session. However, after a bit of 
googling I've worked out a way that seems to work using Ruby:
 
Macintosh:Rebol3 peter$ irb

>> require 'pty'

=> true

>> PTY.spawn("./rebol -q pong-server.r"
)
=> [#<File:/dev/ttys005>, #<File:/dev/ttys005>, 1437]
>>


Process 1437 was running in the list of processes and control was 
returned to the console session.

Of course, I had to manually "kill" process 1437.


As there is a formatting error in the pasted code, I'll confirm the 
ruby:

require 'pty'
PTY.spawn("path-to-rebol -options path-to-script"

I tested this on OSX but believe it should work the same under Linux.

I forgot the closing ) - probably don't need the parentheses in Ruby 
anyway:

require 'pty'
PTY.spawn("path-to-rebol -options path-to-script")

It would be so much better if you could achieve this as easil  from 
within R3 though.

to-binary [1 1 1] should do #{010101} but doesn't work for me in 
A96, is it intended? Documentation tells should work.

Isiit possible to set length of binarx datatype somehow?

I understand it, that this is an intended change

(there are reasons, why the conversion you mention does not look 
correct)

Especially shorten integer to binary representation to 32 bit only

Maybe only copy/part last halve do it.

possibility to set the length of the binary datatype - aha, yes, 
copy/part can yield a shorter binary, another way is to use the Remove 
function

good hint thanks

or, the Clear function, ...

May Clear work partially?