World: r3wp

Don't know if you can run native-only apps on Android - haven't heard 
of anyone doing that.

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!

The hylafax server is using Fax over IP ( comcast ) so I suspect 
that's why I was not able to fax back to me in NZ

Nice achievement in regards to R3 :-) Btw - it seems Carl is working 
on turning View into Extension - http://www.rebol.com/r3/docs/view/graphics-ext.html

Delayed Extensions - http://www.rebol.com/r3/notes/delayed-mods.html

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

It will be more than just extensions that will be able to be delayed, 
any modules will be delayable. I'll be discussing things in the !REBOL3 
Modules group here tomorrow if anyone has questions or suggestions 
about this stuff.

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?

from
>> load-gui
that is

we are not far ... yet ... R3 GUI should be pushed forward by Robert's 
team, but guys are mostly waiting for Carl to turn View into regular 
Extension, and releasing its sources, so that low-level View enhancements 
can be done. As for VID itself, we are still in kind of wait mode 
imo ...

Thanks Pekr; I'm at 1:30am, and just knowing will make for an easier 
sleep; no frets about missing the memo  ;)

Does anyone know if these are bugs in R3 or am I missing some new 
feature?

>> append #{} [#{01} #{02} #{03}]
** Script error: invalid argument: [#{01} #{02} #{03}]
** Where: append
** Near: append #{} [#{01} #{02} #{03}]

>> rejoin [#{01} #{02} #{03}]
** Script error: invalid argument: [#{02} #{03}]
** Where: append rejoin
** Near: append either series? first block [copy first block] [
    f...

>> join #{} [#{01} #{02} #{03}]
** Script error: invalid argument: [#{01} #{02} #{03}]
** Where: applier apply repend join
** Near: series reduce :value part length only dup count

Tested under 2.100.97.3.1 version.

sorry,nevermind....just found that here http://curecode.org/rebol3/ticket.rsp?id=1452&cursor=1

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

Asking for R3 critical fixes

sounds good...back on track

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

They are different:

>> to string! 42
== "42"
>> make string! 42
== ""

With MAKE, it's the length of the created string.

TO and MAKE are considered different in R3, but for some types they 
do the same thing; not string though.

are following operations correct?

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

b/7
== 3

b/8
== 254

Why does it return integers, and not a binary?

sorry - typo in above - should be to-binary, of course ...

also - is following operation what is expected?

>> lx: lx or #{8000}
== #{80000000000003FE}

>> to-integer lx
== -9223372036854774786

Whereas I would expect OR being performed on the lowest bytes!

>> #{8000} or #{03FE}
== #{83FE}

>> #{8000} or #{03FE}
== #{83FE}

just like strings return chars.

I find binary handling, along with inability to join binary resuls 
severyl broken

Max - this is imo wrong ... how is that usefull? I did not ask it 
return integer ... imo /index should still return original type

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.

OK, I can accept that ... but is R3 OR operation, performing OR on 
the higher bytes correct?

If you are concerned about alignment, manage it yourself. The behavior 
is extremely consistent, so that such management is easy.

Brian:  how is that supposed to be easy? The way it is, I have to 
count on the internal representation binary size - here 64 bits ...

I am asking binary 1024 to be ORred with binary #{8000}, the result 
is imo crap :-)

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

but the result is imo wrong anyway, no?

This is correct:

>> (to-binary 1022) or (to-binary 32768)
== #{00000000000083FE}

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

sixe -> size

no, it is not ...

>> to-integer #{8000}
== 32768

What assumption are you talking about? If you were right, then above 
binary should be paddedd too ...

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

If I should care about internal representation of binary, then it 
is not usable datatype for me. How are my operations supposed to 
be fast?

TO-INTEGER and TO-BINARY integer left-pad. OR and AND don't pad at 
all (in theory), they just make up for your error in not providing 
the whole binary. It is like blocks and none.

can't you see that? Following iperations are imo compatible, and 
should provide me with identical results ...

>> (to-binary 1022) or (to-binary 3278)
== #{0000000000000FFE}

>> (to-binary 1022) or #{8000}
== #{80000000000003FE}

>> to-integer #{8000}
== 32768

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.

simply put, in second case, 1022 is not orred with 32768

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.

non reversable operations are evil ... can't remember the case, but 
we already had such discussion in regards to some R2 area ....

Once again - you are imo wrong. R3 should not allow to enter any 
other than full binary padded format then!