World: r3wp

If I find a solution, I'll post the fix and let you know.

Yup, just verified that Rebol always hangs up when the FTP server 
logs a 425 response: "425 Can't open data connection"

I've found THE LINE that Rebol hangs up on when the FTP server returns 
a 425 response.  It is the line with the ;<--- after it below:

	accept-connect: func [port type][
		if not port/locals/passive [
			either port/locals/listen-port [
				if type <> 'new-dir [
					port/sub-port: first port/locals/listen-port ;<---
				]
				close-listen port
				port/locals/listen-port: none
			][
				net-utils/accept-proxy port/sub-port
			]
		]
	]

Obviously, it is in an infinite wait for a listen port that will 
never come.  Can you see any problems if the line were changed to:


if port? lstn-prt: wait [any [system/schemes/ftp/timeout system/schemes/default/timeout 
30] port/locals/listen-port][port/sub-port: lstn-prt]

there should  be a timeout, yes. Would  trigger an error too, how 
 is that done in the right way with ports? Because i do not know 
what this code  does without a port/subport.

what confuses  me, this code runs also in passive  mode?


an idea of mine is to listen on both ports, control and this one. 
if the server sends the 405, its never processed because we dont 
listen there. Should  listen on both ports and still handle commands. 
But do not know what the  right vars are.  Waiting for the skilled 
 ftp-patchers  before examining^^

In limited testing, my patch above (slightly modified to remove typos) 
works.  If the 425 occurs, after a timeout period the patched protocol 
picks up right where it left off.  But yes, I would really like the 
skilled ftp-patchers to take a look at the problem and see if they 
can come up with a better fix.

Grats :)

Are you sure that this happens in passive mode, despite  " if not 
port/locals/passive [  "


I found this line also to be the cause for infinite waiting when 
using ftp with active mode thru a firewall . But activating the passive 
mode eliminated the need for a patch on  my side.

Anyone got a quick script I can use to determine the ip address of 
a PC on the local network?

I presume I need one server script and one client script

Graham: do you mean IP adress of your computer?
>> read dns://
== "boleslavb967"
>> read dns://boleslavb967
== 10.10.8.179

no

I just get 127.0.0.1 when i do that.

it's a virtual nic ...

then I'm afraid I don't know :/

maybe there's some linux command that will tell me

like windows ipconfig

ifconfig :)

there was a script which lists all  the available interfaces. bBsed 
 on 'get-modes IIRC. But  forgot  where i saw it.

IIRC Robert and the author where chatting  once, maybe  he remembers?

sqlab: I'm double-checking my code...

get-modes tcp:// 'interfaces

works nicely

Is it possible to get the MAC address as well?

I don't think I've ever seen it directly in rebol.

I think that would be a security hole.

why?

just run ipconfig /all via shell and parse it out ;-)

The ultimate cookie

ok, is this bad? Rebol/View under OSX:

>> stats
== -741616872

Has anyone got an overview of how the internet protocols work?

Jeff wrote an article on custom protocol handler  .... are there 
any other tutorials around?

Check Chris' stuff in the Sandbox group.

This thread may help a little: 

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlHBNQ

Thanks.

henrik, unless rebol is using more than 2gb, i guess there must be 
something wrong :)

Henrik: it seems to be very bad. But it looks that OSX will not be 
such a bad OS if it allows you work even with apps eating so much 
memory.

it took some time to swap things back into memory. the script was 
working just fine though.

I had a rugby script running all night that would periodically download 
1 MB of data from another machine. I guess there was a leak. :-)

I don't think it's fine if your script need so much memory:)

but it still ran instead of crashing. I think that's good, but isn't 
stats in need of a fix if it can't display mem usage above 2 GB?

that's because rebol don't have unsigned integers

and probably nobody was expecting, someone will need so much memory

BACK versus past-tail indices. Every index (except for 1) may become 
past-tail during the execution of a script (when its block/string 
"shrinks") and "legal" again (when its block/string grows sufficiently). 
Let me mention the SAME? function as an example of a consistent behaviour 
- no matter whether the index is past-tail or not, the SAME? function 
takes it into account when comparing series. The BACK function, however, 
handles past-tail indices differently than the "normal" ones. any 
wishes/notes/proposals?

Graham: re ports, there's not much art to it.  You try and break 
up access to any particular service according to supported accessors. 
 Almost all built in protocols are wrappers to a TCP port, containing 
all the commands for that particular protocol.  Note that 'read on 
a port uses 4 accessors: init, open, copy, close; 'write also uses 
4: init, open, insert, close; 'make will call 'init, whereas 'open 
will first 'init (unless you provide a port! as your argument -- 
eg. open make port! foo::bar), then 'open.  You can use all the other 
accessors on an open port: insert, change, remove, etc.  And of course 
'query which you can assign to provide information about the port 
without opening it.  I'd be happy for anyone to elaborate or correct 
this description...

The sandbox port I wrote may serve as an example, except that it 
wraps a file port and not TCP.  I hope to put together an article 
on this (before ports are changed completely in R3 :)

Chris - you gained nice knowledge on ports!

what about DevCon session? Will you attend? So far only Carl has 
registered his session ....

HTTP is broken up thusly -- INIT breaks down the url/spec, OPEN actually 
does all the heavy lifting, sending the request and parsing the response, 
COPY takes the final download from the buffer, and CLOSE closes the 
TCP port.

Petr, I don't think at this point I'll be able to attend, much as 
I'd love to.  Besides, ports are due for an overhaul in R3, so I'm 
not sure it's the best area for exploration right now.