AltME groups: search

I only use a single client/server.

Pavel, what happens for me is that:

1. I start the server and it waits like it should

2. Then I start the client and transfer begins. At some point around 
10-20 MB in, the server just stops and the client returns to console. 
After a few seconds the server also returns to the console.

3. If I then start the server again, the read continues for another 
80000 bytes, like this:

>> do %/c/serve.r
Script: "Untitled" Version: none Date: none
subport read
len: 32000 total: 19192000 of 406258740...read
subport read
len: 32000 total: 19224000 of 406258740...read
subport read
len: 9000 total: 19233000 of 406258740...read
subport read
len: 7000 total: 19240000 of 406258740...read
subport close


And then the port closes and the server quits again, unless I start 
the client.

Well, my remark stay relevant.

Because  if for any reason the server is slower than the client, 
a lot of chunks can be stacked in the server's memory

Pavel is referring to this example:

http://www.rebol.net/wiki/Port_Examples#Transfer_a_large_file

Guess i'm stupid, the problem is really simple.
there is a timeout both in CLIENT and SERVER.
after 10 seconds both server and clients are stopped.
(check the wait command at the end of the scripts)

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.

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).

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."

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

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

/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"

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

Pavel, the documentation was converted from the R2.3 Core manual, 
and not all of the docs have been rewritten for R3 yet. If there 
is a discrepancy between the behavior and the online manual, and 
this discrepancy isn't already mentioned in CureCode, then assume 
the docs are wrong.

Jerry, would running inside screen be an option? as a temporary workaround 
of course.

my company has a protocol, the admin just follow the protocol and 
leave the serious issue to me. they said "REBOL is not in the list 
that they should maintain"

Gabriele, you are a life saver. I was arguing with the admin just 
a few minitues ago, now the problem is gone with your method. Thanks 
to you. I owe you one.

Nobody has written a UDP scheme for Rebol3 yet. I believe at the 
moment the only comms scheme is http.

How good is the current networking implementation in R3?  Any notable 
bugs?  I'm looking to build a OPC Server in R3.

Since a device is by its nature an interface between R3 and some 
external thing, such code wold always be in the host code. Or later 
in a device extension, once we get those.

Carl's a bit silent lately. I wonder if he is working on new website, 
or continuing his work on Host Kit ....

Does anybody else think that the news of the new Rebol 2 release 
and especially the inclusion of SSL has significantly raised the 
bar on a R3 beta?

I don't think so ... REBOL is in such a bad public acceptance shape, 
that releasing SSL and ODBC will not imo help. At least not to bring 
new ppl. But - you might be right, that it might a bit encourage 
current rebollers ...

should have been done a couple of years ago

PeterWood, no the new R2 release hasn't raised the bar for the R3 
beta - that bar is high already. The beta will still be released 
with the features it was going to have before. The rapid release 
model means that there will never be such a thing as a "final" feature 
set - the feature set will always be the current one, with more to 
come. The first release will not have feature parity with R2; some 
features will be better, some not there yet.

So you know target feature set for 3.0 beta? The feature-set was 
outlined in project-plan document, which is not however being a guideline 
anymore, and I think it never was ....

PeterWood, no the new R2 release hasn't raised the bar for the R3 
beta - that bar is high already. The beta will still be released 
with the features it was going to have before. The rapid release 
model means that there will never be such a thing as a "final" feature 
set - the feature set will always be the current one, with more to 
come. The first release will not have feature parity with R2; some 
features will be better, some not there yet.

I would like to see Extensions and Host code finished to final state 
(it means support for devices, vectors, callbacks, etc.), and concurrency 
added too, or it imo has no sense to call it a beta ...

Rapid release model, remember. There's no such thing as a final feature 
set. Beta means that what is there is expected to work.

Nonetheless, extensions and host code in a more usable state is likely. 
Concurrency less so for the 3.0 release - concurrency is a big issue 
that needs more review, particularly once the subtleties of the model 
are well known enough to make the mezzanines task-safe.

Task-safety will require a full code review, natives included. Probably 
some adjustments to the system model and module code too.

what about a sum or product functions for R3?

I'm all for it. I've suggested them in the past, but didn't get much 
traction. Here's a non-recursive starting point.

    ; Should our seed value be 0.0 to coerce to decimal? If they
    ; include a decimal value before any overflow, it will be OK.
    ; Changed to match the first type in the block.
    sum: func [block [any-block!] /local result] [
        result: any [
            attempt [make pick block 1 0]
            attempt [0 * pick block 1]
            0
        ]
        foreach value reduce block [result: result + value]
        result
    ]

