World: r3wp

No, no errors on submission.

Which blog?

R3 but looks like you're now removed them

Yes, ok, both blogs now.

OT, what about a 64 bit R2?

So we can install on Windows 2008 64  bit ....

WG (wrong group)

Now that the iPad is out .. this must surely drive Android based 
slates as well.

So, no hostkit for Android yet?

No hostkit or R3 for ARM yet.

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.

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