World: r3wp

As long as R2 and R3 use the same method there will be less mental 
translation overhead.

Do we need to do aliases, or generate from a common set of data? 
Perhaps common pages for common functions, since R2 people might 
be interested in R3 compatibility notes.

I was thinking that we could use a simple method where we add "=r2" 
for r2-specific notes... same with =r3.

That would work well.

common pages .. split for r2 and r3 use?

that way we can easily update for r4

so each page has a r2, r3 and ... rn section

Common source, different generated pages.

not sure if that is better ... since if you want a comparison, you 
have to look at separate pages.  And you have to maintain more pages 
as well.

Perhaps. With some formatting trickery, the notes for R3 could appear 
as info boxes in the R2 version, and vice-versa. Or they could be 
skipped on separately generated pages, or all put together on one 
page. We should decide which since it would affect the phrasing of 
the docs.

I'd prefer a single document with R2 and R3 sections when they apply. 
 going forward and backward, this will grow as the single source 
of information.


so far, it has respawned so many times in the past, it just gets 
weaker and weaker ... the original docs which had user contributed 
content via the rebol desktop was the best system.  its just gone 
downhill from there.

this latest web site effort is the perfect place to integrate all 
the docs and ACCUMLATE the information into a single and cohesive 
reference.


as a new user, old user and transitioning user, having all the information 
in one page is best for all cases. 
-you don't end up in the wrong docs (new users).

-you can easily see the scope of the improvements (old users comming 
back or tempted to)

-you can much more easily understand and grasp the changes when they 
are comparable in the same sheet (transition).

is it a known bug in R2: random 1970-1-1/0:0:0 --> win32 exception 
(crash)

it works in R3 as expected

nice one

there are a few bugs in RANDOM. perhaps a 2.7.x release should be 
devoted to fixing them.

Adding to RAMBO

in 2.7.7, send has not been fixed, the problem in the current version, 
is if a problem occours, the connection to the mail server isn't 
closed and when reaching the server max connections, send will stop 
working and difficult for the user to know what's up. here is a patched 
version, in addition to force an attempt close, it will return true 
on success, none on failure. hopefully it can be fixed for 2.7.8 
8-)
http://reboot.ch/rebol/send.r

btw, has /SDK 2.7.7 been build? can't find it.

been looking for 2.7.7 changes, maybe a link to this blog http://www.rebol.com/cgi-bin/blog.r?view=0447
sholuld be put on this page http://www.rebol.com/docs/v2-7.html

No new SDK.

Without SDK, I can't upgrade, most of my apps are used in encapped 
form.

and an working intel OSX SDK would be nice... the previous intel 
OSX builds where 100% useless when used with View.

2.7.7 kakks on an Atom chip single board computer running an embedded 
Ubuntu.   From desktop -> REBOL Demos

Seg Fault.   Should I care? (meaning, is Atom even on the expected 
to worky thingy)  I doubt the company will let me use any /View technology, 
but it would be nice to have for personal one-offs.   Some of it 
works, most of i

t kakks.   Always just the Get Smart  "missed it ... by that much" 
  :)

And 2.7.6 ?

what's "kakks" exactly?
I thought atom was x86 compatible?

How about XP on Atom..anyone tried it?

Works great, with all Windows REBOL versions. It's one of my test 
platforms.

Most "kakks" on Linux are distribution-specific, not processor-specific. 
Could you be more specific?

I've run REBOL on Windows with a number of SBCs with no issue.

R2/Forward updated to 2.100.80 (mostly) compatibility. That was the 
last release of R3 that focused on adding functions. Since then we 
have been doing bug fixes, revamps (of modules and PARSE), extensions, 
host code, and cleaning up datatype behavior. These updates will 
make it into 2.7.8.

Adding or changing functions, mind you. 2.100.80 only affected TAKE, 
as far as R2 is concerned, and in a way that was already there.

Yes, this means that we have fully working SINGLE?, COLLECT-WORDS, 
INVALID-UTF? and RESOLVE. Even R3 doesn't have a fully working INVALID-UTF? 
yet; since R2/Forward is mezzanine we can fix bugs that are still 
pending in the R3 natives.

R3 2.100.81 was the first release of the module revamp, so backporting 
the module system is the next step for R2/Forward. At least as much 
as we can fake, of course. RR2/Forward is still missing an implementation 
of UNBIND though, and it looks like the module system might need 
it. Wish me luck, or chip in!

So move the discussion here.

Delete the old group.

a pretty print function and now I have to deal with strings when 
operating on the data instead of numbers

which is crazy

ah, so you think that the sorting won't work?

So, is R3 using a different maths library from R2 ?

Yes, sort of. Integers and money were changed, percent added.

well, how about fixing decimals too

Decimals use IEEE 754 doubles.

The point would be, were tables done correctly in RebGUI, that the 
pretty print formatting would come at cell rendering time rather 
than as input to the table. In the work I've been doing, Cyphre changed 
table for me so that it would allow sorting on strings that contain 
numbers.

?? what table?

There's no table in VID

I'm talking about RebGUI, not VID.

Henrik .. you surprise me .. you've always said you don't use rebgui 
!

Anyway, R2 and R3 display decimals to a different level of precision 
before sci notation kicks in ....

Those are display functions - math is unaffected by display.