well, if only the default math operators could accept series of scalars 
by default, it would be incredibly simple and powerful.
It should not be so hard to have that behaviour nativly...
A + [1 2 3 4] == A + 1 + 2 + 3 + 4

Zero versus none is a good question Brian. I have SUM return zero, 
but my AVG func returns none.

We might not need to coerce to decimal. The first decimal in the 
list will make that coersion for us. And we don't want decimal results 
for a list of integers - it's a loss of precision. I suspect that 
initializing result with the integer 0 will be sufficient.

Agreed. The only issue is if you don't get a decimal value before 
an overflow occurs, but that's just something to doc.

Not for a empty block.

That's the R3 way - throw a useful error so the programmer can fix 
their code, no DWIM :)

In case reducing the block makes a function or some other active 
value - no double eval. It's a way to trip bad errors quicker.

It uses a lambda local. :-)

And faster. Reversing the order of arguments might not be a good 
idea though - some operators are more forgiving of their left value.

i was not seriously doing a proposal :-)

Yeah, I'm trying to remember (since I didn't comment it) why I coerced 
the result. Something in my brain says there was a good reason.

Maybe I'll remember if we write a test suite for it.

We should make a whole module of math functions, with test code. 
Let the REBOL optimizer at it and then see what we can include.

The "REBOL optimizer" is a running joke. The best way to optimize 
your REBOL code is to post it publicly in AltME or R3 chat and dare 
people to improve it. Then the community tries to one-up each other 
to improve it :)

Bolek, THROW and CATCH work in R3 but there is a strange interaction 
with TRY.

Graham: my reply from R3 Chat:  I think that we will not get much 
refinements for read/write functions. The planned ones were /string 
(text) and /as (enconding). What you want is read working in a streamed 
way. We might get it in future, but I doubt we get what you propose.

hmm, but /as was proposed to specify just type of encoding IIRC, 
not some other functionality ... some of us wanted /as being more 
general, allowing you to specify a codec to decode. Codecs are so 
far inefficient (not streamed), because you have to read all data 
firts, then pass it to encode/decode.

Carl never posted a resolution to read/write case ....

I think my schemes are making R3 unstable.  Tried to post a message 
and got from chat


rebol system error #1301: invalid datatype 99 ... should never happen 
...

Well, we don't need of specific refinements, cause we can pass a 
block to read (which is converted to a port!).

>> read [scheme: 'ftp host: ... path:... other_data: ....]


The  block format could be used to pass other parameters in a more 
handy way.


>> read [ftp://ftp.rebol.com/matrix.avifile: %movies/matrix.avi]


And the good news, is that it's absolulty possible to have something 
like that now.
We just have to patch the function: system/intrinsic/make-port

Well, I am using a write spec block ...

Steeve .. don't waste your time on a r2 chat .. there's no traffic 
on there.  Spend your time on schemes :)

We need a place to set a system timeout ...

To my mind, we need a better framework to design shames using a FSM 
dialect

Or do you mean use a dialect to define the scheme?

yes a dialect to construct schemes

Ladislav has done one too. Time for a FSM battle?

I suspect that you have to write a few schemes to see what is needed 
and then write the scheme dialect

yup we should start with the html one in R3, it's a huge one currently

http://www.rebol.com/r3/docs/functions/write.html


says there is a /binary refinement .. but this doesn't exist any 
more

my implementation of PIPE is only a few lines. i think it should 
be native to R3.

Graham, weird, but you can try:

>> switch to-word type? %test.r [file! [print "... a file"]]
... a file

so return of 'type? is not a type? Well, we have not a datatype type? 
Yes, we have - datatype! .... but help reveals you can't do "to-datatype" 
...

why is datatype a word? :-)

It may look confusing, but it makes perfect sense, it same as:

>> a: 1                 

== 1


>> type? first [a]       

== word!

>> type? first reduce [a]
== integer!

Rebolek - then switch should be supplied a reduced block :-)

We are not talking about block here, but a function body. And if 
I write switch type? %user.r [file! [print "... a file"]] ... it 
is imo supposed to work ...

...switch should be supplied a reduced block

no, that's wrong. See:

>> a: 1
== 1
>> switch 'a [a ["ok"]]
== "ok"


>> switch 'a reduce [a ["ok"]]

== none

>> a: 1
== 1
>> switch a reduce [a ["ok"]]
== "ok"

