World: r3wp

About the loop 5 example; I remember Carl saying that would break 
the rebol evaluation rules, or something like that.
But could we get that functionality some other way?

i think a reduce that can not creates a new block is not interesting, 
because the same block can not be anymore reduced next.

so, you can't use it in a loop

but an insert fonction which can reduce all the values from a a block 
before adding them, is quite interesting.

something like,

insert/reduce ['fill-pen color 'text 'vectorial offset message]]

it means get the value of the worlds before adding them

could be, insert/get or insert/load as well

so that no new blocks are created

Steeve...

REPEND

=D

compose ? hihihihi

yes ok for the name REPEND, but we need a native func with no reduce 
inside

Yes, it would be great if REPEND worked that way.

Anton, is there a reason COMPOSE won't do what you need here?  If 
the objective is to avoid creating a temporary block, compose does 
it.

Look here: http://curecode.org/rebol3/ticket.rsp?id=506

Right on topic with what you are saying, and my biggest personal 
reqest for R3.

Ammon, both COMPOSE and REDUCE generate a new block.

BrianH, that's good that that ticket exists. Thanks for pointing 
it out. Hopefully that will be implemented someday soon.

That's why it's "urgent" priority.

I'm seriously beginning to loose faith in R3. As I see it, there 
are still a lot of bugs on the lowest levels, and most development 
is going on far above that level. It's like a tall building, where 
new windows are put in on the 123 floor, while there are still many 
cracks in the basement. I guess, it'll take years at best, before 
we see a stable R3 on major platforms at the same time.

Most of the bugs in lower levels of R3 are found through higher level 
development, so that will likely continue. Also, getting things right 
is more important this time around. Please don't use it in production 
environments yet.

The lowers levels should then have been tested better, before going 
into higher levels. When you fix a bug on a low level now, it could 
have significal influence on higher levels, so more tests and probably 
new bugs. Problem is the low levels are hidden from us.


Memory problem on OS X concern me a lot. Also today I wanted to do 
some test on issue! datatype, and get strange results. Like doing:

i: #
insert i "abc"


If low level series handling like this has bugs, then I'm very concerned.

Henrik, when I made Canvas RPaint, you helped a lot with testing. 
And I didn't move ahead, before everything worked completely. That's 
the way to do large projects.

I'm not sure I understand this concern. Clearly there is a bug, and 
Carl usually fixes those, but only if they are reported to Curecode.

It looks like the issue type's new unicode (16bit?) internal representation 
isn't being formed or molded correctly yet.

Yes, we can find bugs, report to Curecode. Before Curecode we did 
it in r3-alpha. It has been going on for years. And it will continue 
to years. The problem is the way, the whole project is run.

continue *for* years

I don't understand how you expect it to be done differently.

Carl can only fix bugs so fast.

I tried in r3-alpha to make a list of things, to be tested, with 
a hierarchy from a description from Carl. (The r3-status.r script) 
But it didn't happen the way, I had in mind.

I think, it would have less bugs, if lower levels were tested better 
before moving on. Doing it that way, you'll end up using less time 
on the whole things, before it's finished.

It would also be another situation, if it were open source. But even 
with closed source, I can think of better ways to run it, that how 
it's actually done.

I don't think it would have less bugs. More bugs would have been 
exposed, but the rate of fixes would be roughly the same. We already 
have a rigorous testing system in place, only it has not been used 
much yet. I think it's because Carl is too busy designing the remaining 
subsystems.


What's important at higher level development, is not to use workarounds 
for bugs, but await proper fixes.

that = than

And there are many parts that are sitting unfixed, because they await 
a proper solution (compiler issues), such as the many problems with 
image!.


BrianH has also done a ton of work, spoonfeeding Carl with reports 
and fixing dozens of issues with LOAD and TRANSCODE, so to say that 
things are closed, is not true.

Geomol - I have to object. Before complaining about the way the projects 
is run, please check the following:


 - do you really understand, how the project is being run at all? 
 Because quite frankly, you are not using fair arguments here imo. 
 I can agree, but only to some extent, that things are being done 
 in a chaotic way. But - being close to Carl and trying to listen 
 to him and COMMUNICATE with him, I can understand the aproach he 
 takes. 


- one of your false arguments is, that putting things into CureCode 
is not helpful - CureCode was chosen by Carl and the community as 
a streamlined channel for bug reporting. Now please don't tell me, 
that even some low level bugs are not reported? There is a changelog 
which simply proves you being wrong.


- Before some releases Carl asks BrianH to change CureCode items 
rating to fix most important stuff - so how comes that our aproach 
does not work? Please post bug reports, talk to Carl or BrianH to 
raise the importance - doesn't following section show we finally 
got our requested - release early, release often?
http://www.rebol.net/wiki/R3_Releases


- and to be honest - you are one of persons being added to the r3-gui 
world. Some time back Carl had to add even lamer like me to the list 
:-) - and you know why? Because he was not getting much of response. 
He nominated top community gurus to help with the GUI. Actually, 
the same happened during the Gab's VID3 project - only me, Henrik, 
and BrianH commented. It seems to me that some ppl prefer to chat 
about science and belief systems instead of helping to develop R3 
;-) (I am not dismissing anyone's right to come here to chat about 
anything - this place is really a rebol pub where we meet, but the 
other worlds were specialised, yet lacked the input from community, 
even if asked for help)


