World: r3wp

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 ...

ah, yes, that might be the way too. Such scheme could be then added 
to default distro, if found usefull

I haven't touched r3 or schemes since I finished the imap:// so I've 
forgotten everything now

just not probably stcp - evokes "secure" .... that would rise too 
much of expectations ... whereas we have no SSL in R3 :-(

But I think it should be easy enough

I thought you might say that ...

but encryption occurs at a higher level than tcp

I know guys will not like it, but now I have "safe" way to OR/AND 
binaries the way I want :-) ... just not sure the way I find out 
the integer size is a good method ...

pad-bin: funct [bin [binary!]][
   bit-base: 8 * length? to-binary -1
   switch bit-base [
     64 [return join #{000000000000} bin]
   ]
]
  
>> (to-binary 1022) or pad-bin #{8000}
== #{00000000000083FE}

It *may be* what you want, but... What is the #{8000} binary? If 
it is a 16-bit signed integer, then it should be interpreted as -32768, 
not as 32768.

Ladislav - it came from Python's 0x8000 ... which is, if I understand 
guys correctly, not binary, but some kind of "binary literal integer" 
way of representation, which we don't have in REBOL. But, I know, 
that what Python mens, is 32678 ... and so that it fits my case :-)

I think, that they confused you. It is not related to the Rebol binary 
datatype in any sense, it is just an alternative (hexadecimal) representation 
of integer. It is equivalent to date values in Rebol, where we can 
use alternative representations of values, e.g. 01-01-2010 , or 1/1/2010, 
or 1/Jan/2010.

Yes, I know. And I tried to help myself with binary. Suggestion to 
use integers, and shifting, might be accurate, but I am not here 
to crash my brain with operations I can't easily understand. So I 
try to find a convenient way. And what is convenient for me? To look 
into sources and to see, what is happening:

>> a: to-binary 1022
== #{00000000000003FE}

>> b: pad-bin #{8000}
== #{0000000000008000}

>> a or b
== #{00000000000083FE}


... you see? I could imediatelly check, that OR was correct. And 
if I would be mistaken, or needed to perform shift, I can even use 
bitmap form, to see, what is happening:

>> 2#{0000001111111110}
== #{03FE}


So - no, I will not use integers. And I don't have to, if my model 
fits what I am doing right now ... I still think that it can't fail 
me, and all those "you can't know what #{8000} means" are just theory 
for me right now :-)

... and then - instead of Python equivalent code with 3 lines of 
shifting, I can just perform:

append result to-char my-binary/7
append result to-char my-binary/8

... or so I think ...

... the REBOL way, not just translated Python code ...

Is there any resolution to this topic? (Console) ... when playing 
with R3, I can't stand that ugly Windows "console" more and more 
:-) We can't even have multiline cut & paste :-(

http://www.rebol.net/r3blogs/0282.html


I don't remember the outcome - will we put R2 console back to Windows 
distro? Or wait for our own GUI based one?

>> ; R2 code converting integer -1 to 32-bit binary
>> debase/base to-hex -1 16
== #{FFFFFFFF}
; R3 code converting the said binary to integer
>> to integer! #{FFFFFFFF}
== 4294967295


As far as I am concerned, it looks incompatible to me, and I would 
prefer -1 to be the result of the conversion in R3

R3:

>> to-hex -1
== #FFFFFFFFFFFFFFFF

>> to-integer #{FFFFFFFFFFFFFFFF}
== -1

how is that related?

btw - issue! is no more convertible to binary in R3. Is it because 
issue! is a string type, whereas binary! kind of divorces with string 
type? :-)

How is that related? I don't know. Most probably I don't understand 
the problem you are trying to describe. Why should to-integer! #{FFFFFFFF} 
of said value be wrong?

you would expect it to be -1 probably, right?

I suppose, that I already wrote it abov e

hmm, but it is 4 byte value in 8 byte (64bit) environment, no? Why 
should it roll to -1? Well, I think it will be better for me to let 
the topic to those who understand it, and watch the outcome :-)

Right, it is a 32-bit binary value being converted to a signed integer.

Ladislav, so you think it should work this way in R3?

>> to-integer #{00000000FFFFFFFF}
== 4294967295

>> to-integer #{FFFFFFFF}
== -1

yes

(at least to me it makes sense)

But, surely, it would mean, that e.g. to-integer #{FF} should yield 
-1 too

As well as to-integer #{FFFF}, etc.

And I am standing on the other side of the barricade ... preferring 
to regard this thing being always right padded, in regards to full 
64bit slot :-)

ok, but then we would need a way you convert -1 to 8/16/32/64 binary 
too right?

I mean - left padded ...

Cyphre: Not necessarily.

(the 64-bit result is OK)