AltME groups: search

the .r file is generated by Wetan, it was provided in r3-alpha together 
with the .r and the .rlp, but is probably not on r3 chat.

I followed the example to the letter with my url . ... and I get 
none

And now it's a module and hidden !

Anyway, there does appear to be some type of bug that is setting 
state to none in the port .. and so query returns none

it is possible... it's not like this was greatly tested (back then, 
not many people volunteered to test...), and it was written for a 
very different R3...

oh .. have to restart rebol and set secure

one of the things i wanted to do, but never got to, was to parse 
the output of R3's trace, and then show you a step-by-step code execution 
like in debuggers.

if trace were to add timestamps as well, then it could be used for 
both debugging and profiling, even on programs running on other people 
systems (they just save the trace, and you just load them).

http://www.colellachiara.com/soft/MD3/emitters/wetan.r
and http://www.colellachiara.com/soft/MD3/emitters/wetan.html

Documentation in the code itself using comments, and you structure 
the code for human reading. To any programmer of a language that 
is designed for readability - like REBOL - reading the flow of the 
code is like reading a story. You can understand it immediately.


Reading a literate programming document is like reading a manual 
though, so unless it has story or essay structure it will be difficult 
to understand. Reading the code generated by literate programming 
is like reading a stack of 3.5 index cards that were going to be 
used as research for a story or essay, but were instead just taped 
together at random. The overall structure of the code and every hint 
of the author's intentions are lost.

I've had a go at this the simplest of schemes and can't get it working 
... 

http://rebol.wik.is/Rebol3/Schemes/Daytime

I grabbed stuff from Carl's demos and Gabriele's http protocol

yes but your actors (open and/or read) must create a tcp port thru 
the host

(graham's link above is not complete. there are a few pieces missing, 
and they are missing because the code, even tough it works, is crap 
:)

It is also quite hard to cut and paste as the console doesn't support 
it ..except as a dos console

Have to use the clipboard to transfer stuff to and from the r3 alpha 
console

R2 could be used... but, I had "imagined" there were better packages 
that we could use and get a full featured console.

Le's be practical and reuse R2

the most practical is to make it usable for users and optimize later 
on

lacking cut and paste as now is somewhat even more backward!

Feels like the original console of 1998 which also lacked cut and 
paste if  I recall correctly

and what about a graphic console (with gobs) ?

The windows console in Windows 7 is very odd ... if you maximize 
it , it shifts to the left hand side of the screen.  Try and move 
it and is shrinks back again :(

so, if you want to read the examples on a web page ( usuaally placed 
on the left ) and have an maximized console open .. you can't see 
both

Rich organisations and people are rich, for one reason, by not spending 
it

Anway, we can go the custom route on the console.  But, we'll need 
help with that on Linux (whatever desktop) and OS X, etc.

G: yes... and more than spare cycles. But, the list is long.

schemes would be a nice place to start .... we need to get smtp, 
and pop done.

Graham, perfect for a third party to do (and has been for about a 
year).

And we're not Gabriele ...

If you're working with a line oriented protcol .. do you save the 
buffer to your own buffer and work on it line by line ( deline ) 
?

We never learn, and I write documents for nothing :-)

There's many ppl out there, who will want to try REBOL as a tool, 
and have ABSOLUTLY NO intention into coding some infrastructure things 
themselves. So - we can say such things as "do it yourself" in a 
community cooperative manner here, but let's not dare to present 
such opinions publicly ...

This is not a criticue, this is a raised eyebrow ... I think that 
we are on very good route - Extensions + Host ... and we will surely 
get there.

I guess there needs to be a formal limit to what RT does and what 
community should do. It can't be expected that RT would maintain 
console support on an obscure OS. OTOH you might expect HTTP to work 
as a result of RT work or someone close to RT.

Henrik - and I say I don't care how it happens. The only important 
thing is - the product and its state. If you have no answer for "who 
does it", RT is still responsible, if they want to market REBOL. 
That is why I thought bounties might help to sponsor some ppl willing 
to bring-in some usefull contributions ...

