World: r3wp

I mean 32-bit integer! type, not 32-bit binary encoding converting 
to the current 64-bit integer! type.

It's supposed to be an R3 build option for embedded of legacy systems 
that don't support 64-bit integer math.

of -> or

and my connversion is not exact, because we don't have the sign bit 
expansion

Nice puzzle.

Giving a signed 16bit binary integer, give the corresponding R3 integer.

A one-liner solution (without any test) would be  appreciated

I don't like it very much, be i think i got something...


>> signed16: funco [n][(complement -1 + shift n -15) and -65536 or 
n]
>> signed16 to-integer #{FFFF}
== -1

Well, that math solution is better than the binary manipulations 
I was doing.

Idea comming from a forth kernel i've done

I like the discussion occuring because of my simple question... all 
of your answers are pre-emptively solving other issues I was going 
to have in the future.  :-)

Argh.... I felt vaguely, that there was an easier way

>> signed16: funco [n][32767 - n xor 32767]
>> signed16 to-integer #{FFFF}
== -1

32767 is found like this for signed 16bit integers:
2 ** 15 - 1

Ladislav: The behaviour of to-decimal appears to be different from 
the documentation for the decimal! datatype. That's why I think that 
to decimal! to binary! 10000.0 is a bug.

What documentation? Link it so we can fix it.

A lot of the R3 manual is still R2.3 placeholder docs, not updated 
yet. We changed the behavior of TO throughout R3, so those docs are 
more likely to be wrong. We definitely need volunteers to help with 
the docs. For now, the most accurate documentation for a lot of topics 
is still CureCode.

Wow .. I see Amiga R3 build is pending !

Can we ask Carl for an ARM build?

not after the leg though ...

I want WinMobile build :-)

I think that we should put empahsis on main OSes, and then on mobile 
ones - OS-X - dunno how to use anything like R3, unless the phone 
is jailbroken, WinMobile, Android, WebOS (Palm), Symbian(?), BlackBerry(?)

I think that mobile platforms are trend now. And it will be even 
more in upcoming years. New Google phone comes from HTC, it will 
be Snapdragon CPU (1GHz) based - lot's of power.

I think it is more important to support such platforms, than OSes 
like AmigaOS, MorphOS, Haiku ... otoh - those OSes are run by passionate 
hobbyists, who use phones too. So maybe if you make R3 available 
to those alternatives, they will be happy, and they will support 
us even on Phone platforms ...

I want embedded support :)

I would like to see a 6502 build. Just for fun. :-)

http://www.cc65.org/

As for Amiga related platforms, I would buy a NATAMI ... just for 
nostalgy reasons. It would be cool to have REBOL there :-)

I've still got a Plus/4 so it Henrik can get it going on 6502, and 
supply it on a 1541 360k floppy disk .. I'll try and run it

oops ... i think it might have been 170kb

BrianH: This page: http://www.rebol.com/r3/docs/datatypes/decimal.html

This one too - http://www.rebol.com/r3/docs/datatypes/binary.html

what can we expect from rebol version for christmass ?  rebol - core 
? rebol - core + gui ? rebol - core + gui + odbc ? rebol - core + 
gui + odbc +plugin ;-)

carl said => # The Core host environment will be released, with major 
updates each week until it is stable, acceptable, and documented 
for initial developers. I'll be "in the cave" until this is accomplished.

# Personally, I'd like to see the View host environment also released. 
This would enable development community progress to resume on graphics, 
the GUI, and also on ports to other systems, such as OS X. Maybe 
some Christmas candy, but no promises.

perhaps => rebol core + gui  for windows and linux ?????????

Claude - your estimate is way too optimistic imo.

rebol core + gui only for windows then ???

not at all. Christmass is in one week. I don't expect any other than 
internal development release of Host environment ...

Please read following document - you will see, there is still plenty 
of work to be done to achieve proper isolation ....

http://www.rebol.net/wiki/Host-Builds

There is some architecture change ahead - namely merging DELECT and 
command! interfaces. View will be moved out to this interface, so 
it will be kind of "external".

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

... and then we still wait for much needed improvements to Extension 
interface. It needs to support Devices definitely. No easy way to 
do callbacks right now, etc.

As for my own guess - I think that at least whole January will be 
devoted to such development and testing ....

However - I would not be pessimistic. Quite opposite. Carl is right 
now working on very important aspects of R3. We have been waiting 
for it for 3-4 year and we are finally there ...

yes and i still belive in the christmass gift ;-)

... so just push your callendar a little bit :-)

PeterWood, I just checked the history on those pages and they haven't 
been modified since the initial import from the Core 2.3 manual. 
Thanks for flagging these for revision - I'll see about marking them 
as such.

Documentation writing and modification is the thing that we need 
the most help on, probably 50x the number of people we have working 
on the whole R3 project right now. For now, if there is some discrepancy 
between the manual and the behavior of R3, check CureCode. If it's 
not mentioned there then there is a good chance that the R3 behavior 
is intentional.

Claude, Rebol needs to move ahead in a clear path... finishing rebol 
core, in the way it is headed will allow rebol view itself.


it will also make rebol core a very appealing platform to integrate 
other tools into.  we're almost there but a few little things are 
still needed.

I would be happy to try and help with the documentation but the problem 
I, and possibly, many others face, is knowing what is the correct 
behaviour to document. I could only assume that the behaviour as 
demonstrated by the current Alpha is the one to be documented. I 
fearl that is too big an assumption to make.

Well, if you have any questions that aren't covered by CureCode, 
ask them here, in R3 chat, or post them in CureCode. Keep in mind 
that a ticket being dismissed in CureCode is nothing to be taken 
personally - we like those tickets because they serve as documentation 
of design decisions, especially in their comments.

Prime Numbers Peroformance Test: REBOL(r3-a96) vs. Java(jdk1.5)

For getting primes < 5000, Java is 6 times slower than Java
For getting primes < 100000, Java is 30 times slower than Java

correction: REBOL is 6 ...  REBOL is 30 ...