World: r3wp

further...

Take the implementation of modules and protect stuffs, I agree it 
may be (maybe) deeply modify the core and it's why it's must be done 
now, accordingly Carl and BrianH.
But for a user concern, it has a very low priority.

It's only of interest for those who want to create new commercial 
applications with R3, in few years....

But we will not develop new applications, if some important things 
that were  working in R2 are not working anymore in R3.
It's what i call high priority, NO REGRESSION allowed.

something that worked in R2 must be corrected at first, something 
new can be postponed.
just my opinion

But for a user concern, it has a very low priority.

 Correct. And you are not an R3 user. You are testing R3 alpha software. 
 Which is why it's essential to report bugs to Curecode.

Posting reports is in fact one of the main reasons that the R3 alpha 
is public.

Actually Steeve, the modules and protect features that are being 
worked on ARE high priority because R3 needs them.  Yes, they will 
be very useful for comercial apps when R3 is more stable but for 
R3 to become more stable those features are needed now.

Steeve, I can guarantee that if bugs are not reported they won't 
be fixed at all. It is completely inappropriate to compare the R2 
project to the R3 project. Bugs weren't getting fixed in the proprietary, 
release-rarely R2, but they *are* getting fixed quite regularly in 
the semi-community, release-often R3 project.


We are in alpha, and still in the design phase with much of the core 
of R3. We only have so many people actively contributing to R3, only 
so much capacity. And you might recall how much we have been insisting 
that people not use R3 in production yet, that it is not ready. This 
means that the main product that is setting the priorities of what 
gets fixed or implemented is R3 itself. And that product is still 
being built.

No regression allowed

 - are you kidding? Large quantities of R3 are brand new code. It 
 isn't regressing, it just hasn't caught up yet.


And don't assume that the code will work the same in R3 as in R2 
- we aren't even trying to be compatible with R2 except where appropriate. 
We're fixing design shortcomings in R2, not just bugs, and that means 
incompatibilities sometimes. Compatibility with R2 is considered 
a nice thing to do, but not as high a priority as doing things right, 
adapting REBOL to handle the needs of today and tomorrow.


And speaking of priorities, they are not absolute. We set priorities 
relative to what we are working on now and what we will need next. 
Once those things are done, we bump the priorities of the next things 
on the list.


We recognize that vectors are important, but they are not as important 
as security and modularity *right now*. We needed modules settled 
now because the plugin model depends on them, because it would help 
us design the security model, and because the GUI and mezzanine code 
needs organization to be further developed.


We need the plugin model because it affects the host interface design, 
and the host interface needs a redesign before we can release the 
host code. We need to release the host code so that more people can 
fix bugs like that OS X bug PeterWood mentioned.


Things are going to get fixed, but most fixes require other things 
to get done first. We are focusing now on the bottlenecks, the bugs 
or waiting improvements that are blocking the most. Right now the 
highest priorities are those that are blocking people from contributing 
to R3, because the resource we have the least of is people that are 
willing to help.

The two biggest things blocking contributions:

1. We need to release the host code so people can fix platform-specific 
bugs.

2. The GUI infrastructure is just not in good enough shape to handle 
contributions, at least from a code organization standpoint.


There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
and in some cases we really need those people's help (ironically 
enough, not always for GUI work). For that and many other reasons, 
the GUI is a huge priority in the short term.


And we *really* need to release the host code, or platform-specific 
bug-fixes and enhancements won't happen.

I'm sorry, I can't really guarantee that unreported bugs won't be 
fixed. They might be fixed by accident. However, it is clear that 
unreported bugs would be low-priority unless they affect more important 
things. If they were important to someone, that someone would report 
them, right?

A49 was released with buch of changes ...

By the way, your DIFFERENCE/skip example should be using BODY-OF, 
not VALUES-OF. DIFFERENCE/skip still doesn't work though.

Pekr, good news! Now I can test the new changes, which were critical 
for code optimization :)

There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
  

I'm suprised that so many people are happy to work with a non-gui 
client.  If one asks for volunteers to spend their time, and create 
a retro environment for them to work ... you're not going to get 
the optimal result.

Steeve, in may experience the Curecode reporting system is far more 
effective than RAMBO.

There is clearly a lot f effort (thanks, Brian!) put into analysing, 
categorising, prioritising and fixing issues raised via Cuecode.


Not everything, of course I've added issues that have languished 
a long time, and some that have been dismissed. But they are outweighed 
by the ones that have been fixed in a few days.

It may be a lottery, but it is winnable :-)

Don't take it personally if something sounds ridiculous to me - I 
don't consider my opinion to be common.


