AltME groups: search

And you can't override a field unless it's hidden.

Ok, so let me try to recap this huge discussion. In R2 we had context! 
and object! as two separate types, although context! was hidden from 
users and only accessible by converting it to object! - conversion 
which was broken because it did not create 'self that object! requires. 
So, instead of fixing this by making context! accessible, it was 
decided to remove context! altogether and add 'self to all contexts, 
and add a bunch of exception refinements to BIND to work around all 
the problems that come out of that?

Nope. You missed a bit of the R3 part. But that is a good characterisation 
of how bad things got for R2.

The part you missed for R3 was that there were no exception refinements 
added to BIND to deal with this at all - they weren't needed. And 
we are proposing to add *one* refinement to BIND, out of a choice 
of two.

The R3 version is a lot faster because of the native loops :)

Brian, I don't agree that a half-keyword SELF is the simplest way 
to solve the problem.

Finally, the only reason we still need 'self is because you can't 
use path notation with the results of a function (BIND? in this case). 
So you have to have the result assigned to a word to be easily able 
to do the tricks one can do with path notation. Thus the only reason 
we need 'self is for convenience, so that the end developer doesn't 
have to constantly reinvent their own 'self references, badly.

When I say "badly", we come to the only thing you can't do with a 
roll-your-own 'self: The UNPROTECT exception. UNPROTECT won't unprotect 
'self: it refuses to. And it will unprotect any other protected word 
(future security restrictions allowing). So the one thing you can't 
fake is a persistent word reference to the object that you can't 
modify (the way you can in R2). At least not without writing your 
own UNPROTECT.

irreparable bugs

 isn't descriptive enough. Please add a comment explaining what the 
 bugs in question are, and why you think they are "irreparable", when 
 you link tickets that have known methods that can be used to solve 
 them, including one that is already fixed. And why DO-IN, a function 
 that only exists in the example code of the ticket, not in R3, matters. 
 If you don't do this *in the ticket or its comments* then the ticket 
 will need to be dismissed.

After Beijing Olympics, China government blocks more and more web 
sites. Google Blogspot is one of them. Since most of Chinese people 
cannot visit my REBOL blog on Blogspot, so I decided to create a 
new REBOL blog in Sina.com.cn, which is China-local. The new blog 
will be dedicated to (1) People in China (2) Programming Beginners 
(3) Students in High-schools. It's been created for 4 days. 8 Lessons 
have been published. Check it out here http://blog.sina.com.cn/yingerpeifang
 BTW, "YingErPeiFang" means "Baby Formula".

How about a while-either function

If a block evaluates to anything other than that then it is true.

Graham, it's been a long journey.

Carl, how is the next host/extension (with view as a plugin) comming 
along?

and a lot of spam cleared from the blog

... so the only info we have got after a month or more of total lack 
of any info, is, that "it's been a long journey"? Great. This really 
starts to look rudiculous ....

This has been the pattern with Rebol development in the few years 
that I have been Rebolling. Whether it looks ridicuous or not is 
a matter of personal opinion, but surely it is to be expected?

OT, what about a 64 bit R2?

Android (more recently) has a way for you to write native code plugins, 
to supplement the Java code that apps are written in. It seems to 
me that this would be a good way to get R3 integrated.

Using my R3 fax script, I was able to login to a hylafax server in 
Washington from here in NZ, and send a fax across town!

that is cool... something Carl has been musing about for a long time.

I could google and poke around, but I'd rather Ask a Friendly Human. 
 Where are we at with GUI and GNU/Linux?  I get a crash;
** Script error: size-text has no value

** Where: font-char-size? make make-text-style parse fontize do do 
either load-gui
** Near: font-char-size? self

Is if worth digging in for?  Fonts?  etc.  Or, is it a don't bother 
yet?

Are TO and MAKE considered the same in R3? (same? doesn't return 
true, but the two functions seem to work the same, or maybe there 
is a differenct?)

are following operations correct?

b: to-ginary 1022
== #{00000000000003FE}

b/7
== 3

b/8
== 254

