r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Ladislav
29-Jan-2007
[6954]
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?
Chris
29-Jan-2007
[6955x2]
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 :)
Pekr
29-Jan-2007
[6957x2]
Chris - you gained nice knowledge on ports!
what about DevCon session? Will you attend? So far only Carl has 
registered his session ....
Chris
29-Jan-2007
[6959x3]
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.
Pekr
29-Jan-2007
[6962x2]
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 ....
Graham
29-Jan-2007
[6964]
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.
Maxim
29-Jan-2007
[6965x2]
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.
Anton
30-Jan-2007
[6967x2]
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]
]
Oldes
30-Jan-2007
[6969]
anton, because you set vars for each value:)
Anton
30-Jan-2007
[6970]
omg. it stares me in the face.
Oldes
30-Jan-2007
[6971x2]
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]
]
Anton
30-Jan-2007
[6973x2]
ah nice, I was about to something with DO COMPOSE
Thanks... :)
In my actual code it was really confusing.
Oldes
30-Jan-2007
[6975]
maybe it would be good to give this into FAQ or something like that, 
if it exists:)
Anton
30-Jan-2007
[6976]
Hmm... I'm not sure. I think the problem is that of coding too many 
hours without rest.
Oldes
30-Jan-2007
[6977]
it's not so late:)
Anton
30-Jan-2007
[6978]
Should put that in the FAQ: "How many hours should I code before 
taking a break ?"
Oldes
30-Jan-2007
[6979]
It depends how strong you are:)
Ladislav
30-Jan-2007
[6980]
insert/dup looks like not working when used on /binary/seek ports. 
Is that a known issue?
Oldes
30-Jan-2007
[6981]
for me not
Ladislav
30-Jan-2007
[6982x2]
what version?
(I used rebol/version == 1.3.2.3.1)
Oldes
30-Jan-2007
[6984]
I mean, that didn't know that it's a problem:)
Ladislav
30-Jan-2007
[6985]
aha, sorry for misunderstanding
Gabriele
30-Jan-2007
[6986]
i don't think it's known, otoh /seek is known to have a few problems 
so it's not really surprising. :)
Ladislav
30-Jan-2007
[6987x2]
thanks - RAMBO #4235
Anton - you ran into yet another case of nontransparent argument 
passing. Let me repeat - I don't like nontransparent argument passing...
Anton
30-Jan-2007
[6989x3]
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
Ladislav
31-Jan-2007
[6992x2]
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)
Anton
31-Jan-2007
[6994]
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.
Graham
1-Feb-2007
[6995x7]
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.
Henrik
1-Feb-2007
[7002x2]
oh crap
 <-- isn't this another peeve?
added to checklist