AltME groups: search

You were assuming padding, when there is no way to pad those operations 
without breaking someone's assumptions. If you are doing binary conversions 
and working with binary values you are assumed to know what you're 
doing.

No, OR/AND should be applied from the right side, not from the left 
side ....

pekr,  there are things in Computer science which just are.   Just 
like there are things in maths, which just have to be accepted. 


R3 isn't inventing much of anything here, its actually much closer 
to normal boolean algebra than R2 ever was... FINALLY.   


in binary algebra, normally, things are right padded when sizes don't 
match... that's just how the maths behind it where defined long ago.


binary manipulation is an advanced topic, and you can't assume anything.

Simply put, you are assuming that TO-BINARY and TO-INTEGER are reversable 
when you don't provide the whole binary equivalent of the integer. 
There is no reason that this would be true.

There's no reason that the operation *would* be reversible. The TO-INTEGER 
was correcting for an incomplete binary in a DWIM way. If you had 
provided the whole binary it wouldn't have had to do that. And the 
TO-BINARY had a whole integer, so it didn't have to correct.

What if I will have 32 or 128 variant of REBOL? Will I have to adjust 
my expressions, hence change my code? There is no reason to not perform 
OR/AND on the lowest byte, not the highest byte imo ...

And I was wrong, the Python in your example was not operating on 
binaries at all, it was operating on integers that were specified 
in hex syntax, which is a completely different thing that REBOL has 
no support for at all. Not the same thing.

binary streams and binary arithmetics are different issue to me ...

0x8000 and #{8000} are completely different concepts.

pekr... here I must say, you really do not know what you are talking 
about.


all the binary changes brought to R3 are due to user responses about 
how fucked up it really was to use binary stuff in R2.   really. 
 I had to build binary data-driven TCP servers in R2, for example, 
and I had to use so many shitty work-arounds and fix up numbers .. 
it was an ordeal.


R3 makes binaries, clean, no hassle and simple.  they are a simple 
series of bytes, nothing more.


they are manipulated from the start to the end in that order.  that's 
all there is to it.

and 0x8000 will be a different value based on what variable type 
it is assigned to.

0x8000 can be:

 #{8000}, #{00008000}, or  #{0000000000008000}

you can't tell .

Max - please stop this fanboyism. I know why R3 was brought to us, 
and I know how fucked up R2 binary was. I am glad we are converting 
to binary as one value, not as separate values, like in R2, that 
was not usefull. But my above case will make headache to many ppl, 
I can bet ...

and 0x8000 will be a different value based on what variable type 
it is assigned to.
 ... do you REALLY mean it? 0x8000 is just one value, period ...

... and you are talking about CERTAIN binary value as of stream of 
unknown position, hence not having value at all :-)

pekr you seem to miss that a value and a litteral are two different 
things.

Max - append and join are broken - it is CCed ...

BrianH: now I will get you ... what value should to-integer #{8000} 
return? It now returns 32768!!! And according to your theory, it 
should be equal to padded value, hence to-integer #{8000000000000000}, 
because you just said, that I can't expect #{8000} to be the lowest 
bytes ...

OK, going to sleep. Will wait for eventaully others to express their 
opinion. I understand your points, and will adjust accordingly, it 
is just that it imo sucks for the usage case I needed. For me integer 
to-binary and reverse operations are not safe to combine. That might 
confuse some ppl, and will need good Docing ....

Hmm, actually I still think that not considering #{8000} a concrete 
(32768) value is a bug and totally wrong assumption. It IS a concrete 
value, period. It is just that R3 allows me to enter it without the 
padded higher bytes. And hence - the concrete value should be computed 
internally accordingly. Easy as that ....

Pekr, you do realize that TO-INTEGER #{8000} is a conversion of an 
incomplete binary, an operation, right? And that 0x8000 is syntax 
for an integer value? REBOL doesn't have hex syntax for integers, 
or any default interpretation of binary values as being of a different 
datatype. Just like Python doesn't have syntax for binary values 
(unless I'm mistaken about that last bit).

All of the TO whatever binary! conversions also allow the binary 
to be longer than the target value, ignoring the rest of the data. 
This comes from the assumption that the binary is a stream that you 
are converting and the rest of the stream is other values that you 
will be converting later. If the value is too short then it is assumed 
that you did a COPY/part on the stream for alignment and padding 
purposes, so it will be nice to you, but direct operations on binaries 
are assumed to have comparable lengths. And there are no implicit 
conversions to or from binaries, as a rule. The behavior is very 
consistent.

And in Python 2, a (non-unicode-) string is nothing but an array 
of bytes.

Pekr, I agree with BrianH (as I almost always do).

It seems the confusion is that C or Python's integer representation 
syntax and Rebol's binary datatype look similar, because they both 
use hexadecimal. But 0x8000 in C or Python is really an integer and 
has to fit inside an integer type with some specific size. Rebol's 
binary type is a series type and can be as long or short as you want 
(well, measured in 8-bit chunks, octets), and it doesn't make any 
assumptions as to what the meaning of those octets is.

In Rebol I miss being able to represent integers the way C does, 
it makes translation a bit more difficult.

And just to add my two cents: I find the current R3 behavior to be 
easily understandable and totally sane.

And I don't think those literals are missed, in REBOL.

And the only important thing for correctly using binaries, is not 
to mistake a binary for some other type just because it could validly 
represent this other type. #{0001} is neither 1, nor true, nor $1, 
nor #1, nor ...

You still talk about the syntactic sugar, but that is imo irrelevant. 
If we have so cool and open dtype, which can represent "anything", 
then allowing integer to binary and vice-versa conversion, should 
be prohibited! How is that we decided, that to-integer #{8000} is 
actually 32768? That is absolutly concrete value, it does not allow 
any other interpretation, no? So how is that, when ORring with such 
a value, such expectation does not stand anymore?

I still think, that OR/AND applied from the right side would not 
hurt anyone. It would just work correctly imo. Max's explanation, 
that binary is just a stream does not imo stand any valid argument 
here, because - when you already decide to apply AND/OR, you decide 
at certain time, with certain known binary value,no matter wher in 
the stream you are ...

So once again ... the following result is imo insane, and I wish 
a luck anyone trying to explain it in the docs :-)

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

