World: r3wp

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.

That said, I find as an abstraction layer, they are super useful. 
 I've been thinking about an adapter! datatype that replaces ports 
for data abstraction layers.

I do remember some talks with DocKimbel when he actively developed 
R#. He told me that he would use two-fold aproach to port - separating 
low-level stuff, enabling more abstracted implementations above it 
....

let's see what comes with R3 ....

I just find the way protocols are done wrap the abstraction so tightly 
that you can't insert arbitrary command into a port without rewriting 
the protocol.  Eg. adding the TOP command to POP.

the one thing I find strange comming from carl, is the fact that 
within Amiga, everything was a hook.  so you could very easily re-implement 
everything... and most of the deep internals of  REBOL are pretty 
boxed in... the stuff is still in box... but opening most of these 
secrets is like opening a can of worms...

add to that the irritation cause by static binding.. which is cool 
for many things, but has this side effect of making many run-time 
code change much harder.

Eh? what's happening? Why are these different ?

id: 0 foreach [a b c] [1 2 3 4 5 6] [print id: id + 1]


use [vars id][
	vars: [a b c]
	id: 0 foreach vars [1 2 3 4 5 6] [print id: id + 1]
]

anton, because you set vars for each value:)

omg. it stares me in the face.

you want to do:

use [vars id][
	vars: [a b c]
	id: 0 foreach :vars [1 2 3 4 5 6] [print id: id + 1]
]

ah nice, I was about to something with DO COMPOSE

Thanks... :)
In my actual code it was really confusing.

maybe it would be good to give this into FAQ or something like that, 
if it exists:)

Hmm... I'm not sure. I think the problem is that of coding too many 
hours without rest.

it's not so late:)

Should put that in the FAQ: "How many hours should I code before 
taking a break ?"

It depends how strong you are:)

insert/dup looks like not working when used on /binary/seek ports. 
Is that a known issue?

for me not