World: r3wp

if error? err: try [  ][
   print mold disarm err
]

I've always used the second way, but almost everywhere else, I see 
others use set/any

Ah, I see now *a* set-word!. :-\  Consider an unset! result:

>> if error? err: try [()] [print mold disarm err]
** Script Error: err needs a value
** Near: if error? err: try [()]
>> if error? set/any 'err try [()] [print mold disarm err]
== none

Ohhkay, guess I've just never run across it.  Thanks

Is there any way in R3 to optimize code such as 


 out: insert insert insert insert insert [] 'fill-pen color [text 
 vectorial] 0x0 "hello"


?  I think the appearance of n INSERTs is kind of ludicrous. People 
are doing this for performance reasons, so the usual way we would 
optimize the code (which produces an intermediate block), isn't an 
answer.

I've forgotten if R3 has any way. (A quick look at APPLY and MAP 
doesn't seem to bear any fruit.)

it's not more fast than using a reduce or a compose.

but it saves memory overheads, exspecially in big loops

---> thus, does become a speed issue.

It would be nice to be able to say:

	loop 5 [insert] [ ] v1 v2 v3 v4 v5

so no intermediate block is generated.

Or have a method of reducing only the items in a block as they are 
being applied, without generating a new temporary block to hold them.

(This idea has been discussed before, somewhere...)

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