World: r3wp

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)

This is why I originally objected, and started all this discussion 
... conversion is left padded (your binary value to the right), whereas 
OR/AND are right padded (value applied from the left)

but, if the TO-INTEGER function obtains a 32-bit binary, it is not 
reasonable to expect it is not 32-bit

This is what guys tried to tell me - it is not probably being a 32 
bit binary ... it is just 32 bits, placed somewhere along the way 
in 64 bit slot, or in the binary stream :-)

Ladislav, ah, yes, you are right..then I think that your propsal 
is reasonable.

with such explanation, your 32 bit binary is just first 32 bits of 
64 binary, and then the result might be regarded being OK,no? :-)

but - the way Cyphre wrote his example above, it might be understandable 
... simply put, if you want full slot, you have to padd it from the 
left ... or it is just 32 bit value, and hence should yield -1

I think now I finally understand, what you mean :-)

first 32 bits of 64-bit binary

 is nonsense (you cannot convert "first 32 bits of 64-bit binary" 
 to integer in any reasonable way)

you can - you just take first 32 bits, regard it being a 32bit binary, 
but you still pretend it comes from 64 bit slot ... and convert it 
:-) (just a joke :-)

the only thing you can do is to convert "last 32 bits of 64-bit binary"

(that is actually the description of what is going on currently in 
the TO-INTEGER function)

... and according to that description, current result is OK ... no?