Now soon, GUI work will continue and there are graphics subsystem, 
OpenGL, etc. Enough work for 4-5 people there alone.

And one maintainer per OS platform.

It is of limited availability. If we want the tool used for R2 or 
R3 source, it needs to be publically available, and that means DevBase, 
or failing that, some web site. In either case it needs the right 
licensing, but with Gabriele writing it that is unlikely to be an 
issue.

Too low level I think and messy

maybe supply a block .. where the first is the one you want used 
on success, and the other is an error handler

but each scheme will have its own  callbacks.  some schemes might 
support headers, others not... for example, in my http rss reader, 
I had a callback for the file size.  if it was too large, I'd refuse 
the rest of the read and close the port...

read is going to have to get smarter and read the refinements in 
the 'read defined in the action block

There might be a /with option for READ, which supports additional 
options in an options block, but there won't be any other options 
outside of that block. READ is a low-level function, and won't have 
more refinements.

Brian: ok... let's make it easy... i just copied it here: http://www.rebol.it/giesse/wetan-test.r
and http://www.rebol.it/giesse/wetan-template.html- they just need 
to be in the same dir.

bsd is fine for the license, or mit, one day i'll release it properly 
and attach a license. :P

I've been reading some more of the docs .. and it says that the lookup 
phase in the awake handler is called when the name is resolved with 
a dns lookup .. but that phase is not used when the url uses an ip 
address.  But then I see some demo code using IP addresses ( the 
ping pong server ) where the open port is in the lookup event ...

and this then opens it

lookup [open event/port]

It's clearly explain in the link you pointed.

Note B

OPEN is called twice. It is moded. The mode is determined by the 
existence of the IP address. If the IP address is not known, the 
LOOKUP happens, otherwise the CONNECT happens. This also means that 
if you do an OPEN of a port where you provide the IP address, no 
lookup is done; you skip directly to CONNECT. If it is necessary 
to determine if the IP address is known (a rare situation), use QUERY 
-- which can be called at any time and is very fast.

so, I think it is what I said .. the lookup event always happens 
.. and it is triggered by the obtaining of the ip address.  It is 
the lookup itself that need not occur.

and that happens in the tcp device

ie. where is the smtp mail server information stored and where is 
the email stored?

Ok, this is pretty buggy and doesn't seem to send a well formed email 
... not sure why

http://rebol.wik.is/Rebol3/Schemes/Smtp

Anyway I've posted it for discussion, and to allow the rebol optimizer 
have a look ....

Not me ... I'm using my ISPs and I don't know my password!

I mean I open the port and do a read .. and off goes my email

ok, and the script error is in the auth response parsing

never tested ... I guess you need to find the to address and switch 
states ... etc

should work for the get-s, though. but anyway, you only read state 
one time in the switch, and another time in the default handler

Downloaded and installed community version of communigate pro .. 
mail/pop/everything server ....

How should the pop scheme work?  Open the port, and then send commands 
to it?

don't worry to much if it doesn't work, though. the design is stupid, 
and i'm reworking that at the moment :)

could you try and replace `wait either system/version/4 = 4 [1] [subport]` 
by just `wait 1`

and the first item must be solely the command

and you'll get whatever the command handler deems to be the right 
result to pass along

I see the top 10 lines and a "."

and an async mode, of course :)

you send the command to the port and retrieve either a multi or single 
line response

If you're retrieving a 20mb file via email, you really want to send 
each part back to the client as you get it and not just store it 
in locals as the original r2 pop scheme does.

where does all this tcp syn syn+ack and ack occur ?  Is it automatically 
done in the tcp device?

Can login ... and switch to passive mode ...

And wonder why I need to issue multiple reads to get all the data 
....

graham, afaic open? should work as it is. as the actor functions 
are contained within a block, the bounding is left to make-scheme. 
and make-scheme leaves the inner open? bound to the system version

and i even tested it with a win32 rebol3 :)

and one of the things i observed is that the tcp port does not seem 
to get re-scheduled after a write

