World: r3wp

Go ahead. It's not already there, afaik.

SHIFT in R3 is a pure function though, non-modifying. You might be 
better off with a different function for binaries.

The changes to SHIFT are a good model for how to make PAD simple: 
Builder function, positive to pad left, negative to pad right, padding 
value required,  maybe an /into option. Make it simple enough and 
it could be fast even as a mezzanine.

We might want to reverse that positive/negative thing though since 
SHIFTing left is really padding right with bits though.

Pekr: "if you want your code being cross platform, your code complicates" 
- certainly! In such cases, left-padding does not work reliably, 
in fact!

Hmm, because I can't do shift on binary, enbase/base is giving me 
following result (understandable, as to-binary creates 64 bit binary)

>> enbase/base to-binary shift to-integer (copy l) -8 2

== {0000000000000000000000000000000000000000000000000000000010000011}

whereas:
>> enbase/base 2#{11110000} and 2#{10110000} 2
== "10110000"


Correct too? So when using shift, I need to use different scenarios, 
if I want bits represenation (copy/part)?

Example:
>> to integer! #{FFFFFFFF}
== 4294967295

(while you migth want to obtain -1)

Preconversion is usually the best bet for this kind of thing.

Ladislav - interesting. So I better first check, what platform (integer-side 
wise) I am running on, and adjust accordingly? E.g.

>> 8 * length? to-binary -1
== 64

Yes, e.g. your #{8000} may in fact be interpreted as -32768

Yup. And remember that all of those TO-BINARY calls and binary constants 
have overhead, so you should precompute constants whenever you can. 
This makes yor code *much* faster.

(as it was in 8-bit CPUs)

16bit

We still use 8-bit CPUs, it is just I don't expect REBOL to run on 
them :-)

They were called 8-bit, AFAIK, but worked with 16-bit integers

That's the 8088 and its like. Real 8bit CPUs worked in bytes.

I worked on CPM and DOS 1, so I know the difference :)

I meant e.g. http://en.wikipedia.org/wiki/Intel_8080

(worked on in this case not meaning developing the OSes, but developing 
*on* the OSes)

The 8bit vs. 16bit thing as most understand it referred to address 
space, not integer size :)

The same was with Amiga and Motorola, just reverse, no? MC68000 was 
32bit CPU with 16bit bus, whereas adress space and registers were 
32bit?

Actually, I remember MC68000 being called 16-bit processor (which 
is analogical as for I8080, mentioning the bus size, not the address 
space, or the integer size)

Ah, the good old days :)

:-D

Anton, that might be a good syntax. A "shame" that x is already taken 
for pairs.

Henrik - I just wanted to say the same (re "x") ... I thought about 
"*", but not sure ...

I prefer to think that "shame" was put in quotes sarcastically :)

From R3 twitter:

The first R3 embedded extension function evaluated! I think many 
of you are going to like this capability.

A few days old but I did not see mention of it here.

Yeah, based on the proposals and the docs it looks like it will be 
really simple and powerful, great stuff.

awake: func [event][
    switch event/type [
        connect [return true]

        read [read event/port all [0 = last event/port/data return true]]
        lookup [open event/port]
        wrote [read event/port]
    ]
    false
]

p: open tcp://router-ip:8777 ;--- obfuscated, web public group
p/awake: :awake
wait [p 10] ;wait for connection

write p "^F/login^@"

wait [p 10] ;wait for data
print to-string p/data

close p

>> ?!done%=ret=5faf15d6f67b41e74644b85dfef81ca6


Thanks Steeve, good work ... although thouse synchronous wait [p 
10] are scary :-) I now have some noob questions:


1) I wonder, if we could have "more regular" way of handling timeouts? 
I mean - could there be a time event type, which could be put directly 
in the 'awake? Hmm, but that would be similar to face/rate probably, 
or would even require multitasking/threading, or would not be usefull 
at all :-)


2) Would it be possible to have at least minimal 'awake handler awailable 
for schemes like TCP? I know Carl told us, that having async networking 
comes with some price - it is not so easy to handle. But R2 simplicity 
of opening the port, inserting data, copying result, closing port, 
- is greatly missed ...

sure .. why not

create your own scheme, and put the waits in the scheme definitions 
for read or write etc

I don't want my own scheme, I want bere-bones TCP/UDP to have some 
handler by default :-)

(not talking about putting 'time inside the handler, that was just 
an idea)

Well, the http scheme has sync handler because Gab wrote one.

so your microtik scheme can do the same

tcp is low level async .. so not really sync

yes, I know. I don't care about Mikrotik right now, but about easy 
prototyping. With R2, I was able to start, just like with Telned 
- you open the port, insert some data, and watch things happening. 
Not so with R3. I would welcome, if even R3 TCP had some default 
awake handler, which could be later overriden, if needed ...

so you have to type one more line ...

the r3 port model makes things much easier to write schemes

one more line? Do you mean port/awake: :my-awake? But I first have 
to define 'my-awake, no? Just trying to understand the situation 
...

and users should be using schemes and not low level tcp

Graham - I know ... and I would not trade R3 port model for R2. I 
am just asking, if there might be some "shortcut", to "simulate" 
R2 way of doing things :-)

Yes, define a simple awake handler

OK, so there can't be any way :-)

ask Carl I guess

or create a new scheme called stcp:// for sync tcp

There is a lots of possible usage to raw TCP .... this is for those, 
who like to try stuff in console. They will stop right after opening 
the port .... OK, I will ask Carl ... because - If all is needed 
is for me to define at least simple TCP awake, then why is it not 
included by default then? Or we can have some handler storage, from 
which you could choose just one ...