World: r3wp

works in R2 as well. feel free to add it to R2/Forward.

What's the setting?

what setting?

what input is causing you to create this output?

Are you creating sentences?

blocks of strings, usually created for dialogs or other human readable 
output

I'd think that it is just something that you do :)

I don't do this .. but I have code that processes a whole sentence 
and grammar fixes it including the above.

I've built similar funcs, but not often. Maybe it could be part of 
a formatting module, and I would give it a different name.

The output format is specific enough, and the name generic enough, 
that I wouldn't make it a standard func as is. It is useful though.

Could someone please add an A105 version to R3 Curecode? Thanks!

Done. And bug#1643 marked as fixed in it..

Thanks, Brian.

Just reading new roadmap - http://www.rebol.com/roadmap.html... 
what I don't understand is all the fuss about R3+. From the very 
beginning, I don't like the idea of putting some usefull stuff into 
additional module. E.g. - why some usefull mezzanines or protocols 
be part of the plus package? What I fear is - anything, that is optional, 
will not be a standard. I can understand that we can't include 100 
protocols probably, but talking about + package, where the only protocol 
we have is http, and even that is not fully functional, is a bit 
preliminary :-)


Interesting note about R3 DB - what is R3 DB port? Is Rebin, RIF, 
finally coming? Or did we decide to select one DB, e.g. SQLite engine, 
and include it into R3?


As for tasking - "Experiment: how far does the current R3 multitasking 
base take us?" - no experiments, please :-) Tasking/IPC is the last 
missing stone before we can claim R3 being a beta - it needs solid 
work, and I expect 1-2 months, and the same kind of impact, as Unicode 
transition, or Extension, Callbacks had :-)

Tasking/IPC is the last missing stone before we can claim R3 being 
a beta
 - disagreed

(with both "the last" as well as "missing")

these are just opinions

There is no definition of what constitutes a R3 beta

Nevertheless, I do not doubt Pekr will be proven wrong.

...even without a definition

Pekr, what part of "optional" means "non-standard"? It just means 
that it isn't loaded and taking up resources if you don't need it.

It's a plus for a lot of platforms to be able to build on a minimal 
base. For instance, I would have loved /Base on WinCE.

Everyone has different needs. I defined "my" needs for R3 beta in 
related document (wiki). The only thing I meant is, that I regard 
tasking/ipc being last "big" missing component. I have no problem 
being corrected or proven wrong ...

Is it that hard for you to realize, that your needs do not define 
what is R3 beta?

in must act on pekr's defence here.    his is just summarizing years 
of user expectations.

part of why pekr keeps insisting is that if you just look at the 
many changes the Extension/host kit has undergone since its first 
release, it can be expected that tasks will have as much side-effects 
in its own way.

modules, callbacks, memory leaks in the GC, memory exceptions, IPC 
and API for inter-thread data shareing, the potential list is long.

R3 is currently undergoing open-heart surgery, with Carl deep in 
system and architecture mode... with all of the stuff fresh in his 
mind.


I think its the perfect time to overhaul the task! system and finally 
make a real architecture/API and identify,  solve,  or decide on 
the potential issues "hard issues".

what is "years of user expectations"? if you speak for you and Pekr 
saying, that R3 beta is what "your needs" are, then you are patently 
wrong, no matter you are two now

I am talking about 15 years of use of REBOL by the whole community.

its always been a thorn in the side of the language.  if you don't 
need multi-threading, then cool... but I've lost contracts just because 
of this.

this is not a discussion about to beta or not to beta.   if we go 
to beta ... yay.. then in 6 months- a year... a design change required 
by tasks, forces Carl to either do a half-assed solution or go back 
to breaking R3.  what's the point of even going to beta.

Please be so kind and do not speak for me ("whole REBOL community")

Lad... why are you irritated about the need to address the task! 
issue?

do you think labeling "beta" on REBOL will change something?

But we each have different things that are important to us. I might 
say that robust and professional integration with SQL server is key 
as I know that's stopped a number of people from using REBOL in their 
companies. I could use that as a selling point, but I don't want 
to use SQL Server myself. :-)


Other things are more important to me, but only Carl knows what he 
thinks is important for him and for REBOL.

if the task! datatype is to be part of R3... which it currently is... 
and is laden with bugs, many unknowns and limitations... either we 
rip out the concept of tasking in R3 and limit the language's appeal 
or we fix the datatype and its api.

Gregg the difference is that Tasks operate at the core level and 
imply possible GC hacks, inter extension mem management, hard to 
track stack stuff...


all things which inherently *might* force changes in core level apis 
like devices, extensions, etc.

adding support for libraries, that is effectively something that 
uses the core... not defines it.


adding a standard SQL connector in REBOL would be sweet, but it won't 
change the core... its using it.

Guys, the thing is pretty simple.

I can't speak for Ladislav, but where I disagree about limiting the 
language's appeal is that we don't know who it's supposed to appeal 
to. It may not be you, me, and Petr at all.

There are zillions of things we want to see. Ok, and everyone wants 
something different.

We don't need a R3, that is in development mode until dawn before 
we can make use of it.

Hence, we are working on getting incremental steps done, that are 
useful. Maybe not for everyone but a lot can be done with R3 now.

And we will keep the high pace of new releases. Each one delivering 
more stuff.

Maybe something breaks existing code than. Yes, not to nice and takes 
some work but it's not killing us.

While R3 moves forward, we will use it for all our projects. Add, 
what's missing on the way and move forward.

In this stream tasks will come. I just don't know yet, if next week, 
month or in 6 months at the moment.

But Carl has put it onto the roadmap, so it's already in the near 
range radar.

But tasks is not just about "want".... its about something that has 
the *potential* (we don't know) to break other R3 components down 
the road.


so My point is not that I want it now.... I just want R3 to stay 
"freed from locking" until tasks are revised by carl.