and if you want for the awake handler to be called again, you need 
to be sure to read event/port

except for 'lookup and 'close events, of course

and i don't think that the 32,000 bytes given in this document are 
realistic

I see that the buffer is shared for both reading and writing

A few issues a couple of years old http://www.rebol.net/wiki/Ports_and_Schemes:_Issues#Issue_4:_WAIT

Just looking at what R2 does .. .each time it does a file/directory 
transfer, it opens the data connection, sends the command and then 
closes it again.

Hmm. I did a LIST and only got 4000 characters back.  I tried it 
again, but delayed the read a bit longer and got the full 8000 characters 
or so.  So, wonder why the data arrriving is not triggering the read 
event

maybe I need to read the number of bytes from the buffer, clear that 
number and try reading again until none

This isn't going to work unless I queue the user commands and process 
them once a command has completed.

It works on my server, but I tried it on one of the linux distro 
sites and there it doesn't.... as my write commands are written to 
the port before the previous commands have completed.

And the state machine becomes very confused ..

my bad...was waiting to get real binary numbers so the code shrinks 
to half the size...100% rebol code, too.  Also, I have to figure 
how to hook into the R3 codec infrastructure...and still trying to 
remember my password for R3 chat.

rebol []
make-scheme [
	name: 'dns2
	title: "DNS Protocol"
	spec: make system/standard/port-spec-net [port-id: 80]


	awake: funct [event ] [
		print ["=== Client event:" event/type]
		client: event/port
		switch event/type [
			lookup [
				; print "DNS lookup"
				probe query client
				return true
			]
			connect []
		]
	]
	actor: [
		open: func [
			port [port!]
			/local conn
		] [
			if port/state [return port]
			if none? port/spec/host [http-error "Missing host address"]
			; set the port state
			port/state: context [
				state:
				connection:
				error: none
				awake: none ;:port/awake
				close?: no
			]
			; create the tcp port and set it to port/state/connection
			port/state/connection: conn: make port! [
				scheme: 'tcp
				host: port/spec/host
				port-id: port/spec/port-id
				ref: rejoin [tcp:// host ":" port-id]
			]
			conn/awake: :awake
			open conn
			print "port opened ..."
			; return the newly created and open port
			wait conn
			conn
		]
	]
]

open dns2://www.rebol.com

Yeah .. just did a packet trace and it's all UDP

and does it append to port/data ?

# Setup the IO-request data and length fields. Data is the buffer 
tail position. Length is the buffer space available from above. Clear 
the actual field.

so with a write port ... the buffer is filled with my write data, 
it gets sent, and then cleared by the tcp device

if you use the same buffer (ie port/data) for read and write, you 
may encounter some problems

i will not use the same buffer for read and write

The details of the port actor for WRITE are:


   1. Set port/data to WRITE content (binary string) value. (Mainly 
   to keep it GC safe.)

   2. Obtain binary string as specified. The buffer is not copied. This 
   is a low level mechanism.
   3. Determine start position from index.

   4. Determine length from tail-index or from /part if specified.

   5. Set IO-request length and data. Zero the actual field (the length 
   actually transferred).
   6. Call the TCP device with the IO-request
   7. Check for errors

   8. Check for immediate completion. If done, set port/data to NONE.

Check IO-Request connection flag. This is not a socket check, it 
is a request state flag check.
Check the port/data for an existing buffer.

If no buffer found, allocate one that is of the default size (32,000). 
Note: not 32K.
Compute buffer space available.

If available space is less than half the default size, extend the 
buffer.
Recompute buffer space available.

Setup the IO-request data and length fields. Data is the buffer tail 
position. Length is the buffer space available from above. Clear 
the actual field.
Call the TCP device with READ command.
Check result for error. If error, throw it.

I guess Carl has his reasons on doing it this way instead of having 
separate buffers for read and write

i tried sending with WAKE-UP from the tcp port to the scheme port, 
and the scheme port's AWAKE handler even got called

and then store port/data away in the close event

and it's good to know that data is appended

and the buffer keeps expanding too