World: r3wp

IMHO: after the host, I think the whole device model will be last 
thing to get itself fixed, finalized and done.  when that occurs, 
we'll have a beta.

http://www.rebol.net/r3blogs/0294.html
http://www.rebol.net/r3blogs/0127.html

Thank, I was about to look for those.

I've been waiting for READ/as and WRITE/as for a while now, to apply 
to the clipboard:// scheme.

what i got currently, is this:

p: open etcp://my-ip:my-port   ;immediate, does not connect

write p [verbose debug timeout 20]   ; pass a block of commands to 
change the config of the port

write p "echo toto"     ; the connection is established then data 
are sent
read p 		; one packet is waited and a binary is returned.
read/string p  ; one packet is waited and a string is returned

read/part p crlf    ; one or more packets are waited until the breaking 
rule is matched

read/write/as solve just encoding, no? Still not abstracted encoder/decoder 
solution anyway .... old discussion :-)

READ or WRITE /as just solves the encoding problem. Which for the 
clipboard:// scheme means chosing which one of several encodings 
is already strored in the clipboard, at least for most modern OSes.

ah, what? /string and /lines were added? Well, we can't keep to original 
ideas, probably ...

IIRC originally we had following specs: read file /part size /skip 
len

In such case, maybe it was better to still have read-io, write-io, 
and make read and write more higher level. What is the reason to 
first "prune down" function, and later on give-up, and add other 
refinements, because the practical merits push us to do so?

I like READ and WRITE being lower-level - it makes the semantic model 
of ports simpler. R2 tripped over that all the time.

That would not be a problem, if we were allowed to add our own parameters 
and refinement.

Because the meaninfulness of a refinement in write or read is depending 
of the scheme where it's used.
We can change the code but not the interface.

but why /lines and /string were added?

it does not make them low level anymore. those functions were about 
reading stream of bytes, not strings ...

because of some complaints with file operations

Because they were needed for the main uses of READ and WRITE: Text 
processing.

hahaha :-)

so you talk x hours to me, trying to explain, that R3 broke with 
R2 almost-everything-is-string attitude, to later on admit, that 
we gave up on strictly deviding, what 'read/write are supposed to 
do

Hey, we added support for Unicode text processing right into the 
language, even including two datatypes specificly for that purpose: 
string! and char!.

when was /lines added? I even did not notice it ... even the blog 
which was supposed to resolve it did not mention anything like that 
...

I thought we got 'split to simulate read/lines?

It's not an exception Pekr, there were changes made in the past without 
any commercials

Alpha 78.

I think this is all under-engineered - not finished in design. There 
was never any resolution posted to the topic. And the topic is deep. 
It reaches even continuous reading and parsing (streaming) and codecs 
...

Current codecs are totally unusable

Agreed.

I think that Carl will have to think about this single topic for 
quite some time, to get the design right ...

The truth is, that while I prefer things being conceptually correct/consistent, 
I also miss, if we miss on easiness of use of R2 (read/lines, simple 
tcp open/insert/copy/close sync mode)

probably we need a new FSM dialect, parse is not suited to do that 
job. We have to do too much hack to simulate a fast and clean state 
machine.

Sounds like a good community project.

wasn't DELECT meant to be that? Maybe not ...

btw - will DELECT have any use, when commands will replace it?

could use an FSM dialect. in fact we could use a library of various 
dialects.

You will need to have some way for a block of dialect to be passed 
to a command-based dialect processor. So some function to take the 
place of DELECT will be required, even though it won't be compatible 
with DELECT.

so DELECT will become mostly useless, correct?

No, fully replaced by something completely different. Which doesn't 
yet have a name, but might be called DELECT. The existing DELECT 
will be gone.

OK, thanks ...

sometimes you have to do stuff to think about even better stuff  
;-)

Steeve, Gabriele and I (and perhaps others) have written FSM dialects. 
I think it's a great idea.

First bugfixes appearing in CureCode  for A98 ....

Self reflection - http://www.rebol.net/r3blogs/0312.html

I wonder how the 'self discussion resolves. Brian - Carl just pointed, 
that the description to #1549 ticket is not clear to him .... there 
is also new Doc page to it - http://www.rebol.com/r3/docs/concepts/objects-self.html

I'm reading the page. So far it reflects the surface behavior of 
my proposal, but is less detailed so I can't say for sure.

it seems pretty straight forward to me.

I would like to more understand the 'self topic :-) (well, maybe 
I will never be able, but ...) .... what is the difference between:

- field
- flag (eventually)
- and - keyword?


Is that the field is a real variable (word), flag would require some 
internal storage, but is not an user level value/attribute of the 
context, and keyword is just something like flag known in runtime 
during execution? But 'self, being a keyword, has to be somewhere 
stored too, no? :-)

The word 'self, when a keyword, only has the storage for the word 
value itself; it doesn't have any associated value slot in the object. 
A field of an obhect has a value slot in the object. And a flag is 
internal, probably just one bit somewhere.

So a keyword only takes up as much space as an unbound word.

so the word 'self keeps pointer to context it is bound to?

Yeah, but it's a special binding, with just a reference to the context, 
not to a field. The object doesn't have a 'self field. The 'self 
keyword is currently just a side-effect of the BIND and IN functions, 
not something that is really in the object.

That's why the previous debate about this was so confused - that 
info wasn't known back then.