World: r3wp

b: "1234str" probe ri 'b

yes, that's it, thanks:-)

sorry, Cyphre, it looks that my explanation is exactly the same as 
yours :-)

anyway, it looks, it would be better to use some version with the 
buffer as variable in the context:(

isn't it too many operations to just get a string?
read-str: func[b [word!] /local s nb][
	s: none
	nb: get b
	error? try [
		i: index? nb
		s: copy/part nb i: (index? find nb #{00}) - i
		set b skip nb (i + 1)
	]
	s
]

If by '"eat " you mean permanently remove then :

b: remove/part b 4

As a function:

>> b: "1234str"
== "1234str"
>> ri: func[b] [b: remove/part b 4]
>> probe ri b
str
== "str"
>> probe head b
str

rather not to remove, just skip:-)

Oldes, you don't need to 
	s: none

S is a local and locals are automatically set to NONE for you. (Unless 
you are using a very old rebol.)

that's true:-)

This is how I would do it.

read-str: func[buf [word!] /local result pos][
	if pos: find get buf #{00} [
		result: copy/part get buf pos
		set buf next pos
	]
	result
]

>> my-string: #{11221122003344334400}
== #{11221122003344334400}
>> print mold read-str 'my-string
#{11221122}
>> print mold my-string
#{3344334400}
>> print mold read-str 'my-string
#{33443344}
>> print mold my-string
#{}

That looks much more better, thanks:-)

add 0.0.1 0.0.255 ; == 0.0.255 looks rather surprising to me. any 
opinions?

makes  sense when used with colors

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.