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

World: r3wp

[!REBOL3 Schemes] Implementors guide

Graham
19-Feb-2010
[2010]
The issue in updating an area is to show the new text ... which may 
be out of sight unless you somehow force the area to scroll down 
to the new text
ChristianE
19-Feb-2010
[2011x5]
Gabriele, thanks for the clarification. I'll give it a try over the 
weekend.
On first examination, executing the following code seems like an 
unexpected error. Doing
port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    switch/default event/type [
        read    [prin "read:"    copy  port]
        lookup  [prin "lookup:"  query port open port]
        wrote   [prin "wrote:" ]
        connect [prin "connect:" read  port]
        ready   [prin "ready:"   close port]
        custom  [prin "custom:"]
        done    [prin "done:"  ]     
        close   [prin "close:" ]
        error   [prin "error:" ]
        custom  [prin "custom:"]
    ][
        true
    ]
]
open port
wait port
gives
connect:wrote:read:custom:** Script error: res: needs a value

** Where: either case check-data either switch check-response switch 
applier wake-up loop applier wait catch either applier do vv
** Near: either headers/content-length <= length? port/data [
    sta...
Graham
19-Feb-2010
[2016x2]
in prot-http.r, in http-awake function, there is a switch statement

res: switch state/state


try adding a switch/default instead

and use 'none for the default to see what happens
and probe state/state to see what value might be causing this error
ChristianE
20-Feb-2010
[2018x6]
HTTP-AWAKE is the event handler for the underlying TCP port, from 
my understanding the awake handler for the HTTP scheme should be 
way simpler.
I'm getting better results with
port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    prin join event/type ":"
    
    switch/default event/type [
        connect [read  event/port false]
        ready   [read  event/port false]
        read    [query event/port false]
        custom  [copy  event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port
That gives the following output:
connect:wrote:read:read:custom:done:
But at the 'DONE EVENT/TYPE it then hangs. By returning TRUE there 
the AWAKE handler normally should awake the port, making the WAIT 
return.
Graham
20-Feb-2010
[2024x2]
this is true for a tcp port, but this is a http port, and Gabriele 
has two handlers there, one of which is creating custom events.
Since your code is handling custom events, I presume that you're 
handling the events generated by the main awake handler ...
ChristianE
20-Feb-2010
[2026x7]
Ok, this is confusing, and it doesn't help that I have absolutely 
no expertise in that networking stuff. It doesn't help, I'll have 
to dive in anyway. So excuse me when occasionally I come here panting 
for some air before drowning ;-)
It seems to work fine, reading the page like it should:
port: make port! http://www.rebol.com
port/awake: funct [event] [
    prin join event/type ":"
    
    switch/default event/type [
        connect [read event/port false]
        ready   [read event/port false]

        read    [probe length? event/port probe query event/port false]
        custom  [probe to string! copy event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port
It just doesn't return when it's DONE. Even though the last state 
is that DONE state and the awake handler returns TRUE. Reading further 
...
The CUSTOM event/type is generated by the lower level TCP awake handler, 
with event/code set to zero when transfer is completed. So, TCP-awake 
calls HTTP-awake with an event with event/code:0 and event/type: 
'custom
And it makes no difference if at that point I return TRUE or FALSE, 
the wait hangs
To me, it almost looks like things aren't working "as advertised", 
which may be because docs and code aren't properly sync'ed.
Gabriele
20-Feb-2010
[2033]
Graham: I suspect that your problem is simply that you have to wait 
on all the ports (including events), not just the network port. Don't 
forget that R2 has a "hidden" list of extra ports to wait for (system/ports/wait-list), 
while R3 does not AFAIK
ChristianE
20-Feb-2010
[2034]
Yes, that's what I'm after, Gabriele. Opening a network port and 
then waiting for network, time, or gui events.
Gabriele
20-Feb-2010
[2035]
Christian: does the example on the wiki work? If not, then something 
has been changed since then, and I can't help much without studying 
everything back again. If so, then maybe we can figure out why your 
version does not work.
Graham
20-Feb-2010
[2036]
studying your own code ?  :)
Gabriele
20-Feb-2010
[2037x2]
ie. this one:

   port: make port! http://www.rebol.com/
   port/awake: func [event] [
       switch event/type [
           connect [read event/port]
           done [print copy event/port return true]
       ]
       false
   ]
   open port
   wait port
Graham: mostly, the changes in R3, and trying to figure out how it 
works now. It's not like there are docs with enough details...
ChristianE
20-Feb-2010
[2039]
Gabriele, that's the main point of confusion to me, that even that 
example fails. I.e.. hangs when DONE, in the same way as my attempts 
on this.
Gabriele
20-Feb-2010
[2040]
Ok, so it's not your fault. R3 has changed and the HTTP scheme does 
not work correctly anymore.
ChristianE
20-Feb-2010
[2041]
Good to know. I like the line "It's not like there are docs with 
enough details..."
Graham
20-Feb-2010
[2042x2]
I think I read somewhere Brian saying that http had to be modified 
as chunked encoding didn't work or something like that
But the source was modified and not the rlp
Pekr
20-Feb-2010
[2044]
IIRC http was degraded to 1.0 from 1.1 due a problem Graham describes 
...
Graham
20-Feb-2010
[2045x3]
Isn't there a source code revision history somewhere??
so we can see exactly what was changed?
Looks like we need a set of unit tests for the protocols ...
BrianH
20-Feb-2010
[2048]
All changes to the source are in DevBase.
Graham
20-Feb-2010
[2049x2]
devbase??
last contribution to devbase was 1 mar 2009 by yourself
ChristianE
21-Feb-2010
[2051x6]
More likely than changes to the http-prot source being the reason 
for the async behaviour not working as expected are changes to the 
core itself.
That's my guess.
I tried against Gabriele's original pto-http sources as from the 
*.rlp, not the *.r as touched by Carl. Only thing I changed was two 
replacements of THIRD with BODY-OF.
No luck even with older R3 versions; version 2.100.33.3.1 dating 
back to 2009-01-28 being the oldest I have around.
*pto-http = prot-http
Graham, all changes to the prot-http sources seems to be authored 
by Carl, I've seen no traces of changes to the protocol introduced 
by Brian.
Graham
21-Feb-2010
[2057]
Andreas and I did the same, doing a diff on the original prot-http 
and current and found no major changes.  Suggest submit a bug report.
BrianH
21-Feb-2010
[2058x2]
DevBase is the forum/filestore that you access withg the CHAT command 
in R3.
I haven't posted changes to the http protocol yet, sorry.