World: r3wp

aha, thanks

>> 10.10.10 * 1.5
== 15.15.15
>> green
== 0.255.0
>> green / 2
== 0.127.0
>> green * 0.3
== 0.76.0

tuple * float works :)

it also work in this way :
 divide 0.15.0 2
== 0.7.0

this kind of stuff could be very interesting in imagery ... thanks 
for you reflexion

I have an interesting problem with FTP.  I'm using FileZilla on my 
server and I get the following entry in the log file:

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> 150 Opening data 
channel for directory list

(000032) 1/20/2007 9:16:58 AM - lechnowsky (*IP*)> 425 Can't open 
data connection
(000032) 1/20/2007 9:56:52 AM - lechnowsky (*IP*)> disconnected

During that same period, Rebol's trace/net states the following:

Net-log: ["LIST" ["150" "125"]]
Net-log: '"150 Opening data channel for directory list."

Rebol, never returns from that.  It seems to be a bug in Rebol's 
FTP handler as it doesn't ever time out and continue, it just locks 
up.  I have to press "Escape" to get out of it.  I've left it for 
up to 12 hours and it still doesn't return.

Any ideas?

are you using the latest version 1.3.2 of rebol? I think there are 
some serious patches to FTP somewhere, but I can't remember if they 
made it official.

I'm using the SDK and I'm including sdk-2-6-2/source/prot.r which 
should have the FTP protocol in it.  Does anyone know if there is 
a newer version of prot.r other than sdk-2-6-2?

that's the latest

I presume that the problem is just with the one server?

I think all of Romano's patches http://www.rebol.it/~romano/ftp-patch.r
were incorporated already.

Well, I haven't tried it with a different FTP server, but it definitely 
appears the problem is on the Rebol side.

I've considered installing WarFTPd or something, but this is a production 
server and I don't want to mess anything up by having two FTPd's 
installed simultaneously.

I'm not even sure it is an FTP issue.  The timeout should be triggered 
by Rebol's networking kernel, shouldn't it?

when it hangs, does it use CPU time?

(I meant "I'm not even sure it is a Rebol FTP protocol issue")

No it doesn't use any CPU time.  All stats on the process flatline. 
 No I/O, no CPU, no page faults.

This is part of the application I wrote called Smooth-Copy which 
I am using as a remote backup utility for some of my clients (and 
my wife's laptop, from which I got these results).

Also, I am using FTP in passive mode.

I am overwhelmed with projects presently, and I'm willing to pay 
if someone can come up with a patch to prot.r for FTP (if that is 
where the problem exists).  I would also allow the patched prot.r 
to be released back to the community.

the problem is that it may be just with a particular ftp server ...

But it seems the FTP server is working properly according to the 
log file.  If it cannot retrieve the directory listing, it sends 
a 425 and then eventually disconnects.  In any case, Rebol should 
never hang indefinitely even if the FTP server misbehaves.

Some FTP problems can be bypassed with:
system/schemes/ftp/passive: true
(Don't ask me why!)

We posted the complete source to our FTP client interface, you will 
find the code to handle most of this.

ftp-gadget i guess? http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ftpgadget-package.r
And  you can try it with the gui first :)

if not, can you make an account to trace and try?

Sunanda: Yes, I am running in passive mode.

Reichart: Thanks for posting the source code.  Unfortunately, it 
doesn't look like it can be used like the standard FTP protocol in 
Rebol as it is integrated with your GUI.

Shame.  I remmember when we had to build that, I had indeed asked 
it be made a module, so that suprises me,

I downloaded the source code and upon quick inspection, it doesn't 
look like I could use the FTP by entering ftp://user:[pass-:-server], 
but I could be wrong.

Bo, I've done a bit of FTP hacking. Maybe I can find the bug.

does  ftp-gadget work with your server by gui? eg is the ftp-part 
good enough? If not, where can we test against that server?

Probably because some servers require passive mode? ;-)

Bo: Also, I am using FTP in passive mode.

Bo: arent you behind firewall?

Oops, wanted to cite bo, ntoto address him. He said he  uses passiv 
modea while ago.

I do not know, if it will help you, but I check the cached connections 
in systems/schemes/ftp/handler/connections for any already closed 
connection before doing an ftp action.

is ftp-gadget still much better  then ftp? looks like  a module with 
gui-callbacks to me. and i spottet the word "async" somewhere.

if all [	

 lock: wait join copy [0:0:0.001] system/schemes/ftp/handler/connections 
 ; problems with closed, but still cached connections
	none? copy lock
] [
	close lock
	remove find system/schemes/ftp/handler/connections lock
]

is there a way to "trace" where you read or 'do'ed a file from? would 
be handy if you had a script that could tell whether it was run from 
a webserver or from a local disk

I don't think you can. But check system/options and system/script 
. You could also pass an argument in using do/args.

I think this could be really useful. In fact I think I'll RAMBO it. 
:-)

I agree. But be careful what you wish for.

security?

webserver, disk, random example or exactly that? becausewith  webserver 
(-c) you have stuff in the  cgi-object. Carl uses that  to decide 
 if it  is  a testrun.

The problem I'm having is that most FTP transfers work fine, but 
somewhere along the line (say after 50 FTP connections or perhaps 
as many as a couple thousand FTP connections) one of the connections 
hangs up (presumably because the FTP server returned an unexpected 
response, like not being able to open a directory).

I've set up an FTP user for testing on our server called "rebol3" 
with the password "rebol3".  This user has all permissions in its 
sandbox directory.  Feel free to test, but as I said, it may take 
thousands of FTP requests to get one that locks Rebol up.