- in order to get more ppl involved in R3 development at native level, 
it is clear where do we need to get - we've got R3 chat to be base 
of new Altme, new BBS, new DevBase. In March plan Carl clearly outlined, 
that in order to get sources out, we need rebin, plugins. They are 
now postponed due to modules, security, but still a high priority. 
How do I know? Because I was not lazy and asked Carl the specific 
question.


- we also get improvements on other fronts - we have got new streamlined 
Docs. I suggested Carl to add community section, then also new R3 
section to rebol.com page and to produce detailed changelogs. These 
all are small steps, but steps which make a difference.


Now please tell me - how complaining here can make situation any 
better? How many bugs have you posted, how many rebdev messages you 
have asked to Carl? Why don't you talk about your concerns with Carl? 
He will respond to you, like to me or anyone else - either via chat, 
or via a Blog article.


As for me, I am quite fine with how R3 is progressing last few months. 
Yes, we are slow on the whole project, but we are still doing a good 
progress imo.

Responding to Pekr's comments:


- I've communicated with Carl privately before. Starting on the OS 
X port more than a year ago is one example. Lack of info back to 
me made me stop. It's in a group in r3-alpha, you don't have access 
to.


- About CureCode, I didn't argue, it's not helpful. I don't care, 
what bug report system is used, as long as it works. Curecode is 
one of the best such systems, I've seen. Yes, low level bugs are 
reported. That's not the problem. It doesn't make much sense to me 
to work on a building (in lack of better metaphor) at the 123 level, 
when the basement isn't stable. Question is, how long this situation 
will last, before I see a stable version across platforms. My guess 
is years, therefore my concerns.


- r3-gui. Again it doesn't make much sense to me to work on GUI, 
if the core has many bugs.


- You list many topics in monthly plan. Development is going on at 
all levels of the building. I would start by making a solid basement, 
then make my way up. Making any level finished, before going to the 
next. It's just another way of doing things. I have good experience 
doing it the way, I try to describe.


- About docs. It's about time, something is done with the docs. I 
had huge problems figuring out, even how to test R3 back in the r3-alpha 
days. Docs were confusing, lack info, etc. Some months ago I tried 
to figure out, if I could port Canvas RPaint to R3. I stopped quickly, 
when I couldn't find the docs to do even simple things.


Well, you ask, why I complain. Initially I just said, how I felt. 
Loosing faith in the project. I really hope, it'll happen one day. 
But as I see it, it'll take years. I feel like sharing this view 
with others. Then you can use it as you wish. I need to figure out, 
what I'll do with my own development.

About port to other OS, this is the info (in DocBase), I managed 
to get out of it (check history of that page):
http://www.rebol.net/wiki/Porting_Recipe

I have access to all worlds I know development went in - r3-alpha, 
r3-gui, and I of course remember your effort. It is not the time 
(yet) to do solid porting to another systems by ourselves. So far 
only Carl does some ports, bu those should be regarded being experiments.

It is not the time (yet) to do solid porting to another systems by 
ourselves.


Good info! I should have known that 1.5 years ago, when porting was 
a topic.

Question is, how long this situation will last, before I see a stable 
version across the platforms ...

 - I don't know, noone knows. The thing we need is - testing. So - 
 find a bug, file a bug, talk to Brian or Carl, make it a higher priority, 
 it will get fixed.

Do you think, the time will ever be right for people doing such ports 
to all different kinds of OSs? A situation, where the OS-dependent 
parts of R3 will be open source and documented. I have my doubts.

One thing I have learned  over the years: never care for the "new"version. 
Use what you have, and consider it as what it is... just another 
tool.

So R2 is great, often. Sometimes it is not. The longer R3 takes, 
the more often alternatives will be viable. That simple. I'd love 
to help on R3, but I have work,  kids, etc.

The way I see it (now)is R2 is just a product thatI bought that gives 
great value. But who knows.... tomorrow there might be this awesome 
language called "Zen" and after 2 years I am so good with it... you 
get the picture :-)

The goal is not R2/R3 ... the goal is to be effective. So you can 
make money. And so on.

Right.

I do remember myself panicking xy times in the past. Other panicked 
too - we all arged Carl to get back to finishing Core first, then 
move forward. But Carl thinked otherwise - that R3 is good enough 
to attract new users via GUI. You all surely know, how difficult 
it is to change Carl's mind. But OTOH Carl listens to what we say.

So the answer to your question is - yes, I really think we are months 
at max away from the source releases and real porting efforts. In 
the meantime, do what Maarten suggests - just sit and watch, and 
accept things being just an alpha, not a beta ...

Pekr, I just started my old r3-status.r from the r3-alpha world.


One of the top priority bugs in that is #60 division by zero. I went 
to Curecode and read about the bug dated 4-Jun-2007, and I tried 
it in latest R3. It's still there.


Another high priority, #115 dated 11-Jun-2007 has status waiting. 
Waiting for what?


A third is about money! datatype, #250. Currency now seem to be removed 
from R3, so it can't be tested anymore. So R3 will not have currency?

etc...


So you see, there are lots of things to put in rock at the lowest 
level. So no need to discuss all the higher level things (from my 
viewpoint), before those lower levels are fixed.


An example of backward development or bad planning or whatever. The 
issue! test, I just wrote about. It seems to be because of unicode. 
So the plan for all this wasn't made, when the issue! datatype was 
programmed? Now what? Do we have to roll all back and do heavy testing 
again at the lowest level?