Why does it return integers, and not a binary?

binary is a string of  bytes, so that it returns 8 bit integers to 
me is VERY usefull.

what you say is equal to:

a: [1 2 3 4 5 6]
a/3
== [3]

binary is a series, and indexes return, like all other series, the 
element which constitutes it at the index you give it.

Yes, but that 64 bits is a known, consistent quantity. Very predicatble.

No, binaries are right-padded. You should have been ORing with a 
binary of the proper sixe. R3 was nice enough to add the 0s that 
you didn't provide. It's just your assmption that was off :(

I was orring original converted 1022 with 32768 and got a crap ...

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.

pekr,  to-integer is a helper func.  its like form, not mold.

you shouldn't be using to-integer.. for binary arithmetic.

rebol is reversible:
>> b: to integer! a
== 32000

>> b: to binary! a
== #{0000000000007D00}

>> a: to integer! b
== 32000

Pekr, binary operations are assuming that the binary is part of a 
stream. The "lowest" byte could be megabytes away.

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.

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.

0x8000 is an integer specified in a different syntax, one which REBOL 
has no equivalent to but C does.

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 .

pekr... have you been reading... #{8000} is NOT A NUMBER its a SERIES 
OF BYTES.


you keep refereing to binaries as if they where numbers.  THEY ARE 
NOT

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

to-binary 1022  creates a string  16 bytes (64 bits).

no, it creates a  binary :-)

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

I meant a value stored in ram.

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

Maxim, you're wrong on this one. 0x8000 is always an integer. It 
has nothing to do with #{8000}.

10 represents the number, but it can be stored in a variety of ways.


0x800 represents the number, just in another notation.  like 10  
is written   110   in binary  or   A   in hex

Brian: Max meant the binary #{8000} is a different value ....

Right. A notation that REBOL doesn't support. So Pekr was trying 
to use #{8000} instead, not realizing that it referred to a different 
concept altogether (one which Python has no support for, ironically).

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

#{8000} could just as easily be an incomplete decimal or money, or 
a malformed character, as it could an incomplete integer.

#{8000} is a concrete value. It just isn't an integer.

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.

Out of curiosity, does Python have a literal syntax for an array 
of bytes? That would be the equivalent of binary!.

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.

So just to add what Brian already explained nicely above: #{8000} 
is syntax for a sequence of bytes. The equivalent in Python would 
be b'\x80\x00'. 32768 is syntax for an integer, same in Python. Additionally, 
Python has alternative syntax for the same integer: 0x8000, 0o10000, 
0b1000000000000000; for those literals, REBOL has no corresponding 
syntax.

As you can already glance from the above, we have a nicer literal 
way to specify sequences of bytes. This goes even further: we can 
write #{F0} as 2#{11110000}, for example.

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}

Wow, what a fuss :)

What prevents you to adjust the size of the binary to fit the chosen 
size ?

>>(skip to-binary 1022 6) or #{8000}
==#{8324}

Pekr, you are right when saying, that binary OR uses different padding 
(right) than conversion to integer (left).

As far as I am concerned, the left padding for conversion to integer 
looks more convenient than right padding, "producing" a useful result 
more often.

Regarding the OR operation: I guess, that it *could* use left padding 
too, but, in that case, I am not sure, whether left padding would 
produce a more useful result more often, than right padding. (although 
you provided one case, where left-padding *would* be more useful) 
Nevertheless, I do not think, that padding of these two operations 
has to be the same

From what I can tell above, we just need a way to represent numbers 
properly in any base.

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.

I would prefer less syntax, if possible, maybe something like 2_10000000
(Remember we have 2#{10000000}, but it's a binary! of course.)

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.

A PAD function would be useful.

We made a MOVE function to resolve such discussions, we can do the 
same with PAD.

Is there a reason, why 'shift (as opposed to R2), does not allow 
binary as an argument?

SHIFT in R3 is a lower-level, much faster function. No other particlar 
reason though.

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.

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

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

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

Yes, define a simple awake handler

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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.

Sounds like a good community project.