how is novice supposed to know, that actually submitting result of 
type? %user.r is not going to work with file! datatype in a switch 
body?

Help string to 'switch does not reveal much. And docs are imo even 
incorrect:


Switch also returns the value of the block it executes. The cases 
can be any datatype. If none of the other cases match, use the /DEFAULT 
refinement to specify a default case.

Or maybe a new mezz would be good to have.

Krenzelokize: func [bum this [block!]][
	switch type?/word bum this
]

It was Graham who actually asked, how is he supposed to handle datatype! 
datatype in 'switch function. If he was confused for a fraction of 
minute, then novices could be confused too. The function behaviour 
is inconsistent, at least in reference to docs, period. Even if I 
never used type?/word (as I don't work with dynamic code much), I 
used to-word type? value in 20 seconds, so I found may way around 
the "problem". 


Maybe now I understand, why some external ppl see REBOL community 
as bunch of "we are best, we know the best" luxury fools - we try 
to make idiots from ppl not actually as knowleable as some elite 
members.

Pekr my friend, it was just a little tease :-)

Pekr, you may be right about correcting docs, I'm not sure, haven't 
read them in a while. But in all other aspects you are wrong. What 
you want is basically same as what that crazy spammer on blog wanted 
few weeks ago. Blocks always reduced.

I agree that it may look confusing to some people, same as:

>> f: func [a][append [] a]       

>> f 1
== [1]


>> f 2

== [1 2]


But as I said, it's better to understand why works this way than 
dumbening the language just because newbies may be confused.

no, you don't understand. It is just you understanding the only one 
holy way - submitting function a regular REBOL code :-) Whereas I 
was just wondering, with rather uniform design of switch (case followed 
by code to execute), if we could supply kind of dialect to switch 
function as a body. The same way as how we have 'secure, 'get-modes 
or other dialects ...

switch works with datatype!, if you use a datatype! (read a true 
datatype!)  in the block.
see 
switch type? %test.r [#[datatype! file!]    [print "type file!"]]

Pekr, "The cases can be any datatype" refers to the type of the values, 
not their value. The type of integer! is datatype!, the value is 
#[datatype! integer!]. You can use the serialized syntax if you want 
to specify dataype! values directly, but watch out: If your build 
process goes through a MOLD then the serialized syntax will be lost 
- this tripped me up when I was porting R2/Forward to the R2 mezzanine 
code, I had to rewrite TYPES-OF and TO-TYPESET.

There was a suggestion that SWITCH treat certain words as keywords, 
translating them to their standard values, in particular logic! and 
datatype! keywords. This would make SWITCH work like CONSTRUCT, and 
would likely require an /only refinement for the non-keyworded behavior 
like CONSTRUCT has. This would add a little overhead to SWITCH, but 
not as much as the workaround code already adds. The question hasn't 
yet been resolved, and should be brought up again for final resolution 
- some mezzanine code would need revising.

I just checked it.
loading after a mold/all still gives the datatype!

Steeve talked about using a dialect to write schemes .. to create 
the FSM needed ... weren't you also doing something along these lines 
as well?

^-- Actually, it need not keep you from writing (to-word type? foo) 
if it knew that datatypes should have the last ! chopped if turned 
into a word

It's been hard to get enough spare time with a working brain. Too 
many emergencies lately that take up my time, mostly my sleep time.

If I have 

a: :print 
or
a: %file.txt

how can I check for what it is ?


switch type? a [ function! [ print "function" ] file! [ print "file" 
]

switch type? a reduce [ function! [ print "function" ] file! [ print 
"file" ]

switch to-word type? a [...

switch type?/word :a [...

case [any-function? :a [...] file? :a [...]]

CASE is used for that stuff a lot in the mezz code.

there's this example on http://www.rebol.net/wiki/Port_Examples

 copy-file: func [
       "Copy a large file"
       from-file to-file
       /local file1 file2 data
   ] [
       file1: open from-file
       file2: open/new to-file
       while [not empty? data: read/part file1 32000] [
           write file2 data
       ]
       close file1
       close file2
   ]

Does the skip occur automatically on a file port?

If I write a 100Mb file to a tcp port ... does R3 automatically write 
it in chunks for me?

I would expect so, but you'd block your task! until it was done if 
you do it in one WRITE. And that means blocking quite a bit until 
tasks are properly working.

You can use async by providing a handler, or use one of the sync 
wrapper functions. If you use the sync wrappers it is still internally 
async, but not as far as you know.