World: r3wp

Ok, so how should I write the code, which will eat the 4 chars and 
change the position if I don't want to return the new b from the 
function

as I said: you cannot change the index of a series, so the only possibility 
is to share the variable

Ladislav, I though the 'b in function 'ri is different from the 'b 
in global context so that's why the index differs.

actually the error lies in the fact, that many users think, that 
SKIP changes the index of a series. It actually doesn't:

b: "1234"
index? skip b 2 ; == 3
index? b ; == 1

but than it's quite useless... I wanted to do a function read-integer 
buffer and etc. and make it universal:( 

I know, I can set buffer as global variable (or in the context) and 
do just read-integer etc.

you don't have to, the following works too:

ri: func [b [word!] /local i] [i: copy/part get b 4 set b skip get 
b 4 i]

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