World: r3wp

hey guys, have we a clever way to extract same variables with different 
values in 2 different objects ?
In one word: the difference.
I mean, without doing a nasty loop

i tried, 
>> difference/skip values-of obj1 values-of obj2 2

but it fails (something wrong with the difference function when values 
are none!)

Please, don't say to me, the only hope is to do a foreach loop.

not rebolish

you write VALUES-OF, but do you mean a block of words that are different?

you may come with something completly different, i just want the 
list of variables which have different values

now that we have FOREACH on objects, it could be a good time to ask 
on the blog or in chat.

Hey, that's not clever at all

I was referring to that the FOREACH change was in the same ballpark 
as would be required for this to work without making loops.

even with UNIQUE, i got a stupid result.

>> obj2: make obj1: context [a: b: none] [a: 1]
== make object! [
    a: 1
    b: none
]

>> unique/skip append body-of obj1 body-of obj2 2
== [
    a: none
    b: none
    b: none
]

what's wrong with all thess bugous functions ?

/skip doesnn't work at all in INTERSECT, UNIQUE, DIFFERENCE, UNION...

pfff....

please note it in curecode, thanks

boring...

it will be delayed until 2010

and it won't be by not posting in curecode?

i noticed the same bugs with R2 previously, never been corrected.

I think no one except me want to use those vector functions. I should 
forget it

I should forget it

 nice attitude. why do you think the bugs haven't been fixed, then?

It's only corrected if several user or Carl have the same wanting 
hurgently, if not, it will be delayed until the first beta release, 
in some years...

and it won't be fixed at all if it's not reported to curecode.

Steeve - you are not constructive, sorry. With messages like "boring", 
"pfff", "in some years", please save your comments for yourself then, 
if you don't belive that posting to CureCode and asking for priority 
change might help.

It is exactly attitude like yours, that is becoming boring ...

... at least to ppl, that try to change some things. R3 is simply 
not complete, that is the fact. So - we can either participate (but 
accept the incomplete state), or wait for final release ..

exactly my opinion, i will wait

until the waiting bugs in curecode are all corrected, then i'll post 
new ones, i got new ones, several.

Steeve, that is the incorrect method. If the bugs are not posted 
NOW, they may be harder to fix when R3 goes beta. We don't know, 
but Carl  has stated several times that when Core issues need to 
be looked in to, we must do that now.

I can understand how Steeve feels about posting bugs to CureCode. 
It's very frustrating that when bugs don't get looked at because 
they are not flavour of the day.

Not my opinion concerning some bugs i found. 

I think they have a lower priority than those, I or other poeple, 
have posted currently.

I want my previous request corrected at first, then i'll come with 
new ones with lower priority.
If you don't agree with that, then find the bugs yourself

Not posting bugs to curecode is a good way to betray the continuing 
development of R3.

And I basically strongly disagree with this method, because a non-posted 
bug report will eventually be forgotten by the person who found the 
bug until years later when it turns up again for a different person. 
It serves no purpose for anyone, not posting the report, including 
the would-be reporter.

I will continue to post bugs I find in CureCode when I find them 
but the lack of action on the bugs that I've posted (such as server 
ports not working on OS X) discourages me from doing more testing.

If i see a better aknowledge of the priority of some bugs in curecode, 
then i will change my mind.

Priority is not a parameter in the REPORTING of bugs. It is a paramenter 
in FIXING the bugs. I don't see how software development could work, 
if everyone posted bugs based on perceived priority on whether they 
would be fixed. Carl expects us to do alot of the work with finding 
bugs. When they will be fixed is up to him.

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. Such an attitude is treat 
to those, who try to actually do something. Do you really think that 
the rest of us would not like to have R3 available few years ago?

So, if you feel you will not report bugs, then don't do it - what 
else could be said?

... everybody is free to do anything actually ...

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.