We needed the infrastructure in place for collaborative development. 
What we were using before (AltMe, DevBase 2, traditional revision 
control systems) had failed us - we couldn't scale past about 5 developers 
before the process fell apart. That's why the R3-GUI AltMe world 
was created.


Even in text mode, R3 chat and DevBase 3 have been a huge success, 
as the many releases of R3 in the last few months have shown. We 
needed contributions to get R3 to the point where it is now.

Should write a book about it.

If you collect all of the posts I've written about the subject, I 
almost have already :)

I agree with Steeve that being able to find the difference between 
objects easily would be very useful.

BROWSE now works under OSX.

Pekr: "Steeve - your attitude is the same what DocKimbel showed here 
some two weeks ago. I thought that I am talking to adult ppl, and 
I really don't understand such childish behaviour". 


Are you sure you were thinking about me? I just re-read my old 2 
posts about money! datatype, I don't see what's childish in reporting 
a bug in RAMBO and warning about that?

Hi Doc. The problem with your bug is, that your assumption isn't 
correct. The money implementation used in 2.7.6 isn't more accurate 
than the decimal! datatype

Anyone have some detail on how tab-indexing is handled in R3?

You mean money! uses floating point in R2? If it's true, I don't 
see the point in having a money! datatype?

So what do you think about this? :
>> .3 - .2 - .1
== -2.77555756156289E-17
>> $.3 - $.2 - $.1
== -$0.00

3.4.2 Format

From appendix 1 of rebol core document:


The money! datatype uses standard IEEE floating point numbers allowing 
up to 15 digits of precision including cents.

As for what is the point ? There never seemed any to me in R2.

But it should be useful in R3:


The money datatype now uses a coded decimal representation, allowing 
accurate number representation up to 26 decimal digits in length. 
Due to its accuracy, this datatype is useful for financial, banking, 
commercial, transactional, and even some types of scientific applications.

..which I believe Ladislav supplied.

I suspect some rounding is being automatically applied with the money! 
datatype

>> round .3 - .2 - .1
== 0

R3:

>> $.3 - $.2 - $.1
== $0

Dockimbel - sorry, please accept my apology. It was not you, it was 
actually Geomol on 8-Apr, who too refused to submit bugs, as those 
might not be corrected anyway :-) You just contacted me privately 
the same day, expressing your opinion to me.

My only problem is that you have to use the money datatype to use 
this number format. It could be useful in other places. But I think 
we've had this discussion before.

If you do a ? datatype!, in R3 you get:


money!          datatype! high precision decimals with denomination 
(opt)

So you may wonder as a beginner why the description is like that.

yes, we have had that discussion before. I better don't jump into 
that discussion once again :-), because I never used money!, and 
I don't know why such general functionality as math precision should 
be expressed by the datatype called money! I would prefer BCD! precise!, 
or something else. Also very weird to use $ in front of it ...

PeterWood: thanks for the documentation reminder, I should have read 
it to refresh my mind about that before posting. I wonder if the 
R3 money! implementation could be easily backported to R2? It shouldn't 
be dependent on new R3 features.

Pekr: Apologies accepted, I guess I shouldn't post to you privately 
when you're already upset ;-).

I guess Ladilsav can answer your question about the ease of back-porting 
to R2 but I would guess that it's c code which means it is likely 
to be a long time before it would get back-ported.

Well for one thing, the space for the underlying data is less in 
R2 than in R3.

If R3 still uses 128bits slots for values, it shouldn't change memory 
usage from a user POV?

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.

Does that mean that the average memory usage will increase in R3?

Between that and the Unicode strings, basic data does take more RAM. 
We're making up for it by making all of the standard object types 
more efficient, so that overall memory usage will likely be less.

While we're talking about memory management, will it be possible 
to add in R3, a mean to adjust or tune GC behaviour by exposing some 
of the internal parameters? The goal is being able to adapt the tradeoff 
between speed and memory usage in various situations. For example 
: being able to set a max amount of memory for a REBOL session.

String, number and block data will be more; binary data will be the 
same; port and graphics objects will be much less. When we get vector! 
working that will drop memory usage in many data processing scenarios. 
Many of the changes to the mezzanines and natives (including changes 
in alpha 49) lower the number of block copies, so that cuts down 
memory overhead.

Adjusting the GC: I don't know.

I've asked on chat.

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.
Can you be more precise Brian ?
How long are the new slots ?

Long enough but not longer? :-)

uhm... something like that

Don't know off the top of my head. Not double in size, as the slot 
overhead hasn't doubled, just the data part.

Is Carl hiding from you such important infos ? :)

I don't ask - haven't needed to know.