World: r3wp

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?

Yes, the current result is OK, if you pretend, that you did not obtain 
a 32-bit binary. But, I am not schizophrenic enough to be able to 
pretend I did not obtain 32-bit binary, when I did.

I think I will be OK with either solution .... (as I can fully see 
the consequences), I just need it being documented on some examples 
.....

I can = I can't

if OR and AND work "from left" ... then your proposal of #{FFFFFFFF} 
being -1 is logical too .... but guys might not like it, because 
in such a case, you can't easily convert to integer, unless you pad 
... and  we have no fast way to pad binaries currently ...

what do you mean by no fast way to pad binaries ?

I mean - #{FFFFFFFF} being treated as #{00000000FFFFFFFF} for OR 
and AND operations ....

i don't understand why you don't chose the opposite way (dealing 
with integers) it's simpler and faster

well, why not scrap binary altogether, no? What is binary for, if 
I should use integers? All docs describing some interface, mostly 
talk hexa. I know that hexa is not binary, but I want to see, what 
is happening with my bytes. Something like  4294967295 is telling 
me nothing. And putting binary/hexa helpers in comments is strange 
way of doing things. I want to see bytes, and bits ....

I can understand, that if you are really experienced, you might prefer 
integers, and shifting, etc.

hum ok, you want pad-bin as fast as possible...

R3 ?

yes, R3 .... I posted one func, did you see it?

yup

well, it's crap :-) The computation of existing int-size each time 
is not probably necessary. Maybe if we have it as a constant somewhere 
in system structure, it might be faster ... it is just for my testing 
purposes, not really a show stopper. I might in the end use integers 
as well, it is just that I was never good in binary handling, and 
it helps me to see, what is happening with bytes and bits ...

pekr, you can easily build an extension which handles your specific 
binarie wishes and it will be VERY fast.

I am not saying I can't .... I can as well start with mezzanines 
... good enough for my testing purposes, or even for target purpose 
= send few bytes of control commands to router :-)

>> pad-bin: func [bin][to-binary to-integer bin]
>> pad-bin #{8000}
== #{0000000000008000}

That's all ?

haha, clever :-) today I just tried with to-binary bin, I thought 
it will re-convert it :-) But this to-integer trick did it :-)

maybe no reason create a function for it, just state it in comments:

to-binary to-integer #{8000} ;--- make it 64 bit

Usually I make shortcuts for to-binary and to-integer in my scripts 
(which have insanly long names in the rebol world)
I used to use: toi, tob, or int and bin

bin int #{8000}

Sounds good. But it is still better to do the conversions to the 
most efficient method ahead of time if you can. REBOL is hand-optimized.

As far I can remember our community is not very good with graphic 
designs, but hey we are coder !

wrong thread...

Brian - I seem to recall that the JVM as a target paltform for REBOL 
was discounted (because of performance and not having tail-call optimization, 
I think) - have you any opinion on targetting the Microsoft DLR? 
This would be a good way to get traction by being able to run in 
browsers (not just IE) without a REBOL plugin (well, assuming that 
Silverlight was already installed).

Some browser samples in Ruby and Python:

http://www.visitmix.com/labs/gestalt/samples/

This page walks thrugh running Ruby in the browser:


http://www.rubyinside.com/ironruby-silverlight-ruby-in-browser-3192.html

I have been giving the subject some thought, and even more so since 
Silverlight came out. It would be the best way to get REBOL into 
Windows Phone 7, for instance. I don't see how the tail-call thing 
would affect REBOL on Java though: REBOL doesn't do tail-call optimization 
anyways. But we might want to wait for Java 7 and its dynamic types 
(Java's cheap knock-off of the DLR).

R3 question?  http://synapse-ehr.com/forums/showthread.php?53-Error-Illegal-entry-in-bfchar-block-in-ToUnicode-CMap

No, it's not an R3 question, those functions don't exist in R3.

Must be some library he is using

trying to do scheme above tcp to aid with async protos

but each time i stick my nose in R3's network stuffs, I encounter 
limits which annoys me

what limits, for e.g.?

First, we can't add our own parameters to actors or change their 
type

e.g

I wanted to user the refinement read/part to allow custom breaking 
rules

>> read/part port 100  ; to read only 100 bytes
Fine it wors