>> l or #{8000}
== #{80000000000003FE}

Using language like "insane" to describe the above is hyperbole. 
I don't respect that; it's an overreaction. Why not say instead, 
"the following result is still confusing to me". (I'm having the 
same problem with my parents and with myself, we are using too much 
extreme inaccurate language, and it's causing emotional stress between 
us.)

And Pekr is using binaries, because they happen to sort of fit into 
binary operations in some cases, which makes them look incomplete.

How about a base! datatype, which would be a number! ?

#(10000000)2 == 127


Quick and probably bad example. An issue would be how to convert 
between different bases.

Anton - insane is just that ... insane :-) It is just word. I did 
not say Carl, BrianH or anyone else is insane, having some arguments. 
REBOL is not religion, as Brian says ... it is a tool. And I want 
the tool to work correct way, if possible. So - stop being stressed 
about someone claiming something is insane :-) 


The question to all above is - what is the correct behaviour. The 
qeustion even is - what is correct about correctness? I know from 
the past, that Carl really cares about simple things being simple. 
I can't remember the case, but I do remember I pointed out something 
will confuse ppl, and I was right - we could see the same kind of 
questions by novice again, and again, and again.


I think that if you claim, that to-integer #{8000} allow many interpretations, 
how is that we have choosen the concrete one? (32768) Because it 
is what we would expect. You might think that I don't understand 
what BrianH or Max or You talk about. Whereas only Ladislav got the 
correct answer for me - if it would hurt to have reverse padded OR 
operation.

BrianH: I know :-) It is just that for the simple purpose of OR, 
you have to do all those conversions and tests for the integer size. 
Then original "shortcut" format of #{8000} be better avoided in the 
code.

When I am adapring code from languages with C-like integer syntax 
I resolve the constants to regular integers ahead of time and then 
put the original syntax in comments. Works great, no conversion overhead 
at runtime. You should try it.

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.

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)?

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

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.

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 :)

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

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

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

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

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 :-)

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}

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 :-)

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

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

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 :-)

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 :-)

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)

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

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 :-)

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

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

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.

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.

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

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

but then i wanted to allow any type of breaking rule, like
>> read/part port crlf ; to break into lines
And event more powerfull:
>> read/part  port [thru #"^@]
To allow any parsing rule as breaking point

but then i wanted to allow any type of breaking rule, like
>> read/part port crlf ; to break into lines
And event more powerfull:
>> read/part  port [thru #"^@]
To allow any parsing rule as breaking point

but then i wanted to allow any type of breaking rule, like
>> read/part port crlf ; to break into lines
And event more powerfull:
>> read/part  port [thru #"^@]
To allow any parsing rule as breaking point

well, read/write became low-level, and Carl still did not decide, 
how to replace missing R2's functionality ....

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.

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

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

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?

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

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

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

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.

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

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.

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.

Yes, plus it took a lot of space (it adds up). Plus the objects that 
didn't have that field behaved badly - such objects were created 
to serve as function contexts, or by functions like USE and FOREACH. 
Since all of the code that worked on objects had to skip past the 
first field ('self), if the first field wasn't 'self it was still 
skipped. Plus the 'self field was writeable, which made code injection 
attacks possible when running untrusted code - not really a concern 
for R2 with its known insecurity in such situations, but for R3 it's 
a design criterium to be able to sandbox code. It is really better 
to not have the field at all, and just make it a keyword in certain 
limited circumstances (imo).

This wasn't really much of a problem for experienced R2 developers 
because they learned the workarounds and checks necessary to add 
to their code to make it work. Or in the case of things that work 
badly or not at all, they got used to not doing those activities, 
no matter how useful they would be. It was a "good enough is good 
enough" situation, with noone asking whether it really was good enough 
until the R3 project started.

I don't undersand all the fuss about the 'self :-) Is your and Ladislav's 
point of view really so different here? :-)

... and also - does Carl's new doc provide you with some explanation, 
how actually 'self is handled in various situations?

wow that 'self topic has become pretty intense.  just one question 
left...  

what color gloves (boxing) are  Brian and Ladislav wearing?   ;-)

Hey, I did my best to express his point in a timely manner in a way 
that would be understood, same as with the opposing points. There 
was a lot of discussion that had to be gotten across quickly to Carl, 
so that he could make a final ruling. And it looks like a refined 
version of Ladislav's proposal was chosen. So we did a good job :)

The 'self test doesn't seem to be working as expected so far, at 
least for closures and loops. Weird.

Ladislav, for comparison I added the tests from the blog to #1543, 
#1544 and #1549. Take a look and tell s what you think. English is 
overrated - clearly, we should be expressing our arguments in REBOL 
:)

I added your philosophical point tests to the example code of the 
#1549 ticket, and the practical tests to a comment. Please check 
both.

And test them against the build linked above, to see whether they 
match. There doesn't seem to be a SELFLESS? function yet, so the 
downsides of the proposal haven't been resolved yet by the posted 
build.