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

World: r3wp

[!REBOL3 Schemes] Implementors guide

Graham
11-Jan-2010
[1124]
I guess that's a no no ...
eFishAnt
11-Jan-2010
[1125]
wow, you guys are rockin!  Thanks Steeve, for the dns2.  Funny, that's 
how my wife says my name when she wants something..."Oh Steeeeve."
Andreas
11-Jan-2010
[1126]
someone said so, yes :)
Graham
11-Jan-2010
[1127]
so fish .. where's your codec ??
Andreas
11-Jan-2010
[1128]
but changing the WAIT inside the awake to a READ doesn't change things 
:)
Graham
11-Jan-2010
[1129]
a system read?
Andreas
11-Jan-2010
[1130]
unless you do something special, there's only system reads for tcp 
ports
Graham
11-Jan-2010
[1131]
no binding for me
Andreas
11-Jan-2010
[1132x2]
even for the scheme port, there's only system read
but the system then dispatches this to the read actor
Graham
11-Jan-2010
[1134]
and my read actor does a wait
Andreas
11-Jan-2010
[1135x2]
yeah, but inside wait-cmdport you're WAITing on the cmdport
inside write-cmdport*
Graham
11-Jan-2010
[1137]
fix it please :)
Andreas
11-Jan-2010
[1138x4]
change line 212 from `wait cmdport` to `read cmdport`
doesn't fix the long lags, though
in fact, you can drop this line completely, i think
because a WRITE on the tcp port from within the tcp port's awake 
handler automatically re-schedules the tcp port for event handling
Graham
11-Jan-2010
[1142]
ok, working with line removed ..  but still delays
Andreas
11-Jan-2010
[1143x12]
mhm
only chasing thru your code, atm :)
ok, the flow should be, imho:
- read WAITs on the cmdport

- if the cmdport needs to open a dataport, cmdport WAITS on dataport
port/state/connection is your cmdport, if i'm not mistaken
so i started by changing the read actor to:
		read: func [port [port!]] [
			wait port/state/connection
		]
which should break things hard :)
and yes it does, hangs after SYST
next step: tracing if your awake handler returns true in this case
wuah, huge switch :)
but, as expected, it does not :)
client/spec/ready seems to be a good flag to use as return value 
for the awake handler
unfortunatly, in the AUTH 230 handler, you set both ready to true 
_and_ issue another write
assuming that the SYST is rather worthless anyway, i drop the write
Graham
11-Jan-2010
[1155]
ready is set to true so I can process the SYST
Andreas
11-Jan-2010
[1156]
i'll abuse ready is the return value from the awake handler, for 
now :)
Graham
11-Jan-2010
[1157]
I did this as otherwise I ended up pipelining the ftp server :(
Andreas
11-Jan-2010
[1158]
don't they like that :) ?
Graham
11-Jan-2010
[1159]
not if they don't support pipelining!
Andreas
11-Jan-2010
[1160x2]
:)
btw graham, do you happen to have heard of git?
Graham
11-Jan-2010
[1162]
repository thingy?
Andreas
11-Jan-2010
[1163x2]
yep
used it, by any chance?
Graham
11-Jan-2010
[1165x2]
yes :)
nope ...
Andreas
11-Jan-2010
[1167]
wow, fixed it :)
Graham
11-Jan-2010
[1168]
Umm... does Ubuntu use git ??
Andreas
11-Jan-2010
[1169]
i use git
Graham
11-Jan-2010
[1170]
I know I installed something which failed to work for me ... in downloading 
from the ubuntu repository
Andreas
11-Jan-2010
[1171]
and if you'd be using it too, developing protos together would be 
much more fun :)
Graham
11-Jan-2010
[1172]
so what's the fix?
Andreas
11-Jan-2010
[1173]
dropped the SYST write from 230