World: r3wp

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

what version?

(I used rebol/version == 1.3.2.3.1)

I mean, that didn't know that it's a problem:)

aha, sorry for misunderstanding

i don't think it's known, otoh /seek is known to have a few problems 
so it's not really surprising. :)

thanks - RAMBO #4235

Anton - you ran into yet another case of nontransparent argument 
passing. Let me repeat - I don't like nontransparent argument passing...

It's just funny because FOREACH is used so often.

I guess FOREACH would suffer much if the first argument was expected 
to be always a block!

would not suffer

try this:

foreach': func [
    "Evaluates a block for each value(s) in a series."

    word [word! block!] {Word or block of words to set each time (will 
    be local)}
    data [series!] "The series to traverse"
    body [block!] "Block to evaluate each time"
] [
    foreach :word :data :body
]

(it is a referentially transparent argument passing variant)

The second and third arguments look like they are already referentially 
transparent, but I suppose you are ensuring this in case FOREACH 
ever changes its spec.

Has anyone got smtp to work with gmail ?

I cloned the esmtp protocol to use on port 465, and added a /secure 
to 'send so that it uses my new ssmtp protocol.

I changed  the open-proto to open-proto/secure/sub-protocol port 
'ssl in the new ssmtp protocol.

I can send like this

set-net [ [compkarori-:-gmail-:-com] smtp.gmail.com ]
send/secure [compkarori-:-gmail-:-com] "testing .. "


and a trace/net shows that it sends the message but then hangs waiting 
for a 250 response from the 'check-write

oh crap .. web-public channel ... going to get spammed now :(

mucking around, i changed the system/words/insert port/sub-port "^/." 
to system/words/insert port/sub-port "^M^J.^M^J" and that gives an 
error.

oh crap
 <-- isn't this another peeve?

added to checklist